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