Non-admin users, /tmp/.X11-unix/X0 permissions
Hi, I have the same problem, but I have not understand the solution: wait for a new release of XWin or to change something in conf.? thank you. angelo. [EMAIL PROTECTED]
Re: Non-admin users, /tmp/.X11-unix/X0 permissions
On Tue, 26 Apr 2005, Angelo Graziosi wrote: I have the same problem, but I have not understand the solution: wait for a new release of XWin or to change something in conf.? I uploaded a new release which avoids setting the sticky bit on the directory. maybe you'll have to remove the old /tmp/.X11-unix manually. The new version should arrive soon at the mirrors. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Non-admin users, /tmp/.X11-unix/X0 permissions
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. --
Re: Non-admin users, /tmp/.X11-unix/X0 permissions
On Mon, 11 Apr 2005, Alan J. Flavell wrote: 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? You could assign each user a different /tmp path via mount mount -buf 'd:\temp\$USER' /tmp This way the files don't interfere _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. On unix the xserver is installed as setuid root and can handle those permission problems by overruling the permissions with its root permissions. On cygwin this is not possible. Does it help if the t flag is cleared? Then we could create the directory without the flag instead. I don't care for filesystem security on windows anyway. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
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.
Re: Non-admin users, /tmp/.X11-unix/X0 permissions
On Mon, 11 Apr 2005, Chuck Theobald wrote: Interestingly, the suggestion that root needs to own /tmp/.X11-unix is impossible, as root is an invalid user. This is a message left over from the unix versions of Xorg. I'm just too lazy to go through the whole get a patch into the stable branch of Xorg to address this message. If anybody cares, file a patch at bugs.freedesktop.org and fight the security considerations of the xorg board. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723