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.

ﾤ ﾡ
  • 189
  • 2
  • 12
Phil
  • 1,969
  • 6
  • 29
  • 33

10 Answers10

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
Randall
  • 626
  • 4
  • 4
  • 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 04 '15 at 12:34
  • 1
    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 06:56
  • bonanza: it is the the one output from xauth list. – John Eikenberry Jan 04 '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 04 '17 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.

kfl62
  • 271
  • 5
  • 7
12

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.
sleske
  • 10,009
  • 4
  • 34
  • 44
  • 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 04 '17 at 22:39
  • @JohnEikenberry: True, thanks for pointing this out. I updated my answer. – sleske Feb 16 '17 at 09:43
8

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

sudo apt-get install sux
sux user -c 'command'
ehempel
  • 143
  • 4
7

This will fix the problem for all users:

cat <<EOF > /etc/profile.d/xauth.sh
#!/sbin/bash
export XAUTHORITY=~/.Xauthority
EOF
JMS
  • 71
  • 1
  • 1
7

As root:

xhost local:yourusername

Where yourusername is your user name :)

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

ACV
  • 201
  • 2
  • 3
3

I found something that works great for me on KDE

kdesu -u username /path/to/program
Phil
  • 1,969
  • 6
  • 29
  • 33
  • 1
    On debian part of [`kde-cli-tools`](https://packages.debian.org/search?keywords=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
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)
alex
  • 1,329
  • 6
  • 9
  • `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
  • xauth: (argv):1: unknown command "+" – Mona Jalal Jan 25 '21 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 '21 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.

pojem
  • 1
-2

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

gksu -u username program
Matija Nalis
  • 2,478
  • 24
  • 37
  • 1
    "gksu has been deprecated for years": https://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
  • 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 '18 at 21:42