Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Message-ID: <3B6DB7E6.2080507@ece.gatech.edu>
Date: Sun, 05 Aug 2001 17:17:26 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713
X-Accept-Language: en-us
MIME-Version: 1.0
To: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
CC: cygwin-developers AT sources DOT redhat DOT com
Subject: Re: Silly ACL problems [Was: Re: Problems with autoconf-2.52 testsuite using current CVS Cygwin]
References: <996329431 DOT 27668 DOT ezmlm AT sources DOT redhat DOT com> <3B63432E DOT 6050309 AT ece DOT gatech DOT edu> <3B649305 DOT 2090302 AT ece DOT gatech DOT edu> <3B64C0A9 DOT 1080700 AT ece DOT gatech DOT edu> <3B64F567 DOT 6060304 AT ece DOT gatech DOT edu> <3B65835C DOT 9000001 AT ece DOT gatech DOT edu> <3B65A2B8 DOT 90702 AT ece DOT gatech DOT edu> <3B66CC47 DOT 8040704 AT ece DOT gatech DOT edu> <3B6711C9 DOT 6050700 AT ece DOT gatech DOT edu> <3B6C3A4F DOT 3070502 AT ece DOT gatech DOT edu> <3B6D9D32 DOT 1050600 AT ece DOT gatech DOT edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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