Bug 598671

This issue may be solved only by moving the X socket outside of the /tmp directory. Assigning to proper component.

I believe libx11 is correct.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Not in any way a libX11 bug...

Created attachment 426298 [details]
openssh-5.3p1-x11-abstract-socket.patch

This is an openssh bug.  The ssh client connects to the X server on the local machine, and only looks for the filesystem socket when it does so.  It needs to look for the abstract namespace socket first.

Attached patch (not even compile-tested) probably works.

Solved by changing _PATH_UNIX_X to a nonexistent path. Please may you test it under rawhide openssh-5_5p1-15_fc14 before I push it to the other versions.

That's really not the right thing.  That'll break forwarding to X servers launched with -nolisten tcp, which is the default for gdm.

The patch I posted is the same technique libX11 uses: try the abstract socket first, fall back to the filesystem socket if it doesn't exist.

Another version  openssh-5_5p1-16_fc14 released. Please test it.

I'm not able to reproduce this problem. Dan can you give me some exact repro
steps please?

Setup pam_namespace for your account,  On my machine I do this with this file.

# cat /etc/security/namespace.d/dwalsh.conf 
# Inserted by the xguest package.
/tmp    tmpfs   tmpfs   ~dwalsh

Then if you are running with SELinux (And I am sure you are :^).
Execute

setsebool -P allow_polyinstantiation 1

Log out and log back in.  Now your /tmp should be different from roots.

The best way to see this would be to ssh into the box as root and create a file in /tmp.  Then ssh into the box as a normal dwalsh, and you do not see the file.  You should see nothing in /tmp.

Now try to ssh -X -Y as the user

Thanks Dan for the reproducer!

VERIFIED as fixed in openssh-5.3p1-20.el6

NEW package openssh-5.3p1-20.el6.x86_64
$ xterm 
Warning: Cannot convert string "nil2" to type FontStruct
xterm: cannot load font -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
[xterm launches fine]

OLD package openssh-5.3p1-14.el6.x86_64
$ xterm 
connect /tmp/.X11-unix/X0: No such file or directory
xterm Xt error: Can't open display: localhost:10.0

In F-14, the first connect_local_xsocket_path() added by the patch causes a systematic error message:

[bellet@helix ~]$ ssh -X bonobo xload
connect : Connection refused

Here is the related strace:

3862  socket(PF_FILE, SOCK_STREAM, 0)   = 7
3862  connect(7, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, 110) = -1 ECONNREFUSED (Connection refused)
3862  close(7)                          = 0
3862  write(2, "connect : Connection refused\r\n", 30) = 30
3862  socket(PF_FILE, SOCK_STREAM, 0)   = 7
3862  connect(7, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 110) = 0
3862  fcntl(7, F_SETFD, FD_CLOEXEC)     = 0
3862  ioctl(7, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8346ae80) = -1 EINVAL (Invalid argument)
3862  fcntl(7, F_GETFL)                 = 0x2 (flags O_RDWR)
3862  fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK) = 0
[...]

Agreed, seeing the same thing on an upgrade from F13 to F14.

Xterm on 'nike' running ssh to 'varda':

---
[maze@varda ~]$ xprop -root _NET_DESKTOP_GEOMETRYconnect : Connection refused

_NET_DESKTOP_GEOMETRY(CARDINAL) = 4000, 1600
---

strace of ssh on 'nike' gives:

socket(PF_FILE, SOCK_STREAM, 0)         = 7
connect(7, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, 110) = -1 ECONNREFUSED (Connection refused)
close(7)                                = 0
write(2, "connect : Connection refused\r\n", 30) = 30
socket(PF_FILE, SOCK_STREAM, 0)         = 7
connect(7, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 110) = 0

[maze@nike ~]$ ls -al /tmp/.X11-unix/X0 
srwxrwxrwx. 1 root root 0 Nov  7 20:10 /tmp/.X11-unix/X0

'connect : Connection refused' shows up everytime you launch an X client.

I'm just pointing out that this error message is very annoying.  And adding myself to the CC list for this bug.

[I'm not convinced that having separate tmp's for root and myself is desirable for 'nike' which is a single-user laptop - would that even fix this? the above chatter leads be to believe that it might...]

[this bug is against RHEL6/openssh and marked VERIFIED, should a NEW bug be opened for F14/openssh? or should this one be reopened and/or moved to F14?]

Maybe the fix would simply be to not print the error message on the first connect failure (ie. only print it if both connect to abstract and non-abstract fail?)?

The f14 is fixed in the openssh-5.5p1-23.

(In reply to comment #20)
> The f14 is fixed in the openssh-5.5p1-23.

ACK : it works for me in F-14. thanks!

$ rpm -qa | egrep openssh
openssh-clients-5.5p1-22.fc14.2.x86_64
openssh-server-5.5p1-22.fc14.2.x86_64
openssh-5.5p1-22.fc14.2.x86_64
openssh-askpass-5.5p1-22.fc14.2.x86_64

Broken.

$ sudo yum --enablerepo=updates-testing update openssh\*

$ rpm -qa | egrep openssh
openssh-server-5.5p1-23.fc14.2.x86_64
openssh-5.5p1-23.fc14.2.x86_64
openssh-clients-5.5p1-23.fc14.2.x86_64
openssh-askpass-5.5p1-23.fc14.2.x86_64

Fixed.

Yay!

(now if it only wasn't in testing)

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.