Bug 25871 - SSH, su and xauth don't play well together
SSH, su and xauth don't play well together
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: openssh (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-03 11:30 EST by Yaron Minsky
Modified: 2007-04-18 12:31 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-03 03:30:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Yaron Minsky 2001-02-03 11:30:15 EST
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
Comment 1 Pekka Savola 2001-02-03 19:59:33 EST
This is rather annoying :-/ but not trivial to fix properly.
Comment 2 David Woodhouse 2001-02-21 10:27:29 EST
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;
Comment 3 Nalin Dahyabhai 2001-03-09 15:05:50 EST
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.
Comment 4 Tomas Mraz 2005-02-03 03:30:59 EST
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.

Note You need to log in before you can comment on or make changes to this bug.