This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin 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: Minor ntsec fixes and optimizations.


At 12:53 PM 1/29/2003 -0500, Christopher Faylor wrote:
>Btw, do either of you (Pierre, Corinna) have any insight into the recent
>cygwin mailing list thread where people were complaining about still
>having ntsec issues?  Do you know what that was all about?  This was
>in the "cygwin Release process" thread.

Chris,

I saw the following sentence:
>The "ntsec" problem by all accounts was a one-time switch 
> that burned a lot of people.  It's STILL not resolved...

but it's not clear (to me) what's not resolved.
This is my take on ntsec problems. Feel free to add:

1) The biggest hurdle is the need for a correct passwd file. 
That's a problem mainly for domain users, probably because of
the post-install script. I have made suggestions there (use
mkpasswd with new -c switch).

2) There is a recurrent problem with HOME. People don't understand
how it is set. That should be in the FAQ. Cygwin rules are:
- starting from Windows
1) HOME from Windows environment
2) /etc/passwd
3) HOMEDRIVE/HOMEPATH from Windows environment
4) /
- starting from network 
1) /etc/passwd
2) /
(the rule to fall back to 2) depends on the daemon)

3) There is the sometimes incorrect display of permissions on files
installed by setup. I have sent a patch that should improve the 
situation.

4) There the Christian Mueller problem with displaying the permissions
of files created by Windows applications in cygwin directories. 
Improvements were made, still waiting for more specific feedback. 

5) There is the Jurgen Defurne issue of running a daemon as himself with
a gid that is not a Windows group and not being able to login over the
network. I have modified things to allow that sick case (in last patch).
 
6) Yesterday there was a report about chown and exim. Turns out I 
have introduced a bug while fixing another. The bug appears when the
chown function is called with a new owner equal to the old owner
(noop!) but different from the current user. Because there is no owner
change, the Restore privilege is not turned on and the user is unable
to rewrite the (unchanged) security descriptor.
The problem does not occur with the chown command because it notices
there is no owner change and doesn't call the chown function.
I will patch that.

Pierre


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