Bug 61087 - XAUTHORITY is not set by su in openssh session
Summary: XAUTHORITY is not set by su in openssh session
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: openssh   
(Show other bugs)
Version: 7.2
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-03-13 13:39 UTC by jorma.laaksonen
Modified: 2007-04-18 16:40 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-03 15:20:28 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description jorma.laaksonen 2002-03-13 13:39:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.17 i686)

Description of problem:
This used to work:

machine1 %> ssh machine2
machine2 %> su
machine2 #> xeyes

But now I get an error:

X connection to localhost:10.0 broken (explicit kill or server shutdown).

To me it seems that XAUTHORITY environment variable is not set
by su and therefore /root/.Xauthority file is used.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Log in from a remote machine
2. xeyes
3. su
5. xeyes

Actual Results:  2. xeyes works
4. XAUTHORITY : undefined variable
5. X connection to localhost:10.0 broken (explicit kill or server shutdown).

Expected Results:  4. /root/.xauthxxxxx
5. xeyes should work

Additional info:

$DISPLAY is set correctly to localhost:10.0 for both me and root.

root #> xauth -v list
xauth:  creating new authority file /root/.Xauthority
Using authority file /root/.Xauthority


Comment 1 Pamela Fong 2002-03-14 04:43:41 UTC
I'm running RedHat 7.1, 2.4.9-31.  I had upgraded to OpenSSH_3.1p1 by
installing the RPMs, and this broke the X11 forwarding.  I worked around
the problem by creating the file,


having contents,

  OPTIONS="-o 'X11UseLocalhost no'"

and then I ran

  /etc/rc.d/init.d/sshd restart


Comment 2 James Ralston 2002-03-15 06:55:19 UTC
What Pam said: you need to set the "X11UseLocalhost" option to "no".

The problem is that lots of X11 programs will make very aggressive optimizations
about what constitutes a "local" (versus TCP/IP) X11 transport.  A DISPLAY value
of ":10.0" always means "use local transport" (the /tmp/.X11-unix/X0 unix
socket).  A DISPLAY value of "hostname:10.0" usually means "use TCP/IP", but
some X11 applications are too smart for their own good, and will optimize
"localhost:10.0" (or to just ":0.0" and attempt to use local
transport.  Such apps then fail, because when forwarding the X11 protocol, the
sshd on the remote machine doesn't listen on the /tmp/.X11-unix/X0 socket; it
only listens on the TCP port.

IMO, it's completely stupid that the OpenSSH developers added this "feature". 
They did it because people were whining about the fact that when you forwarded
an X11 connection to a remote machine, sshd was listening on *:6010 (port 6010
on all interfaces).  That meant that anyone who could reach TCP port 6010 on the
remote machine could connect to sshd's X11 forwarding listener and try to attack
the X server of the machine you connected from (by trying to guess the magic
cookie for sshd's forwarder).

The *correct* solution is to tell people not to forward X11 connections to
remote machines that don't firewall the X11 display port ranges, or are
otherwise insecure.

Besides, even with the X11UseLocalhost "feature", people logged into the remote
machine can still try to attack your local X server through sshd listening on
the loopback.  So this "feature" is doubly stupid.

A suggestion for Red Hat: put "X11UseLocalhost no" in the /etc/ssh/sshd_config
by default.

Comment 3 John Dalbec 2002-07-11 19:50:34 UTC
X11UseLocalhost is broken in that the DISPLAY=localhost:10.0 but the key in .Xauthority is for the display :10.0.  Some X programs optimize away the localhost and 
find the correct key, but pam_xauth does not.  This is why su'ing doesn't work.
[jpdalbec@<client> jpdalbec]$ ssh -X <server>
jpdalbec@<server>'s password: 
Last login: Thu Jul 11 03:10:48 2002 from <client>
[jpdalbec@<server> jpdalbec]$ export DISPLAY=:10.0
[jpdalbec@<server> jpdalbec]$ su
[root@<server> jpdalbec]# xeyes
Error: Can't open display: :10.0
[root@<server> jpdalbec]# export DISPLAY=localhost:10.0
[root@<server> jpdalbec]# xeyes
(xeyes appears on the client)

Comment 4 Tomas Mraz 2005-02-03 15:20:28 UTC
It works fine with the current Fedora Core.

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