I thought I’d share this little tip on how to easily forward X stuff (including over SSH), when needing to
sudo first, easily. It seems that this been something lost since the dawn of a new generation of Unix/Linux users, so hopefully this helps.
Why would you need to do some X forwarding as root? I don’t need to much anymore these days, but more often than not, I find myself needing to if I’m doing a quick Wireshark, and
tshark won’t cut it… or some bizarre Java install that needs to be done as root.
Your simple, secure and easy method is… the environment variable
Whenever a normal X login occurs, or
ssh with the
-Y options, amongst a bunch of other things, the
.Xauthorityfile is updated with the current authorisation information used to connect to a X server. This file is normally updated automatically, and can be viewed and manipulated using the
jason@somehost:~$ xauth list somehost/unix:0 MIT-MAGIC-COOKIE-1 <big long hex string>
xauth binary uses a combination of the
$DISPLAYvariable, and the
/home/.Xauthorityfile to do its thing. It will also consult an alternate
.Xauthorityfile if the
XAUTHORITYenvironment variable is set.
“The xauth program is used to edit and display the authorization information used in connecting to the X server.”The xauth man page
Accessibility to the
.Xauthorityfile relies purely on filesystem permissions, nothing more. This poses both a security risk and a usability benefit. The risk is that, if another user can read yours, and knows your
$DISPLAYvalue, they can do things to your display that you may or may not want.
This also means that root can point at anyones
.Xauthorityfile, and this is where this tip comes into play.
It’s really as simple as this:
sshinto the host you want to see X coming from, using preferably
- Once in, you should notice you have (at least) the
DISPLAYenvironment variable, and a corresponding
/home/.Xauthorityfile entry (viewable as above using
sudo -ito root; notice your
$DISPLAYshould still be there (if it’s not, your
sudoconfig is doing weird things)
- Finally, set your
XAUTHORITYenvironment variable to point back at the file for the originally-logged in user, and you’ll be good to go
Here’s an example:
jason@somehost:~$ ssh -AY email@example.com otherhost ~ $ env | grep DISPLAY DISPLAY=localhost:10.0 otherhost ~ $ xauth list otherhost/unix:10 MIT-MAGIC-COOKIE-1 <some long hex> otherhost ~ $ su - Password: root@otherhost:~# env | grep DISPLAY DISPLAY=localhost:10.0 root@otherhost:~# env | grep XAUTHORITY root@otherhost:~# logout otherhost ~ $ sudo -i [sudo] password for user: root@otherhost:~# env | grep DISPLAY DISPLAY=localhost:10.0 root@otherhost:~# export XAUTHORITY=/home/user/.Xauthority root@otherhost:~# wireshark
Isn’t this insecure?!?
It sure can be. Well, not technically insecure, but perhaps… “risky”? Alas, if you already have root, there’s a whole bunch of naughty things you could also do, so I don’t see this as any different.
It can actually be fun to prank others using this technique, but mostly, it’s just super useful.
As a “chain of trust” type thing, I see this as:
- I’ve legitimately logged in as
userhas been granted root privileges
root, I’m not breaching trust, as all I’m doing is pointing back to my normal user
So, stop trying to update your X authority and whatnot using strange pipes and echoes and bizarre
greps and for loops, and use the
XAUTHORITYenvironment variable instead!