Single file version available here.
Last updated on 2008-06-06.
To discuss, comment here.
| Next |
Table of Contents
http://www.debian-administration.org/articles/494
X authentication is based on cookies — secret little pieces of random data that only you and the X server know… So, you need to let the other user in on what your cookie is. One way to do this is as follows:
Before you issue the su or sudo (but after having ssh'ed into the remote system), request the cookie for the current DISPLAY that's connecting to your X server:
$ xauth list $DISPLAY
You'll get something like
somehost.somedomain:10 mit-magic-cookie-1 4d22408a71a55b41ccd1657d377923ae
Then, after having done su, tell the new user what the cookie is:
$ xauth add somehost.somedomain:10 MIT-MAGIC-COOKIE-1 4d22408a71a55b41ccd1657d377923ae
(just copy'n-paste the output of the above 'xauth list' onto 'xauth add') That's it. Now, you _should_ be able to start any X application.
documented on: 29 Jan 2007, daveseff
I don't believe the timing of this article! :)
I'd been struggling with this recently:
I can't login as user B directly on a Solaris box.
I login as user A, then su to B. Of course, X forwarding stops working. And I need X working to install some proprietary software.
Then I see this article that explains precisely how!
Another technique I discovered recently (after getting stuck on a SLES system with no sux packages) is to set the XAUTHORITY environment variable to $USER/.Xauthority (where $USER is the username you ssh'd in as).
You can use the sux package too (with the command of the same name).
similarly there is a gksu package that provides gksu and gksudo.
> will the trick works on chroot as well, provided everything eg /dev /proc > are properly bind mounted?
Yep, it works, after I bind mount /tmp as well!
> $ xauth list > > seems to takes years to report the cookie...
That's because some left-over cookies, try specify which cookie to list:
xauth list somehost.somedomain:10
T
#Asssuming you did ssh -X user@hostname
# Gain root privileges, su -
# and merge the Xauth information like this: xauth merge /home/user/.Xauthority
Beno
> Another really really simple alternative is to ssh again to root@localhost.
I didn't say anything about root. Root is easy. You usually can run 'sudo xapplication' and be happy with that. As an administrator, which is what this site is about, sometimes you have to help troubleshoot things for other users and you need to 'sudo su - username' to see the problem from their perspective. When you sudo su, or su in general you loose your DISPLAY and Xauth settings.
documented on: 29 Jan 2007, daveseff