X2Go Bug report logs - #505
nxproxy fails to access /tmp/.X11-unix when /tmp

Full log

🔗 View this message in rfc822 format

X-Loop: owner@bugs.x2go.org
Subject: Bug#505: Fwd: [Bug 1101726] New: x2goclient fails on hosts using polyinstantiated /tmp directories
Reply-To: Orion Poplawski <orion@cora.nwra.com>, 505@bugs.x2go.org
Resent-From: Orion Poplawski <orion@cora.nwra.com>
Resent-To: x2go-dev@lists.x2go.org
Resent-CC: X2Go Developers <x2go-dev@lists.x2go.org>
X-Loop: owner@bugs.x2go.org
Resent-Date: Tue, 27 May 2014 19:45:02 +0000
Resent-Message-ID: <handler.505.B.140121962521374@bugs.x2go.org>
Resent-Sender: owner@bugs.x2go.org
X-X2Go-PR-Message: report 505
X-X2Go-PR-Package: x2goclient
X-X2Go-PR-Keywords: 
Received: via spool by submit@bugs.x2go.org id=B.140121962521374
          (code B); Tue, 27 May 2014 19:45:02 +0000
Received: (at submit) by bugs.x2go.org; 27 May 2014 19:40:25 +0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
	ymir.das-netzwerkteam.de
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID,
	URIBL_BLOCKED autolearn=ham version=3.3.2
Received: from mail.cora.nwra.com (mercury.cora.nwra.com [4.28.99.165])
	by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id BDE683D166
	for <submit@bugs.x2go.org>; Tue, 27 May 2014 21:40:24 +0200 (CEST)
Received: from [10.10.20.7] (barry.cora.nwra.com [10.10.20.7])
	(authenticated bits=0)
	by mail.cora.nwra.com (8.14.4/8.14.4) with ESMTP id s4RJeN38016194
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
	for <submit@bugs.x2go.org>; Tue, 27 May 2014 13:40:23 -0600
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cora.nwra.com;
	s=default; t=1401219623;
	bh=LyKtNgv5SUZB0/CSb6BMnyAoUXfJTqxnkibaOktbW3A=;
	h=Message-ID:Date:From:MIME-Version:To:Subject:References:
	 In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=ciGA566IPHuyWHpAUAHo5utaJF5hdk0O+vJQ8aeiriCPEuuQ8ixOFIZeIJn7Rmpez
	 2raCFUCBchwO6I3asFAdZVffw+V7QOxdWBEENFaDP/WfGvnW5IMFXYKd5FkZY7PfsQ
	 +/i7thT/NIUCz61q/H2YeoOnrzh5wk9BtJo0UsDk=
Message-ID: <5384EA27.8010303@cora.nwra.com>
Date: Tue, 27 May 2014 13:40:23 -0600
From: Orion Poplawski <orion@cora.nwra.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: submit@bugs.x2go.org
References: <bug-1101726-140047@bugzilla.redhat.com>
In-Reply-To: <bug-1101726-140047@bugzilla.redhat.com>
X-Forwarded-Message-Id: <bug-1101726-140047@bugzilla.redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Package: x2goclient


-------- Original Message --------
Subject: [Bug 1101726] New: x2goclient fails on hosts using polyinstantiated 
/tmp directories
Date: Tue, 27 May 2014 19:38:53 +0000
From: bugzilla@redhat.com
To: orion@cora.nwra.com

https://bugzilla.redhat.com/show_bug.cgi?id=1101726

            Bug ID: 1101726
           Summary: x2goclient fails on hosts using polyinstantiated /tmp
                    directories
           Product: Fedora EPEL
           Version: el6
         Component: x2goclient
          Assignee: orion@cora.nwra.com
          Reporter: rgm+rh@gnu.org
        QA Contact: extras-qa@fedoraproject.org
                CC: orion@cora.nwra.com



Hi,


Description of problem:

This is like bug#1100985, but whereas that was an issue with x2goserver, this
is an issue with the client.

If the host on which the client runs has enabled polyinstantiated /tmp
directories as per

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/polyinstantiated-directories.html

then x2goclient cannot connect to anywhere (even if the host that it tries to
connect to has a "normal" /tmp). It seems it cannot find the /tmp/.X11-unix/X0
socket on the local host. It should be able to work with X's abstract namespace
socket rather than requiring the old filesystem socket.


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

x2goclient-4.0.1.4-1.el6.x86_64
RHEL 6.5


How reproducible:

100%


Steps to Reproduce:
1. Uncomment the line in /etc/security/namespace.conf that reads:
#/tmp     /tmp-inst/           level      root,adm

Apply the workaround from bug#1100985 so that /tmp/.X11-unix gets created
in the user's /tmp directory (or for testing simply create it by hand with the
right permissions).

2. Start a new desktop session as a normal user. Observe that /tmp/.X11-unix/X0
does not exist in that user session.


3. Try to connect anywhere using x2goclient.


Actual results:

x2go fails with a message of the form:
   ServerProxy: WARNING! Connection to ':0.0' failed with error 'No such file
or directory'.


Expected results:

x2go works.


Additional info:

There seems to be no clean way to fix this. RHEL5 had some commented-out
example code in /etc/security/namespace.init that was designed for this kind of
problem:

# If you intend to polyinstantiate /tmp and you also want to use the X windows
# environment, you will have to use this script to bind mount the socket that
# is used by the X server to communicate with its clients. X server places
# this socket in /tmp/.X11-unix directory, which will get obscured by
# polyinstantiation. Uncommenting the following lines will bind mount
# the relevant directory at an alternative location (/.tmp/.X11-unix) such
# that the X server, window manager and X clients, can still find the
# socket X0 at the polyinstanted /tmp/.X11-unix.
#
#if [ $1 = /tmp ]; then
#       if [ ! -f /.tmp/.X11-unix ]; then
#               mkdir -p /.tmp/.X11-unix
#       fi
#       mount --bind /tmp/.X11-unix /.tmp/.X11-unix
#       cp -fp -- /tmp/.X0-lock "$2/.X0-lock"
#       mkdir -- "$2/.X11-unix"
#       ln -fs -- /.tmp/.X11-unix/X0 "$2/.X11-unix/X0"
#fi


By experiment, this does not seem to work in RHEL6. It seems that when the
namespace.init script runs, the real /tmp is already hidden.

If you run the bind mount part at startup, then just make the link in
namespace.init, it seems to work, but this is rather ugly.
It would be better if x2go would just work. It seems that other X applications
were fixed in RHEL6 to not need the workaround.
See eg bug#598671, which says that applications should look for X's abstract
namespace socket first, before falling back to the old filesystem socket
/tmp/.X11-unix/X0.

Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

Send a report that this bug log contains spam.