Xlib: connection to "sr1-ubur-20:34.0" refused by server
Alan.Coopersmith at Sun.COM
Fri Oct 23 10:05:21 PDT 2009
Alan Coopersmith wrote:
> There's two copies made at session startup - one in your $XAUTHORITY
> and one in a system directory that differs by display manager (gdm,
> xdm, kdm, dtlogin, startx, etc.) that's passed to the X server started
> (the -auth /path/to/file you can see in the arguments when running ps)
> and is usually only readable by root.
Doh! I just realized I forgot a important exception to that rule
that's probably very important to your specific case.
...is usually only readable by root unless your session was started
on Solaris by gdm or dtlogin and running a Sun provided X server,
since we have an extra patch (which I really need to get off my
todo list and into the upstream code one of these days) which has
the display manager tell the X server when a user logs in what that
user's credentials are, so the Xserver can setuid from root to that
user - and so that it doesn't lose its copy of the xauthority file
when it does so, it chowns it to that user.
So for instance, on a Solaris 10 Sun Ray server I just logged into:
alanc at sr1-ubur-20:~ [1:02pm - 2] ps -ef | grep 'X.* :24'
userX 11382 2459 0 Oct 09 ? 341:01 /opt/SUNWut/lib/Xnewt :24
-nobanner -auth /var/dt/A:24-Cbb2mb +bs -kb
alanc at sr1-ubur-20:~ [1:02pm - 3] ls -l /var/dt/A:24-Cbb2mb
-rw------- 1 userX other 44 Oct 9 13:04 /var/dt/A:24-Cbb2mb
So the user logged into the server (whose identity has been changed to
protect the innocent) could use xauth to read the cookie from that file
and put it back into their $HOME/.xauthority, or even just set
$XAUTHORITY to that file.
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
More information about the xorg