49

Let's say I have 2 user accounts user1 and user2. When I login as user1, and then switch to user2 using su, I can execute command-line programs, but GUI programs fail.

Example:

user1@laptop:~$ su - user2
user2@laptop:~$ leafpad ~/somefile.txt
No protocol specified
leafpad: Cannot open display: 

So how can I run a GUI application?

1
  • One of the main reasons, I've found, that this fails is because $XAUTHORITY is still set to user1's ~/.Xauthority, which the program, I guess, will try to read, and it fails because that file typically has mode 0600 (-rw-------), meaning it's unavailable for reading by anyone in the "other" group, which includes user2. Meaning if you chmod o+r ~/.Xauthority (as user1), you will have hacked your way around this problem. I wrote a script that demonstrates this. Feb 3, 2018 at 7:29

9 Answers 9

54

su vs. su -

When becoming another user you generally want to use su - user2. The dash will force user2's .bash_profile to get sourced.

xhost

Additionally you'll need to grant users access to your display. This is governed by X. You can use the command xhost + to allow other users permission to display GUI's to user1's desktop.

NOTE: When running xhost + you'll want to run this while still in a shell that belongs to user1.

$DISPLAY

When you become user2 you may need to set the environment variable $DISPLAY.

$ export DISPLAY=:0.0
16
  • 1
    xhost +user2 still gives me this error - xhost: bad hostname "user2". I googled some, and it seems I need to do xhost +user2@laptop or xhost +user2@localhost, not sure which. Then it says xhost +user2@localhost being added to access control list.
    – sashoalm
    Jan 11, 2014 at 10:10
  • 1
    But even after adding the user with xhost, and specifying export DISPLAY=:0.0, running leafpad still gives me No protocol specified leafpad: Cannot open display:, and fails to run. I found this link at linuxquestions.org/questions/linux-newbie-8/…, which says that there are some magic cookies and xauth. Have you tested that those things work on your computer btw? Maybe something's different with my configuration? I'm on Debian+LXDE.
    – sashoalm
    Jan 11, 2014 at 10:15
  • 7
    Oh, found something. On Fedora 21 running xhost gives a list in the format SI:localuser:USERNAME, so xhost SI:localuser:user2 should work. Oh and the display of the user can be found using w.
    – Wilf
    Apr 21, 2015 at 11:01
  • 11
    xhost + will allow any user on any host that can connect to your x-server to access your screen. xhost +SI:localuser:user2 works for me on Debian.
    – robartsd
    Mar 17, 2017 at 4:46
  • 2
    More xhost details and options (debian based solydX): This will allow any local user to access the display: xhost +local: From the man page: "The local family specifies all the local connections at once. However, the server interpreted address "si:localuser:username" can be used to specify a single local user" So this worked for me: xhost +si:localuser:[username]
    – Peter Kay
    Jun 6, 2020 at 15:04
14

You could use X11 forwarding:

ssh -XY otheruser@localhost your-gui-program-name-here
1
  • 1
    This is a brilliant solution. The simplest I 've read so far. Far more people are familiar with ssh than with x11 configuration. Nov 19, 2018 at 15:13
10

You need to share the authentication token from the user1 (assuming ~is home of user1):

cat ~/.Xauthority | sudo -u user2 -i tee .Xauthority > /dev/null
3
  • 1
    This is the only answer that worked for me (Ubuntu 14).
    – sudo
    Sep 8, 2017 at 1:28
  • This solution works nicely from within the remote machine (= X Win client) while the xhost solutions in other answers have to be executed on the local machine (= X Win server).
    – Jpsy
    Nov 1, 2017 at 15:55
  • It might be safer to use tee -a to avoid clobbering any existing information in .Xauthority. Jun 27, 2019 at 16:25
10

You can start app from another user. I will start the gimp app from user2, while being logged in (GUI) with user 1:

$ xhost +
$ sudo su user2

(enter pass)

$ gimp

Enjoy :)

3
  • can you tell a quick better way? Jan 1, 2018 at 1:57
  • I've always used this method, but it's no longer working to me with Debian and Xfce. (correction: it does work, but I have to export DISPLAY first, as the accepted answer says)
    – giusti
    Aug 20, 2018 at 0:38
  • after you end your session it will be good to disable it by $ xhost - Oct 18, 2018 at 21:59
4

You may try the sux command:

sux user2

sux will handle the $DISPLAY stuff for you. You may need to install it with:

sudo apt-get install sux

