Red Hat Bugzilla – Bug 65590
The enviroment variable XAUTHORITY carries over su - username
Last modified: 2007-04-18 12:42:47 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.3 (X11; Linux i686; U;) Gecko/20020523 Description of problem: I would like to be able to login as a normal user. Open a terminal window, su to root, copy .Xauthority from the home directory of the user I logged in as to another user, then su to that user and be able to run graphical programs. Currently, $XAUTHORITY will = /home/<insert original username here>/.Xauthority Since the other user doesn't have access to the original user's home directory this fails with permission denied. Even if the second user did have permission to the directory .Xauthority's permissions are by default set to 600. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. init 5 2. Login as normal user 3. Open terminal window 4. su - root 5. cp -a /home/<insert original username here>/.Xauthority /home/<insert second username here> 6. chown <insert second username here>.<insert second username here> /home/<insert second username here>/.Xauthority 7. su - <insert second username here> 8. xterm Actual Results: Xlib: connection to ":0.0" refused by server Xlib: No protocol specified xterm Xt error: Can't open display: :0 Expected Results: No error messages and xterm pops up Additional info:
I don't see the usefulness of su'ing to root, and then su'ing to other users accounts from there and running graphical programs. At least not as a remotely high priority thing. I don't really consider this a bug, but more of a low priority feature enhancement request.
I can understand why you might see it low priority. I found a better way to do the same thing. I had tried something like it before, but not in exactly the same way. The manpage for xauth mentions xauth extract - $DISPLAY | rsh otherhost xauth merge - which can be redone as xauth extract - $DISPLAY | ssh user@localhost /usr/X11R6/bin/xauth merge - You run this as the first user and replace user with the username of the second user. This will copy the hostname/unix:0 entry. It would probably be better if it copied both, but it seems to work with just this one. The downside for me is that I don't want to have to set a password for the second user(aka account only accessiable by su - user as root). The reason is that it is the code compiler user(Thanks mharris for suggesting your rpmbuild-nonroot hack :) ) and so it just makes security worse to give it a password. But even after using this more direct method the XAUTHORITY environment variable is set wrong when you su - user from the first user. In X I no of no other way to become another use than su. Outside of X, using ctrl-alt-f1, login as second user, export DISPLAY=:0, xterm is too much hassle.
I thought of a simple workaround. I can add XAUTHORITY=$HOME/.Xauthority export XAUTHORITY to ~/.bash_profile
The whole point of this is to avoid the the horribly insecure xhost +hostname if the system has more than one person can login at a time.
The also could relate as a secure workaround for bugs like the one where you must give root permission to your X session to be able to run Xcdroast from the menu using consolehelper. The standard workaround is xhost +locahost, but as mentioned above that is insecure.
Closing WONTFIX as I dont see any problem here. If there is a problem, it should be reported and fixed by XFree86.org on xpert@xfree86.org mailing list. At a minimum, someone who understands xauthority information a LOT more, needs to be a part of looking at this. Making random uninformed changes to things is never good.