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:
- gives the
guest
user access to your current user $DISPLAY
via xhost +SI:localuser:guest
- 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
)
- if the password is ok (and you have permissions in
sudoers(5)
) it runs the command /usr/bin/firefox-esr
as another user (guest
)
- after the program completes, permissions to other user (
guest
) to access your $DISPLAY
are revoked via xhost -SI:localuser:guest
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
.
$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 youchmod o+r ~/.Xauthority
(as user1), you will have hacked your way around this problem. I wrote a script that demonstrates this. – Braden Best Feb 03 '18 at 07:29