This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]