Bug 598671 - ssh -X -Y does not work with pam namespace
Summary: ssh -X -Y does not work with pam namespace
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openssh   
(Show other bugs)
Version: 6.0
Hardware: All Linux
Target Milestone: rc
: ---
Assignee: Jan F. Chadima
QA Contact: Miroslav Vadkerti
Keywords: Triaged
Depends On:
TreeView+ depends on / blocked
Reported: 2010-06-01 20:06 UTC by Daniel Walsh
Modified: 2010-11-11 14:52 UTC (History)
6 users (show)

Fixed In Version: openssh-5_3p1-18_el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-11-11 14:52:02 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
openssh-5.3p1-x11-abstract-socket.patch (1.58 KB, patch)
2010-06-23 15:46 UTC, Adam Jackson
no flags Details | Diff

Description Daniel Walsh 2010-06-01 20:06:35 UTC
Description of problem:

X Currently listens on the abstract socket


And if this fails will try to connect to 


When using pam_namespace with a variable /tmp.  /tmp/.X11-unix/X0 will not exist.

ssh client still tries to connect to this socket rather then the abstract one.

And the X on the remote machines fails with the following error.

xterm -display $DISPLAY 2>/dev/null
connect /tmp/.X11-unix/X0: No such file or directory

Also broken on F12, F13, F14

Comment 2 Jan F. Chadima 2010-06-07 09:06:28 UTC
This issue may be solved only by moving the X socket outside of the /tmp directory. Assigning to proper component.

Comment 3 Daniel Walsh 2010-06-07 14:25:24 UTC
I believe libx11 is correct.

Comment 4 RHEL Product and Program Management 2010-06-07 16:01:07 UTC
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

Comment 5 Adam Jackson 2010-06-23 15:43:32 UTC
Not in any way a libX11 bug...

Comment 6 Adam Jackson 2010-06-23 15:46:55 UTC
Created attachment 426298 [details]

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.

Comment 7 Jan F. Chadima 2010-06-24 07:12:51 UTC
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.

Comment 8 Adam Jackson 2010-06-24 17:43:54 UTC
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.

Comment 9 Jan F. Chadima 2010-06-25 12:27:04 UTC
Another version  openssh-5_5p1-16_fc14 released. Please test it.

Comment 13 Miroslav Vadkerti 2010-09-10 07:33:22 UTC
I'm not able to reproduce this problem. Dan can you give me some exact repro
steps please?

Comment 14 Daniel Walsh 2010-09-10 15:12:58 UTC
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 :^).

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

Comment 16 Miroslav Vadkerti 2010-09-13 12:15:56 UTC
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

Comment 17 Fabrice Bellet 2010-11-01 09:16:09 UTC
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

Comment 18 Maciej Żenczykowski 2010-11-08 06:40:47 UTC
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


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...]

Comment 19 Maciej Żenczykowski 2010-11-08 06:44:03 UTC
[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?)?

Comment 20 Jan F. Chadima 2010-11-08 08:58:40 UTC
The f14 is fixed in the openssh-5.5p1-23.

Comment 21 Fabrice Bellet 2010-11-08 09:12:29 UTC
(In reply to comment #20)
> The f14 is fixed in the openssh-5.5p1-23.

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

Comment 22 Maciej Żenczykowski 2010-11-08 09:34:27 UTC
$ rpm -qa | egrep openssh


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

$ rpm -qa | egrep openssh



(now if it only wasn't in testing)

Comment 23 releng-rhel@redhat.com 2010-11-11 14:52:02 UTC
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.

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