From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18)
This is an old problem, and is perhaps not considered a bug. Basically, if
I SSH into a redhat machine, X works fine. If, however, I then su to root,
I can no longer use X. This is a problem with the inheritance of
xauthority files. Changing the XAUTH variable manually to whatever SSH set
the user's XAUTH variable to fixes the problem.
Steps to Reproduce:
1. SSH to machine
2. su to root
3. try to launch any X application
This is rather annoying :-/ but not trivial to fix properly.
Is there any particular reason for it to use a different xauthority file instead
of ~/.Xauthority? This is also fairly annoying for setups with shared home
directories where you just want to use 'ssh otherhost xprogram -display $DISPLAY
\&' and have the program connect directly to your display.
--- session.c~ Wed Feb 21 15:24:50 2001
+++ session.c Fri Feb 16 23:14:25 2001
@@ -354,6 +354,7 @@
if (s->display == NULL)
/* Setup to always have a local .Xauthority. */
xauthfile = xmalloc(MAXPATHLEN);
strlcpy(xauthfile, "/tmp/ssh-XXXXXXXX", MAXPATHLEN);
@@ -373,6 +374,7 @@
success = 1;
Presumably /tmp is on a local disk, which will prevent the xauthority file's
contents from being sent over the network in the clear (for example if you're
using NFS). There's obviously something more to this, but I'm consistently
unable to reproduce this bug.
This works fine in the current Fedora Core releases. It's work of
pam_xauth module to copy the authority keys when su'ing. Note however
that when su'ing from root to an user the authority keys aren't
copied. This is intentional because it would be a high security risk
to allow unprivileged user to access root's display.