Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My regular user account is, let's say, user1. I created separate user2 for some x application that i would like to run while being logged into x as user1 but in a way that will prevent it from read/write access to user1 data. I thought that i could use xauth and sudo/su to user2 from user1 to run this application. How do i do this? I'm not sure how to configure xauth.

share|improve this question

To use xauth selectively, as user1 run:

xauth list|grep `uname -n`

This prints the hexkey authorization entries for you . You could have different displays associated with those hosts as well.

As user2 set your display (assuming default case):


Then run:

xauth add $DISPLAY . hexkey

Note the dot after the $DISPLAY and before the hexkey.

When access is no longer needed, as user2 you can run:

xauth remove $DISPLAY
share|improve this answer
Problem 1: user2 has no .Xauthority file in user2's home directory. Problem 2: Somehow and for some reason I dont' understand, after su, XAUTHORITY holds the filepath to user1's. But that file is not readable by user2. – Otheus Nov 4 '15 at 12:34
Seems, you forgot unset XAUTHORITY under user2 – socketpair Dec 28 '15 at 21:37
is the hexkey in the xauth add command the same as from xauth list or do I have to create a random new one? – bonanza Jul 15 at 6:56

Assuming debian or ubuntu (should be similar on Red Hat / SUSE).

sudo apt-get install sux
sux user -c 'command'
share|improve this answer
+1 good answer, no point in reinventing the wheel. Incidentally, sux mostly does what my answer above suggests. It's more powerful and easier to use of course. – sleske Aug 7 '09 at 12:13
You may note, that 'sux' indeed is a simple shell script, too.. – Martin Mächler Feb 2 '13 at 17:18
sux is unmaintained (and removed from Debian/Ubuntu's repositories): – Rob W Feb 5 at 20:28

I put in my .zshrc a line with export XAUTHORITY=~/.Xauthority and now I am able to execute sudo -E xcommand. After a lot of googling, for me this was the easiest way.

share|improve this answer
Note that this procedure would not normally require you to use sudo -E (and using -E is disabled on most default installs) because normally the default sudoers configuration would allow the XAUTHORITY environment variable to be passed to sudo. – Guss Jul 20 '11 at 14:33
@Guss It doesn't require -E. It can be set as a variable that can be passed, and either Red Hat or Debian suggests it. – Daniel C. Sobral May 3 '12 at 20:15
@DanielC.Sobral - that's what I said :-) – Guss May 4 '12 at 20:19
@Guss Oh, sorry. I somehow inverted every sentence you wrote. :-) – Daniel C. Sobral May 4 '12 at 21:37

Don't use Xauth, it's rather insecure (blanket allow/deny).

Rather use the X-Cookie mechanism. Just do:

su user2
cp /home/user1/.Xauthority /home/user2/.Xauthority 
export DISPLAY=:0

Then user2 will use the secret cookie in .Xauthority to authorize to the X server, and no one else will have access to it.

Note: Depending on your file permissions, you might have to copy .Xauthority in some other way.


While the above works, using sux is easier if it is installed. See other answer.

share|improve this answer
yeah,i have root access on that machine – Phil Aug 6 '09 at 17:52

This will fix the problem for all users:

cat <<EOF > /etc/profile.d/
export XAUTHORITY=~/.Xauthority
share|improve this answer
This is basically what I've done and it works great, thanks! – Guss Jul 20 '11 at 14:32

These are just hacks:

  • xauth + (unsecure)
  • ssh -X user2@localhost (ugly)

sleske above has, I think, the proper solution.

share|improve this answer
up vote 1 down vote accepted

I found something that works great for me on KDE

kdesu -u username /path/to/program
share|improve this answer

As root:

xhost local:yourusername

Where yourusername is your user name :)

Then do su as your user xclock should work if it's installed

share|improve this answer

This way made in suse/opensuse :

Simply modifying the /etc/pam.d/su, adding the option (bold) :

session optional systemuser=1

Then you can switch with su without - :

su user2

and run the app graphically.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.