Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents

· Introduction to Operating Systems
· Linux Basics
· Working with the System
· Shells and Utilities
· Editing Files
· Basic Administration
· The Operating System
· The X Windowing System
· The Computer Itself
· Networking
· System Monitoring
· Solving Problems
· Security
· Installing and Upgrading
· Linux and Windows

Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
Copyright Info
Terms of Use
Privacy Info
Masthead / Impressum
Your Account

Private Messages

News Archive
Submit News
User Articles
Web Links


The Web

Who's Online
There are currently, 54 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here



Current HOWTO: Remote X Apps mini-HOWTO

Remote X Apps mini-HOWTO: X Applications from Another User-id Next Previous Contents

7. X Applications from Another User-id

Suppose you want to run a graphical configuration tool that requires root privileges. However, your X session is running under your usual account. It may seem strange at first, but the X server will not allow the tool to access your display. How is this possible when root can normally do anything? And how do you work around this problem?

Let's generalise to the situation where you want to an X appliation under a user-id clientuser, but the X session was started by serveruser. If you have read the section on cookies, it is clear why clientuser cannot access your display: ~clientuser/.Xauthority does not contain the right magic cookie for accessing the display. The right cookie is found in ~serveruser/.Xauthority.

7.1 Different Users on the Same Host

Of course, anything that works for remote X also works for X from a different user-id as well (particularly slogin localhost -l clientuser). It's just that the client host and the server host happen to be the same. However, when both hosts are the same, there are some shortcuts for transferring the magic cookie.

We'll assume that you use su to switch user-ids. Basically, what you have to do is write a script that will call su, but wraps the command that su executes with some code that does the necessary things for remote X. These necessary things are setting the DISPLAY variable and transferring the magic cookie.

Setting DISPLAY is relatively easy; it just means defining DISPLAY="$DISPLAY" before running the su command argument. So you could just do:

su - clientuser -c "env DISPLAY=$DISPLAY clientprogram &"

This doesn't work yet, because we still have to transfer the cookie. We can retrieve the cookie using xauth list "$DISPLAY". This command happens to list the cookie in a format that's suitable for feeding back to the xauth add command; just what we need!

We shall want to pass the cookie through a pipe. Unfortunately, it isn't easy to pass something through a pipe to the su command, because su wants to read the password from its standard input. Fortunately again, in a shell script we can joggle some file descriptors around, and get it done.

So we write a script around this, parameterizing by clientuser and clientprogram. Let's improve the script a little while we're at it, making it less readable but more robust. It looks like this:


if [ $# -lt 2 ]
then echo "usage: `basename $0` clientuser command" >&2
     exit 2


# FD 4 becomes stdin too
exec 4>&0

xauth list "$DISPLAY" | sed -e 's/^/add /' | {

    # FD 3 becomes xauth output
    # FD 0 becomes stdin again
    # FD 4 is closed
    exec 3>&0 0>&4 4>&-

    exec su - "$CLIENTUSER" -c \
         "xauth -q <&3
          exec env DISPLAY='$DISPLAY' "'"$SHELL"'" -c '$*' 3>&-"


I think this is portable and works well enough in most circumstances. The only shortcoming I can think of right now is that, due to using '$*', single quotes in command will mess up quoting in the su command argument ('$*'). If there's anything else seriously wrong with it, please drop me an email.

Call the script /usr/local/bin/xsu, and you can do:

xsu clientuser 'command &'

Can't be much easier, unless you get rid of the password. Yes, there are ways for that too (sudo), but this is not the place for that.

The tiny xsu script just mentioned has served as the basis for a more extended script called sux which apparently has found its way as a package into the Debian distribution.

7.2 Client User Is Root

Obviously, anything that works for non-root client users is going to work for root as well. However, with root you can make it even easier, because root can read anyone's ~/.Xauthority file. There's no need to transfer the cookie. All you have to do is set DISPLAY, and point XAUTHORITY to ~serveruser/.Xauthority. So you can do:

su - -c "exec env DISPLAY='$DISPLAY' \
                  XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \

Putting it into a script would give something like:

if [ $# -lt 1 ]
then echo "usage: `basename $0` command" >&2
     exit 2
su - -c "exec env DISPLAY='$DISPLAY' \
                  XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \
                  "'"$SHELL"'" -c '$*'"

Call the script /usr/local/bin/xroot, and you can do:

xroot 'control-panel &'

Although, if you've set up xsu already, there's no real reason to do this.

Next Previous Contents

The Linux Tutorial completely respects the rights of authors and artists to decide for themselves if and how their works can be used, independent of any existing licenses. This means if you are the author of any document presented on this site and do no wish it to be displayed as it is on this site or do not wish it to be displayed at all, please contact us and we will do our very best to accommodate you. If we are unable to accommodate you, we will, at your request, remove your document as quickly as possible.

If you are the author of any document presented on this site and would like a share of the advertising revenue, please contact us using the standard Feedback Form.


Looking for a "printer friendly" version?



Security Code
Security Code
Type Security Code

Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!

Amazon Wish List

Did You Know?
You can help in many different ways.


Tell a Friend About Us

Bookmark and Share

Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.41 Seconds