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

[Chuck Theobald]

This one bit me as well when trying to set up WinXPSP2 machines for a lab 
environment.  The solution I settled on was to use Windows Security 
settings to grant "Everyone" "Full Control" over c:\cygwin\tmp.  This 
works.  I too wasted time chasing down the suggestions and searching in 
vain in the archives.  The mkgroup/mkpasswd thing does not work if you are 
not an Administrator, and even so, mkpasswd fails with a "mkpasswd (257): 
[1745] The procedure number is out of range."

Interestingly, the suggestion that root needs to own /tmp/.X11-unix is 
impossible, as root is an "invalid user".

Chuck


At 05:57 AM 4/11/2005, Alan J. Flavell wrote:

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

Chuck Theobald
System Administrator
The Robert and Beverly Lewis Center for Neuroimaging
University of Oregon
P: 541-346-0343
F: 541-346-0345