48

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.

10 Answers 10

32

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):

DISPLAY=:0; export DISPLAY

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
  • 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 '16 at 6:56
  • bonanza: it is the the one output from xauth list. – John Eikenberry Jan 4 '17 at 22:40
  • 1
    Another way to do this is would be something like... "xauth extract - $DISPLAY | sudo -iu steam xauth merge -". In this case I have XAUTHORITY set in .profile, so the 'sudo -i' gets that set right. – John Eikenberry Jan 4 '17 at 22:42
12

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.

  • 1
    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
  • Still didn't work for me, on Mac OS X with zsh – Sridhar Sarnobat Aug 22 '17 at 15:52
9

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

sudo apt-get install sux
sux user -c 'command'
  • +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
  • 5
    sux is unmaintained (and removed from Debian/Ubuntu's repositories): packages.qa.debian.org/s/sux/news/20140101T172633Z.html – Rob W Feb 5 '16 at 20:28
9

First: Don't use xhost +, it's rather insecure (blanket allow/deny).

Rather use the X-Cookie mechanism:

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

Alternatively, if you have sux installed, use that (see ehempel's answer).

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

Notes:

  • Depending on your file permissions, you might have to copy .Xauthority in some other way.
  • Instead of copying .Xauthority, you can also use xauth to extract and copy the authorization key (see Randall's answer). If you have multiple keys in the .Xauthority file this is more selective; otherwise it is a matter of taste.
  • yeah,i have root access on that machine – Phil Aug 6 '09 at 17:52
  • This is just manually copying the xauth cookies via root access. This is no different from using xauth as Randall explains in the (current) top answer, except it copies every cookie that 'xauth list' would show. So this is less secure than the top xauth answer which would only add the cookies you pick. – John Eikenberry Jan 4 '17 at 22:39
  • @JohnEikenberry: True, thanks for pointing this out. I updated my answer. – sleske Feb 16 '17 at 9:43
7

This will fix the problem for all users:

cat <<EOF > /etc/profile.d/xauth.sh
#!/sbin/bash
export XAUTHORITY=~/.Xauthority
EOF
  • This is basically what I've done and it works great, thanks! – Guss Jul 20 '11 at 14:32
3

As root:

xhost local:yourusername

Where yourusername is your user name :)

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

2

These are just hacks:

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

sleske above has, I think, the proper solution.

  • ssh -X is a very simple and elegant solution, not depending on any deprecated/unmaintained gtk/kde stuff (which require installing more binaries with SUID bit...). – Stefan Mar 10 '18 at 20:52
2

I found something that works great for me on KDE

kdesu -u username /path/to/program
  • On debian part of kde-cli-tools, and not in $PATH but in /usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu (obviously depending on architecture). – Stefan Mar 10 '18 at 20:48
0

This way made in suse/opensuse : http://www.novell.com/support/kb/doc.php?id=7003743

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

session optional pam_xauth.so systemuser=1

Then you can switch with su without - :

su user2

and run the app graphically.

-1

For GNOME (and without any desktop environment really, I use it with icewm only) gksu:

gksu -u username program
  • "gksu has been deprecated for years": bugs.debian.org/cgi-bin/bugreport.cgi?bug=867236 – Stefan Mar 10 '18 at 20:45
  • @Stefan note that this Debian bug is about premise that elevating privileges for whole program is bad idea, and that the program should instead be modified to just execute minimal helpers with elevated privileges instead (using PolicyKit). This question (and my answer) is about reducing privileges, which is another thing altogether and in fact good idea (for example, for random browsing I have shortcut that execute firefox under some less privileged account that my default one, so any exploit there can't touch my data - and gksu(8) is quite fine for that) – Matija Nalis Mar 12 '18 at 14:40
  • All that is fine, but using a deprecated and unmaintained SUID binary is just wrong. This answer might have been useful in the past, but isn't anymore. – Stefan Mar 12 '18 at 21:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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