Silly ACL problems [Was: Re: Problems with autoconf-2.52 testsuite using current CVS Cygwin]

Corinna Vinschen
Sun Aug 5 15:12:00 GMT 2001

On Sun, Aug 05, 2001 at 05:17:26PM -0400, Charles Wilson wrote:
> > Nothing, I think. Setup is a non-Cygwin tool so it has nothing
> > to do with ntsec. Since the ACL of /bin doesn't inherit it's
> > permissions, newly created files get a default DACL which is
> > identical to what you see above if your account has admin privs.
> Okay, I'm confused.  I thought it had been decided that inheritance was 
> a bad thing, and recent changes in cygwin CVS were so that newly created 
> directories did NOT have the 'propagate to children' setting turned on.

That would be correct. Inheritance is a concept unknown by POSIX
filesystems (except for s-gid bit).

> But then we rely on 'propagate to children' when setup.exe runs, or we 
> get a "bad" discretionary ACL?

Not really. Did you ever notice that the files created by setup.exe
always have the wrong ACL compared to the permissions in the tar
file? Since setup is native Windows, the permissions are always
related to the systems settings. For example, on my system I have
not cared for the /usr directory. It's still set to full access
for `Everyone' including the obligatory inheritance. So all dirs and
files created by setup in /usr have set the same permissions - full
access for everyone. If any directory has no inheritance set, files
are getting the default DACL of the creating process as in your case.

> Something is just plain wrong when setup.exe tries to install something 
> (which, inside its tarball package if unpacked separately, has perms 
> rwxr-xr-x) but ends up being rwx------ because of some weird mismatch of 
> directory permission inheritance.

Don't forget that tar even on POSIX systems doesn't restore the
permissions fully - the owner of files isn't set correctly unless
the -p option is given.

> Either setup needs to "do what's necessary" to directory perms, or we 
> should revert back to 'propagate to children' in cygwin1.dll mkdir(). 
> Or fix mkdir() so that the expected thing happens.  Whatever that is.
> I think this should be addressed before cygwin-1.3.3...

That could perhaps be addressed by giving setup a default DACL
which allows full access to everyone. That would allow that all
users could still work with the installation. No surprising
"Permission denied" messages...

> > This reminds me that setting the default DACL could be a useful
> > extension to the create_token() code...
> Again, I'm a bit confused -- but would this fix the problem I outlined 
> above?

Not for setup. It would just be a good thing for Cygwin processes.

> !@#^# Could MS have come up with a more insane way of implementing ACLs 
> if they'd tried harder, or have they demonstrated the mathematical 
> asymtote of insanity?

The answer is "yes". What was the question, btw?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                      
Red Hat, Inc.

More information about the Cygwin-developers mailing list