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

Charles Wilson
Mon Aug 6 09:28: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).

Good.  Confusion eliminated.  'nuff said.

> > 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. know, it's been so long (1.5 yr?) since I actually did a
full install that I never really noticed.  I suppose that speaks well of
the 'upgrade' capabilities of cygwin's setup.exe.

In any case, your explanation is quite cogent.  Thx.

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

good point.  But I don't think it's possible for a user to create a file
using tar -x and then NOT be able to access that file (regardless of the
owner settings).  doesn't tar adjust the perms when owner != untar-er?
> > 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...

I like this.  (Sure, permissions, security, yadda yadda.  This is
windows, fer gawd's sake).

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


> What was the question, btw?

What needs to change w.r.t. DACL's in (cygwin | setup.exe) to prevent
other users from running into the problems I have experienced with
non-inherited perm settings?

It looks like the answer is:

cygwin: create_token() needs to set a default DACL of some sort, that is
a little more open than rwx------.  (This only affects the *default*
DACL.  If perms/ACL are *specified*, then of course the "default" has no

setup.exe: dirs(files?) created by setup.exe should have a DACL that
allows full access to everyone.  If users want to lock things down
tighter after the fact, they 
can, I suppose.

Two problems: I dunno how to do this, and they're taking my computer
away in a couple of I can't help with this in the near
future.  :-(


More information about the Cygwin-developers mailing list