Non-admin users, /tmp/.X11-unix/X0 permissions

["Alan J. Flavell" <a dot flavell at physics dot gla dot ac dot uk>]

We have encountered a problem when different non-admin users try to 
use Cygwin/X on the same Windows system (at different times, I mean).  
This is with a standard Cygwin/X installation, as far as I can tell, 
so I'm rather surprised by how little discussion I found of this in 
the archives.

After one normal user has run Cygwin/X, the next user gets told that
s/he can't write to /tmp/.X11-unix/X0

The reason seems to be that the directory /tmp/.X11-unix has
the "t" bit set (drwxrwxrwt), which means that normal users
aren't allowed to mess with files that they don't own.

Thus, the first user creates X0 with their ownership, the "file" then 
hangs around till the second user tries to run Cygwin/X, and they get
told they can't overwrite it.

The problem can be trivially resolved by removing the "t" bit from the 
directory - but presumably that represents a security exposure?

If you want a specific release: we were chiefly using 6.8.1.0-9, but 
the problem is not confined to that release.


This item in the archives seems to be only tangentially relevant:

http://sourceware.org/ml/cygwin-xfree/2005-03/msg00058.html

whose Subject is "using cygwin/x as non-administrator doesn't work" 
(which is not exactly the problem that we are getting, since the 
*first* non-administrator has no problems starting Cygwin/X as many 
times as they want to - the problem is with the second - and 
subsequent - users).

The response in the archive is a bit vague:

| You can allow other users to write to /tmp/.X11-unix, or have a /tmp 
| directory for every user where the user can create files at will.

The first part of that would "solve" a problem that we haven't got: 
the issue is *not* that ordinary users can't write to the *directory*, 
-but- that, by virtue of the "t" bit, they can't interfere with files 
left there by someone else.  Hence this standoff with X0.

The second part of the suggestion presumably involves symlinking /tmp 
to something which has the user name in it, so that /tmp is a 
different actual path for each user?

Is there some concrete, tried-and-tested, advice for resolving this 
situation, by whatever means, please?  (And if it's entirely reliable, 
how about folding it into the released product?).

Then there's this comment in the covering mail:

| I suspect that this is due to having turned off the "Server" service 
| in XP.

What was that about, please, and could it represent an alternative 
resolution of the problem which we are experiencing?

thanks for any constructive advice.


As a secondary point, could I mention some misleading trails?

As someone had said in earlier discussion in the mail archives, it 
seems that this line in the log:

 _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root

is a red-herring and should be ignored.  And furthermore, that 
the subsequent lines

 _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
 _XSERVTransMakeAllCOTSServerListeners: server already running

represents an incorrect deduction based on the preceding error - the 
server is *not* already running.  

The system also offered us this advice, in the course of 
investigations:

 Your group is currently "mkpasswd".  This indicates that
 the /etc/passwd (and possibly /etc/group) files should be rebuilt.
 See the man pages for mkpasswd and mkgroup then, for example, run
 mkpasswd -l [-d] > /etc/passwd
 mkgroup  -l [-d] > /etc/group
 Note that the -d switch is necessary for domain users.

which, after consulting documentation and archives, we concluded 
was not a solution to our problem (albeit possibly a useful thing to 
do for unrelated reasons).

Initially, time was wasted trying to follow-up these misleading 
diagnostics in the mistaken belief that they would resolve the 
original problem - would it be feasible to at least re-word them so 
that they don't lay false trails?  But that's a side-issue.

--