X server authority only allows local connections even if xserver-allow-tcp=true

Bug #1206533 reported by Bevis King
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Light Display Manager
Triaged
Low
Unassigned
lightdm (Ubuntu)
Triaged
Low
Unassigned

Bug Description

I'm currently working on configuring Ubuntu 12.04 Linux to match our user environment - one of the aspects I'm working on is enabling X11 over TCP as we have a large number of graphical applications running on local (same-subnet) compute server systems. Encrypting the X11 stream between clients and servers on the same physical network switch inside a secured floor of offices seems like insanity to me.

I've obviously configured Lightdm to start the Xorg X11 server with TCP mode connections enabled, but the -auth argument (which I assume is provided by lightdm) points to a file called /var/run/lightdm/root/:0. Despite the TCP mode connection being enabled, the only MIT-MAGIC-COOKIE-1 key that is placed within this file includes the "hostname/unix:0" specification which limits it's use to Unix domain sockets only.

What I need to do is to have lightdm (assuming it is lightdm that is creating this authorisation file) create it with simply "hostname:0" so that the MIT-MAGIC-COOKIE-1 key may be used on X11 over TCP connections as well as those over X11 over Unix Domain socket connections.

I have confirmed that extracting the key from the :0 file using Xauth -f :0 list followed by a correspondingly altered re-insertion of the key without the /unix part using Xauth -f :0 add ... command does indeed work.

My first question is whether there is something I've missed in the lightdm configuration file that would allow me to specify that I want the MIT-MAGIC-COOKIE-1 enabled for both TCP and Unix domain connections?

The second point which follows on from that is whether when allowing TCP connections to the Xserver, maybe lightdm SHOULD remove the /unix element from the MIT_MAGIC-COOKIE-1 stored in the :0 file. It would seem to me to be logical that it should.

And the final point is seeking advice on the best recommended way to work around this problem for the time being. I assume I could do the xauth list/xauth add steps within the display-setup-script if necessary. Is this the best place to do it?

Thanks in advance for your help.

Description: Ubuntu 12.04.2 LTS
Release: 12.04

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: lightdm 1.2.3-0ubuntu2.3
ProcVersionSignature: Ubuntu 3.2.0-49.75-generic 3.2.46
Uname: Linux 3.2.0-49-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.0.1-0ubuntu17.3
Architecture: amd64
Date: Tue Jul 30 15:16:52 2013
MarkForUpload: True
ProcEnviron:
 LANGUAGE=en_GB:
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/csh
SourcePackage: lightdm
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Bevis King (b-king-surrey) wrote :
Revision history for this message
Bevis King (b-king-surrey) wrote :

I've created the following script which does the necessary - I've called it enabletcp and placed it in /etc/lightdm:

#/bin/sh
#
# enable TCP mode MIT-MAGIC-COOKIE-1
#
HOSTNAME=`hostname`
COOKIE=`(cd /var/run/lightdm/root; xauth -f :0 list | grep "$HOSTNAME/unix")`
CLEANED=`echo $COOKIE | sed -e 's/\/unix//'`
(cd /var/run/lightdm/root; xauth -f :0 add $CLEANED)
exit 0

and I've added:
display-setup-script=/etc/lightdm/enabletcp

to the /etc/lightdm/lightdm.conf file.

Changed in lightdm (Ubuntu):
status: New → Triaged
importance: Undecided → Wishlist
Changed in lightdm:
status: New → Triaged
importance: Undecided → Wishlist
importance: Wishlist → Medium
Changed in lightdm (Ubuntu):
importance: Wishlist → Medium
summary: - Removing the /unix specification from the /var/run/lightdm/root/:0 file
+ X server authority only allows local connections even if xserver-allow-
+ tcp=true
Changed in lightdm:
importance: Medium → Low
Changed in lightdm (Ubuntu):
importance: Medium → Low
Revision history for this message
Robert Ancell (robert-ancell) wrote :

To the first question, there is no configuration that allows the MIT-MAGIC-COOKIE to be set to allow remote connections.

Agreed, it seems logical that it should at least be possible to make the cookie available to remote connections if the sysadmin has chosen to use that method. I'm trying to remember why it isn't like that - I think it was done the way it is currently to match existing display servers and it's not good practise to use MIT-MAGIC-COOKIE (the encryption would be a very small overhead).

Correct, the display-setup-script is probably the right place to add additional authentication.

Revision history for this message
Bevis King (b-king-surrey) wrote :

Providing the X server is allowing TCP domain connections and accepts the MIT-MAGIC-COOKIE-1 over TCP connections, getting the MIT-MAGIC-COOKIE-1 to the remote host is relatively easy. The xauth on the console host can see the MIT-MAGIC-COOKIE-1 and can be used to copy it into the .Xauthority file in the users home directory. Thereafter remote applications will automatically pick it up from the user's (NFS shared) home directory on any other hosts they need to use.

We have seen many of our applications where the overhead of the encryption is simply massive and combined with the latency of the continuous context switching to the SSH process to encrypt the data becomes utterly unacceptable. Granted one particular application involves synchronising video feeds from multiple video camera captures performed by multiple hosts but in this and other roles X11 is up to the task; tunnelled/encrypted X11 is far too slow and is not suitable for purpose.

Regards, Bevis.

Revision history for this message
Robert Ancell (robert-ancell) wrote :

Thanks for the data point on the use of encryption!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.