outstanding issues blocking new release?

Corinna Vinschen vinschen@redhat.com
Tue Aug 7 09:38:00 GMT 2001

On Tue, Aug 07, 2001 at 10:59:17AM +0200, Corinna Vinschen wrote:
> 3) Setup is prepared and changing fhandler_base::open() shouldn't
>    be too hard since most of the code already exists (alloc_sd).
>    I just need a few hours to wrap it for usage in open() and to
>    test the stuff. So, if you're not in a hurry...

That was way easier than I estimated. And I have learned something new:

The SECURITY_ATTRIBUTES given to the CreateFile() call does _not_ only
describe the security settings for the returned handle as I thought
all the time. Instead it has actually two purposes:

- The bInheritHandle member sets the inheritance property for the returned
- The lpSecurityDescriptor member sets the security descriptor for the
  created file, actually.

And the CreateDirectory() function has a SECURITY_ATTRIBUTES parameter
as well.

That means, the open(), symlink() and mkdir() calls now don't open
the file/dir a second time to write the NT security settings as before
but the settings are already done in the CreateFile()/CreateDirectory()

Why didn't I realize that already two years ago???


BTW, that has an interesting side effect. The propagation of
permissions from the parent directory is no problem anymore when
creating files in directories which aren't owned by the creator
of the file. That problem was the main reason to switch off the
propagation completely when creating directories. The explicitly
given security descriptor in the CreateFile()/CreateDirectory()
calls rules.

So the question is:

Shall we return to propagating permissions to subfolders and files?

The advantage is that native windows applications would create files
with useful permissions again.

Since 1.3.2 still propagate permissions, non-developer users wouldn't
even realize that something has changed. Even users who don't upgrade
to the latest setup.exe wouldn't have the problem which Charles stumbled
over. Sorry, Charles! It seems as if you has been sort of a guinea pig...


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

More information about the Cygwin-developers mailing list