Mail Archives: cygwin-developers/2001/08/06/12:31:05
> 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.
Hmmm....you 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.
True.
> 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
effect.)
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 hours...so I can't help with this in the near
future. :-(
--Chuck
- Raw text -