From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20010202 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. Reproducible: Always 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) break; +#if 0 /* Setup to always have a local .Xauthority. */ xauthfile = xmalloc(MAXPATHLEN); strlcpy(xauthfile, "/tmp/ssh-XXXXXXXX", MAXPATHLEN); @@ -373,6 +374,7 @@ close(fd); restore_uid(); fatal_add_cleanup(xauthfile_cleanup_proc, NULL); +#endif success = 1; break;
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.