Exporting X authorization to another user

On my machine, I have a special user account for when I want to make tests. Sometimes, I’d like to run a command under this account while I’m working in my X desktop, without switching desktop.

Please note that this article is not oriented toward people unfamiliar with Unix.

As an example, let’s say we want to run an X terminal under the ‘test’ user account.

kdesu

One way to do this under KDE is to use kdesu:

kdesu -u tester -c xterm

OK, that’s ok when you use KDE. I suppose that gnome has an equivalent solution. It’s by far the easiest solution, but isn’t always what you want:

• You need to have KDE installed to use it.
• It works only on the same computer
• It asks for your ‘test’ password every time

SSH

Another solution is to use SSH, and its X forwarding capability:

ssh -X test@localhost xterm

Just by replacing ‘localhost’ by another host, you can execute a remote application which will use your Xterminal. In addition, all your communications between the two hosts will be encrypted.

In a default setup, you’ll still have to enter your password everytime you launch this command, but ssh-agent can help you. I won’t detail the use of SSH agent, since its already quite well documented. I’ll just note here that I’ve added a desktop entry to my KDE Autostart directory ( ~/.kde/Autostart by default in Ubuntu). For KDE new users, a desktop is encapsulates a command, some options, the name of the icon,… I’ve just create a file name ~/.kde/Autostart/ssh-add.desktop with the next content:

[Desktop Entry]
Encoding=UTF-8
Exec=ssh-add ~/.ssh/id_dsa.priv
StartupNotify=true
Terminal=false
Type=Application
ssh -X test@localhost xterm

The easiest way to create this file is through a right click in the appropriate folder, and selecting ‘Create a new link to an application’.

With this, when your KDE session starts, it requests your password, and remembers it until you close your sessions (strictely speaking, it doesn’t remember your password, but it uses it to decode your DSA key, which is stored in memory. I won’t enter in those details here, neither on how to create your DSA key in the first place.

One drawback of this solution is that if the executed application is graphically intensive, you will notice that it is slowed down by the encryption. When working on the same machine, there’s really no need to encrypt all the communcation.

xauth

Most of the time the above solution is the easiest one. However, sometimes, I need to allow any program running under the test account to use my display as it fits (beware that this also allows that account to make, for example, an screen shot of my display and save it, hence reading my mails,…)

For this, I use the next command:

xauth extract - $DISPLAY | ssh test@localhost "xauth merge -; DISPLAY='$DISPLAY' xterm"

What does this do?

• The first xauth command extract authorization information from the X server. With this information, nearly anybody can connect to your X display (anybody on your local machine, and also anybody on a remote machine if they have network connectivity (no firewall,…) AND your X server is listening to network connection (google for XDMCP))

). This information is sent to the standard output of the command.

• The standard output of xauth is sent to the user account of user ‘test’ (on localhost, the same machine, in this example). The SSH client running with my ID connects to the SSH server, authenticate to it (without requesting again my password, thanks to ssh-agent). The SSH server runs the second ‘xauth’ command with user ID ‘test’, and gives it the authorization information which was forwarded to it through SSH.
• The second xauth command merges this information with the one eventually already present for user ID ‘test’
• The last ‘xterm’ command is executed, still with user ID ‘test’, and sends a X terminal

For this last point, how does the X-Terminal know which X server it should contact? It knows that through the $DISPLAY variable. Note the tricky part of the above line: since the $DISPLAY is surrounded by double-quotes, it will be evaluated by *my* shell, not the one running under user ID test. The command will therefore become, after shell evaluation:

xauth extract - $DISPLAY | ssh test@localhost "xauth merge -; DISPLAY=':0' xterm"

Note that with this solution, only the transmission of the autorization information is encrypted. After that, all communication is made directly without encryption, and without SSH, between your xterm program (and the subprocesses that it could launch) and your X server.