under Debian/Ubuntu.

2
  • 4
    sux is no longer shipped by Debian or Ubuntu. The best alternative I could find is adding xhost SI:localuser:root (or whatever user) to ~/.xprofile to allow it permanently or to use runuser
    – stefanct
    May 21, 2016 at 21:34
  • Up to and including Debian Stretch, there was gksu / gksudo alternative that worked fine. While still in Sid, it is removed in Buster for security issues. Sep 7, 2019 at 22:27
3

As alternative to sux, to safely run graphical command (firefox-esr in example below) as $AUTHUSER (guest in example below):

AUTHUSER=guest
AUTHSTRING=SI:localuser:${AUTHUSER}
xhost +${AUTHSTRING} > /dev/null
SUDO_ASKPASS=/usr/bin/ssh-askpass
export SUDO_ASKPASS
sudo -k --askpass -u ${AUTHUSER} /usr/bin/firefox-esr
xhost -${AUTHSTRING} > /dev/null
sudo -K

the code does:

  1. gives the guest user access to your current user $DISPLAY via xhost +SI:localuser:guest
  2. uses ssh-askpass to graphically ask you for password (of course, you could use sudoers(5) NOPASSWD: to avoid this, if your security policy thinks it is ok. Or you could use other askpass programs, or specify them in config files (see sudo(8) for details on --askpass)
  3. if the password is ok (and you have permissions in sudoers(5)) it runs the command /usr/bin/firefox-esr as another user (guest)
  4. after the program completes, permissions to other user (guest) to access your $DISPLAY are revoked via xhost -SI:localuser:guest
  5. finally, sudo -K removes cached password, so next invocation of ssh-askpass will ask you for password again (instead of using cached password)

    while it is little more work than what gksu(8) or sux(8) did, it can be scripted, and it is much more secure than:

    • xhost + (any user will have access to your graphical display as long as it is in effect)
    • readable ~/.xauth by other users (indefinite access by that user to your display)
    • what gksu/sux did (temporary copy of ~/.Xauthority, which allowed specified user to copy your MIT-MAGIC-COOKIE-1 and continue using your display even after gksu/sux finished (as long as you did not shutdown machine or logged out of display - screensavers, hibernate etc did not change the magic cookie).

as it will allow only one local user access to your display, and then only as long as the command runs (when command finishes, $AUTHUSER will no longer be able to access your display in any way).

Another safe alternative is ssh -X (without -Y which actually makes you less secure! see ForwardX11Trusted in ssh_config(5) for details), as is easier to use if you are not scripting it, but it induces additinal overhead (eg. it is slower) and some programs might not work correctly without unsafe -Y.

3

You can use pkexec, from man pkexec:

DESCRIPTION
pkexec allows an authorized user to execute PROGRAM as another user. If username is not specified, then the program will be executed as the administrative super user, root.

First you need to give to that user the permission with xhost, to use the GUI.

To add an user permanently you can add the following xhost command to /etc/bash.bashrc (system wide) or locally in ~/.bashrc. On debian.

You can use this script to launch leafpad as user2:

#!/bin/sh

xhost SI:localuser:user2
pkexec --user user2 env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY leafpad
2

Most solutions provided here don't integrate with Wayland and PulseAudio.

I wrote ego (Alter Ego), which automatically handles xhost and Wayland and PulseAudio socket sharing: https://github.com/intgr/ego

So you just run ego leafpad or ego -u user2 leafpad

If you run into problems, please open an issue on GitHub. I may be the only user of it, so it hasn't gotten much testing yet.

-2

You need to load installation UI as user2.

Try to following this:

Login as root:

sudo su

Test the x server:

xclock

If you can see a clock running, that's good to go, now try run this:

xhost

The result should like this:

xhost SI:localuser:tri
# tri is my user name

Now let user2 access xhost

xhost +SI:localuser:user2

now try to login again to user2 and try to open any of GUI program.

1
  • 1
    (1) There is nothing in this question that requires running as root, or where running as root is beneficial. (1b) If anything, running as root may just confuse matters. (2) There’s rarely (if ever) any reason to use sudo su.  Use sudo or su; pick one. (3) The question is written in terms of user1 and user2.  Please write your answer in terms of user1 and user2.  (Do or do not; there is no tri.) (4) Your answer would be better if it included an explanation of SI:localuser. … … … … … … … Please do not respond in comments; edit your answer to make it clearer and more complete. Jun 26, 2019 at 16:27

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.