This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: Non-admin users, /tmp/.X11-unix/X0 permissions
- From: Peter Woo <me at subnet142 dot com>
- To: cygwin-xfree at cygwin dot com
- Date: Mon, 11 Apr 2005 23:54:06 +0800
- Subject: Re: Non-admin users, /tmp/.X11-unix/X0 permissions
- References: <Pine.LNX.4.61.0504111316440.30745@ppepc56.ph.gla.ac.uk>
- Reply-to: cygwin-xfree at cygwin dot com
I guess in /usr/X11R6/bin/startxwin.bat, they circumvent the problem by
removing the .X11-unix directory at start:
:CLEANUP-FINISH
if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix
P.
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.
>
>
>