Running GUI application as another (non-root) user

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:

<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="5c292f392e6d1c303d2c28332c">[email protected]</a>:~$ su - user2
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="cfbabcaabdfd8fa3aebfbba0bf">[email protected]</a>:~$ leafpad ~/somefile.txt
No protocol specified
leafpad: Cannot open display:

So how can I run a GUI application?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

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

Method 2

You could use X11 forwarding:

ssh -XY <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="83ecf7ebe6f1f6f0e6f1c3efece0e2efebecf0f7">[email protected]</a> your-gui-program-name-here

Method 3

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

Method 4

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 🙂

Method 5

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.

Method 6

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.

Method 7

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

Method 8

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.

Method 9

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.

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0