?

Log in

 
 
30 May 2008 @ 01:43 pm
xauth-user: Let another user pop up windows on your X display  
I hacked on this last week to make its output more self-explanatory, so it's dated 2008-05-24, but it's actually a year or so older than that.  xauth-user will allow user1 to utilize user2's X Windows Server display.  Once done, user2 had better completely trust user1, else user2 might get some nekkid picshurs popping up on their screen when trying to demonstrated something to his boss...

Gone are the days of running "xhost +" to allow anyone to draw a window on your X display.  Every Linux distribution I've used in the past 5 years require MIT magic cookies as authentication between an X client and the X Windows Server display.  These cookies are typically stored in ~/.Xauthority.  An X Windows Server display will read this file, and when an X client (say, xterm or firefox) wants to start up and pop up a window on the display, the X Server will challenge the X client.  Only if the X client can also read the .Xauthority file (or gets the same cookie contained therein through some other fashion)  will it pass the challenge and be allowed to pop up a window.

BTW, one user's .Xauthority files can have multiple cookies, one for each unique X display that it might utilize, e.g. :0, :1, remotehost:0, etc.

Here's an example where I'm running an X Server on display ":1".  User jdimpson is running that Server, but user sysadmin wants to pop up an xterm window on jdimpson's desktop.

BEGIN EXAMPLE
jdimpson@artoo:~$ echo $DISPLAY
:1.0
jdimpson@artoo:~$ xauth-user
usage: /home/jdimpson/bin/xauth-user <username> [X display #]
jdimpson@artoo:~$ xauth-user sysadmin :1
now you can run sysadmin's apps on jdimpson's display :1
jdimpson@artoo:~$ sudo su - sysadmin
sysadmin@artoo:~$ DISPLAY=:1 xterm &
sysadmin@artoo:~$
END EXAMPLE

Note that you have to set the DISPLAY variable to the same one you ran xauth-user on.  (xauth-user assumes :0 if you don't list it explicitly.)

BEGIN xauth-user

#!/bin/sh

if [ $# -lt 1 ]; then
        echo "usage: $0 <username> [X display #]";
        exit 1;
fi
ME=`whoami`
USER=$1;
DISP=$2;
if [ -z "$DISP" ]; then
        DISP=:0
fi

#echo copying magic cookie from $ME to $USER;
xauth nextract - $DISP | sudo su - $USER -c "xauth nmerge -"
echo now you can run $USER\'s apps on $ME\'s display $DISP;

END xauth-user

As its name suggests, it is based on xauth, which is the usual tool to hande X Server authentication (and thus to manage .Xauthority files).  It simply uses xauth on the initial user's side to spit out the correct cookie for the given display, piped into xauth on the secondary user's side.  Note that it requires that the initial user must be able to use sudo to su to the secondary user in order to access the secondary user's .Xauthority file.  The actual access to the .Xauthority files is implicit via the default behaviour of xauth.

Be very careful when using xauth-user; if you get the X display wrong, you might overwrite a magic cookie that's active in another X Server, which will make it impossible to run any new X windows.  In the above example, if you ran "xauth-user sysadmin :0" (instead of :1), and if sysadmin already has an unrelated X Server running on :0, then you'll overwrite sysadmin's active :0 cookie with jdimpson's :0 cookie (which may not be valid for anything if jdmpson is running display :1).  Screwed.  If this does happen, check out the generate section of the xauth man page to rectify this situation.  There's probably room to do some sanity checks, if I ever get around to it, at least making sure the current user isn't trying to overwrite his own currently in-use cookie.  Better yet, I could even have it save the old cookie, but that would require something to come a long later to restore it.

Final note.  xauth-user won't work for remote displays the way old "xhost +" used to (i.e. X clients could connect over the the network to display on a remote X Server), because 1) it assumes both users have local accounts with local .Xauthority files, and 2) most modern Linux distributions turn off the X Server's remote access capability anyway.  For remote X access I recommend you use SSH, making sure the X11Forwarding is turned on.