This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]