59

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.

Improve this question

10 Answers 10

Reset to default
43

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
Improve this answer
5
  • 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, 2015 at 12:34
  • 1
    Seems, you forgot unset XAUTHORITY under user2
    – socketpair
    Dec 28, 2015 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, 2016 at 6:56
  • bonanza: it is the the one output from xauth list.
    – John Eikenberry
    Jan 4, 2017 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, 2017 at 22:42
16

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.

Improve this answer
5
  • 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, 2011 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, 2012 at 20:15
  • @DanielC.Sobral - that's what I said :-)
    – Guss
    May 4, 2012 at 20:19
  • @Guss Oh, sorry. I somehow inverted every sentence you wrote. :-)
    – Daniel C. Sobral
    May 4, 2012 at 21:37
  • Still didn't work for me, on Mac OS X with zsh
    – Sridhar Sarnobat
    Aug 22, 2017 at 15:52
13

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.
Improve this answer
2
  • 1
    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, 2017 at 22:39
  • @JohnEikenberry: True, thanks for pointing this out. I updated my answer.
    – sleske
    Feb 16, 2017 at 9:43
8

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

sudo apt-get install sux
sux user -c 'command'
Improve this answer
4
  • +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, 2009 at 12:13
  • You may note, that 'sux' indeed is a simple shell script, too..
    – Martin Mächler
    Feb 2, 2013 at 17:18
  • 6
    sux is unmaintained (and removed from Debian/Ubuntu's repositories): packages.qa.debian.org/s/sux/news/20140101T172633Z.html
    – Rob W
    Feb 5, 2016 at 20:28
  • E: Package 'sux' has no installation candidate
    – Mona Jalal
    Jan 25, 2021 at 19:28
8

As root:

xhost local:yourusername

Where yourusername is your user name :)

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

Improve this answer
7

This will fix the problem for all users:

cat <<EOF > /etc/profile.d/xauth.sh
#!/sbin/bash
export XAUTHORITY=~/.Xauthority
EOF
Improve this answer
0
3

I found something that works great for me on KDE

kdesu -u username /path/to/program
Improve this answer
1
  • 1
    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, 2018 at 20:48
2

Some other options:

  • xauth + (unsecure) (doesn't work on recent versions of xauth)
  • ssh -X user2@localhost (ugly, but might be simpler to get to work than direct authentication)
Improve this answer
3
  • 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, 2018 at 20:52
  • xauth: (argv):1: unknown command "+"
    – Mona Jalal
    Jan 25, 2021 at 19:29
  • 1
    @MonaJalal yeah, I haven't used xauth in ages, it seems that it has changed significantly. Updated the answer to note that, thanks!
    – alex
    Jan 26, 2021 at 20:06
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.

Improve this answer
-2

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

gksu -u username program
Improve this answer
3
  • 1
    "gksu has been deprecated for years": bugs.debian.org/cgi-bin/bugreport.cgi?bug=867236
    – Stefan
    Mar 10, 2018 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, 2018 at 14:40
  • 1
    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, 2018 at 21:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .