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: <3B6EC5C0.75D0910A@ece.gatech.edu>
Date: Mon, 06 Aug 2001 12:28:48 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: 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> <3B6DB7E6 DOT 2080507 AT ece DOT gatech DOT edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> 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