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