Mail Archives: cygwin-developers/2001/08/05/17:17:32
> On Sun, Aug 05, 2001 at 03:23:30PM -0400, Charles Wilson wrote:
>> Well, it looks like the script below DOES cause some problems. I just
>> installed the new ash and binutils packages using setup. However: I
>> can't execute them.
>> > Here's the ACL for /bin (prior to running setup to install the new ash)
>> > # file: bin
>> # owner: 500
>> # group: 513
>> user::rwx
>> group::rwx
>> mask::rwx
>> other::r-x
>> default::mask::---
>> > After installing ash (as Administrator), the ACL for sh.exe:
>> > # file: sh.exe
>> # owner: 544
>> # group: 513
>> user::rwx
>> group::---
>> group:18:rwx
>> mask::---
>> other::---
>> > I can fix this (by hand, after logging BACK in as Administrator), but
>> what went wrong?
I did 'for fn in `zcat /etc/setup/ash.lst.gz` ; do if [ -f $fn ]; then
chmod +rX $fn ; fi ; done
Also for the experimental binutils. (note the capital 'X'). That seems
to fix it. But...
> 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.
But then we rely on 'propagate to children' when setup.exe runs, or we
get a "bad" discretionary ACL?
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.
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.
IOW, what happens if I run setup, and install only the cygwin package.
(okay, plus bash and fileutils). In this minimal install, there is no
/usr/lib/gcc-lib/ directory. So, I create one myself, using mkdir.exe
from fileutils. I chmod the directory to rwxrwxrwx (BUT, because of the
differences in how setup.exe creates dirs and how cygwin's mkdir()
creates them, /usr/lib/gcc-lib doesn't have the same inheritance
settings as /usr, /bin, /lib, etc).
Then I run setup.exe to install gcc. Everything under gcc-lib will be
inaccessible except by admin, right? But technically I did nothing wrong.
I think this should be addressed before cygwin-1.3.3...
>
> 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?
!@#^# 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?
--Chuck
slowly going insane myself.
- Raw text -