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.

“Something lost since the dawn of a new generation of Unix/Linux users”

I went on some quick searches for this, and some/most of the answers were unnecessarily complicated — for example, here, here, or a bunch of weird, convoluted methods here.

Your simple, secure and easy method is… the environment variable XAUTHORITY.

The background

Whenever a normal X login occurs, or ssh with the -X or -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 xauthbinary:

jason@somehost:~$ xauth list
somehost/unix:0  MIT-MAGIC-COOKIE-1  <big long hex string>

The 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.

The process

It’s really as simple as this:

  1. sshinto the host you want to see X coming from, using preferably -Y
  2. Once in, you should notice you have (at least) the DISPLAYenvironment variable, and a corresponding /home/.Xauthorityfile entry (viewable as above using xauth list)
  3. Now su -/sudo -i to root; notice your $DISPLAYshould still be there (if it’s not, your sudoconfig is doing weird things)
  4. 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 user@some.other.host

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 can actually be fun to prank others using this technique”

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 user, and userhas been granted root privileges
  • As 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!