Re: .rhosts on W2K w/o ntsec

Re: .rhosts on W2K w/o ntsec

[Christian Mueller]

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

[Pierre A. Humblet]

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

[Christian Mueller]

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

[Michael Schaap]

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

[Randall R Schulz]

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

[Christian Mueller]

>  > 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 Mueller]

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

[Pierre A. Humblet]

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/

.rhosts on W2K w/o ntsec

[Christian Mueller]

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

Would it be possible to add something to the CYGWIN environment 
variable which prevents 'ruserok()' from verifying the owner of the 
.rhosts file? Or, even better, would it be possible to store the 
file's owner and group in the extended attributes as well and use this 
in case ntsec is turned off?

The reasons why I don't want to use ntsec are:

- I'm running Cygwin on a laptop and have to be part of the 
administrative group in order to prevent closing down everything to 
login as Administrator every time I plugin to client networks, etc. 
The "Run as..." option in W2K is only covering half of the issues I'm 
coming across. As a result, all Windows files are created with the 
admin group as owner while Cygwin creates files with my login as owner.

- I'm sharing the home directory between Cygwin and Windows 
applications and Windows applications create new files with rather 
stupid permissions when inheritance is turned off (as is the case with 
Cygwing directories with ntsec turned on)

When I forget to re-set the owner and permissions settings before 
running "cvs commits" or similar, the chaos is complete....

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/