Re: .rhosts on W2K w/o ntsec
Also, the directories created by Cygwin with ntsec do have inheritance turned on. In fact that inheritance determines the ACL of files created by Cygwin when ntsec is off, and also the ACL created by most Windows applications. Incidentally you can display these stupid permissions with getfacl and change them with setfacl, so you could add Administrators if needed. Hmmm it seems as if you mis-interpreted (is this a word?) my problem: The permissions set by Cygwin with ntsec are absolutely OK. I'm having problems with permissions set by *native* Windows programs when they create files in my Cygwin home directory I just did some tests with CYGWIN=ntsec and it seems as if it's better than it used to be a year ago or so. The only thing that doesn't work is typing something like cmd /c xxx.doc to start the according application automatically if the according file is not executable but I can write a little script that looks into /proc/registry and figures out how to open a file of a given type. I'll give it a shot, convert all my files to NT security and see how it goes. Thanks again. Cheers, --Christian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: .rhosts on W2K w/o ntsec
Christian, Use cygstart docFile instead of cmd /c docFile Cygstart doesn't require the execute bit on the document file as cmd /c does. I don't know how cygstart works internally, but I imagine it looks up the association and launches the appropriate application without regard for the execute bits on the document file being opened. Randall Schulz Mountain View, CA USA At 10:42 2002-11-20, Christian Mueller wrote: ... I just did some tests with CYGWIN=ntsec and it seems as if it's better than it used to be a year ago or so. The only thing that doesn't work is typing something like cmd /c xxx.doc to start the according application automatically if the according file is not executable but I can write a little script that looks into /proc/registry and figures out how to open a file of a given type. I'll give it a shot, convert all my files to NT security and see how it goes. Thanks again. Cheers, --Christian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: .rhosts on W2K w/o ntsec
On 20-11-2002 19:51, Randall R Schulz wrote: I don't know how cygstart works internally, but I imagine it looks up the association and launches the appropriate application without regard for the execute bits on the document file being opened. Luckily, cygstart doesn't need to do such things. ;-) It just passes the filename to the ShellExecute API function, which doesn't seem to care about the execute bits. - Michael -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: .rhosts on W2K w/o ntsec
Also, the directories created by Cygwin with ntsec do have inheritance turned on. In fact that inheritance determines the ACL of files created by Cygwin when ntsec is off, and also the ACL created by most Windows applications. Incidentally you can display these stupid permissions with getfacl and change them with setfacl, so you could add Administrators if needed. Hmmm it seems as if you mis-interpreted (is this a word?) my problem: The permissions set by Cygwin with ntsec are absolutely OK. I'm having problems with permissions set by *native* Windows programs when they create files in my Cygwin home directory I just did some tests with CYGWIN=ntsec and it seems as if it's better than it used to be a year ago or so. The only thing that doesn't work is typing something like cmd /c xxx.doc to start the according application automatically if the according file is not executable but I can write a little script that looks into /proc/registry and figures out how to open a file of a given type. I'll give it a shot, convert all my files to NT security and see how it goes. Thanks again. Cheers, --Christian OK -- I tried it, converted all my files to ntsec and played around with some programs. And, I'll go right back, remove all NT-level permissions and turn off ntsec. Files saved by Windows applications such as JBuilder (actually Java but a Windows JRE) end up as follows: -r-xr-xr-x 1 root none 59486 Nov 20 20:46 MainFrame.java* Without ntsec, the file looks as it should: -rw-r--r-- 1 chris users 59486 Nov 20 20:46 MainFrame.java Furthermore, backing up the Cygwin directory to a CD with a general purpose CD writer program such as Nero doesn't work anymore because Nero can't read some of the files. Windows is not Unix and Windows programs typically don't care about file permissions (especially things like should a file be executable), thus files created by Windows programs will always end up with incorrect permissions in Cygwin with ntsec turned on. Back to the original question: Would it be possible to either (optionally) turn off the owner check in ruserok() or to respect the UID/GID values in the extended attributes if CYGWIN=ntea nontsec plus something like ntea_uid? Cheers, --Christian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: .rhosts on W2K w/o ntsec
Thanks again for your help! What do you mean setting new userids? It is safe to turn ntsec off in the /etc/profile or ~/.bash_profile sourced by the login shell. Of course the login shell itself will still have ntsec on, so it needs to reexec itself after turning ntsec off. I was thinking of daemons such as inetd, sshd, etc. setting new user IDs (contexts, whatever) after the login as such has succeeded. I didn't have the time so far to look up how Cygwin handles this case, thus my concerns about inheriting the CYGWIN envionment variable. Given your question, I take it that Cygwin will pass the CYGWIN variable to all sub-processes regardless whether or not the user ID has changed. This would rule-out my biggest concern regarding different CYGWIN variable settings for inetd clients and local logins. Another problem would be that other services which don't start shells such as the IPC daemon, apache, etc. would end up using ntsec. Not sure if that's really a problem. At any rate that can be controlled with the -e argument of cygrunsrv, but I don't know what will happen in each case. The problem with this (regardless of the -e option in cygrunsrv) is that the environment being active for the service (e.g. CYGWIN=ntsec) cannot be changed at a later time unless the service starts some shell-like process which will execute something like /etc/profile. In other words, the service will execute with ntsec being active and there's no way to turn it off. Wouldn't it be a good idea to store uid and gid in the extended attributes as well and use them if ntsec is turned off? At least for me this would be the perfect solution They are, of course, but Cygwin does not report them when ntsec is off. Changing that behavior would probably hurt other users. Asking for a special cmueller field to CYGWIN is unlikely to yield a positive reply. Hmpff! I'm not asking for any special treatment for myself. If that was the case, I would take the source and implement whatever I think would be useful instead of going to the public cygwin mailing list Having said that, I agree that it's probably dangerous to simply change the current behaviour (i.e. UIDs and GIDs are stored in EAs but not used unless ntsec is turned on as well). However, it would be possible to safely change this behaviour based on a new token (e.g. ntea_uid or whatever). I have reread your original e-mail and I don't fully understand why nontsec helps you. The reasons you give are not compelling. Even with nontsec, the files you create are not owned by Administrators. Actually, they *are* owned by Administrators *if* they are created by Windows apps. As soon as a Windows user is part of the Administrators group, all files created by this user will automatically be owned by the Administrators group (again, I'm talking about Windows apps here, not Cygwin apps). I had problems in the past (around 1 year ago) with files created by JBuilder5 from Borland -- I had ntsec turned-on at this time and ran into problems when I committed the resulting files with cvs (Cygwin) because the source files were owned by Administrators and had stupid permissions (something like 0777). I thought quite a while about a solution for my dilemma and ended up using ntea nontsec because this is the only way how I can share Cygwin directories with Windows applications without ending up changing file permissions each time Windows programs have updated/created some files. Also, the directories created by Cygwin with ntsec do have inheritance turned on. In fact that inheritance determines the ACL of files created by Cygwin when ntsec is off, and also the ACL created by most Windows applications. Incidentally you can display these stupid permissions with getfacl and change them with setfacl, so you could add Administrators if needed. Hmmm it seems as if you mis-interpreted (is this a word?) my problem: The permissions set by Cygwin with ntsec are absolutely OK. I'm having problems with permissions set by *native* Windows programs when they create files in my Cygwin home directory Is your group Administrators? If not, wouldn't it help to change it to that? Yes, it is. Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: .rhosts on W2K w/o ntsec
The reason for this is obvious: I turned off ntsec, thus the .rhosts file is owned by whoever starts rshd (probably SYSTEM because I run it as a service). I'm running Cygwin on W2K/NTFS; my CYGWIN environment variable is ntea nontsec. Have you considered leaving ntsec on in the service environment but turning it off in yours, after you get in? Pierre Thanks for the reply! Yes, I did consider it but I didn't really follow up on this idea because this would mean that all files created by subsequent processes like rsync would end up using ntsec and files being read would have the wrong permissions (i.e. from ntsec, not ntea). Unless, of course, I turn ntsec off again as soon as ruserok() has completed. The only way to do this would be in /etc/profile. Is this safe, i.e. will Cygwin see the environment changing and turn off ntsec for *all* subsequent syscalls and processes, even after forking, setting new userids, ? Another problem would be that other services which don't start shells such as the IPC daemon, apache, etc. would end up using ntsec. Wouldn't it be a good idea to store uid and gid in the extended attributes as well and use them if ntsec is turned off? At least for me this would be the perfect solution Cheers, --Christian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: .rhosts on W2K w/o ntsec
On Mon, Nov 18, 2002 at 10:50:43AM +0100, Christian Mueller wrote: Unless, of course, I turn ntsec off again as soon as ruserok() has completed. The only way to do this would be in /etc/profile. Is this safe, i.e. will Cygwin see the environment changing and turn off ntsec for *all* subsequent syscalls and processes, even after forking, setting new userids, ? What do you mean setting new userids? It is safe to turn ntsec off in the /etc/profile or ~/.bash_profile sourced by the login shell. Of course the login shell itself will still have ntsec on, so it needs to reexec itself after turning ntsec off. Another problem would be that other services which don't start shells such as the IPC daemon, apache, etc. would end up using ntsec. Not sure if that's really a problem. At any rate that can be controlled with the -e argument of cygrunsrv, but I don't know what will happen in each case. Wouldn't it be a good idea to store uid and gid in the extended attributes as well and use them if ntsec is turned off? At least for me this would be the perfect solution They are, of course, but Cygwin does not report them when ntsec is off. Changing that behavior would probably hurt other users. Asking for a special cmueller field to CYGWIN is unlikely to yield a positive reply. I have reread your original e-mail and I don't fully understand why nontsec helps you. The reasons you give are not compelling. Even with nontsec, the files you create are not owned by Administrators. Also, the directories created by Cygwin with ntsec do have inheritance turned on. In fact that inheritance determines the ACL of files created by Cygwin when ntsec is off, and also the ACL created by most Windows applications. Incidentally you can display these stupid permissions with getfacl and change them with setfacl, so you could add Administrators if needed. Is your group Administrators? If not, wouldn't it help to change it to that? Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: .rhosts on W2K w/o ntsec
On Fri, Nov 15, 2002 at 10:37:42PM +0100, Christian Mueller wrote: Hi, after updating to the latest version of Cygwin (1.3.15-1) including all other modules, rshd wouldn't accept my .rhosts file anymore because it's owned by the wrong owner. The error message is permission denied (bad .rhosts owner). The reason for this is obvious: I turned off ntsec, thus the .rhosts file is owned by whoever starts rshd (probably SYSTEM because I run it as a service). I'm running Cygwin on W2K/NTFS; my CYGWIN environment variable is ntea nontsec. Have you considered leaving ntsec on in the service environment but turning it off in yours, after you get in? Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
