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
Date: Sun, 12 Aug 2001 21:03:38 +0200
From: Corinna Vinschen <vinschen AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: outstanding issues blocking new release?
Message-ID: <20010812210338.B659@cygbert.vinschen.de>
Reply-To: cygdev <cygwin-developers AT cygwin DOT com>
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <3B76C44A DOT 90202 AT ece DOT gatech DOT edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B76C44A.90202@ece.gatech.edu>; from cwilson@ece.gatech.edu on Sun, Aug 12, 2001 at 02:00:42PM -0400

On Sun, Aug 12, 2001 at 02:00:42PM -0400, Charles Wilson wrote:
> the ACL for a directory created by setup.exe is not the same as the ACL
> for a directory created by mkdir() under new cygwin1.dll:
> 
> Created by setup.exe:
> # file: /bin
> # owner: 544
> # group: 513
> user::---
> group::---
> mask::---
> other::rwx
> default:mask::---
> 
> Created by mkdir:
> # file: /usr/local/doc
> # owner: 500
> # group: 513
> user::rwx
> group::rwx
> mask::rwx
> other::rwx
> default:user::rwx
> default:group::rwx
> default:mask::rwx
> default:other::rwx
> 
> In each case, 'ls -ld' shows "drwxrwxrwx".  Newly created files 
> underneath these two directories have ACLs that are identical.

That's what I'd expected. setup.exe uses a very simple default DACL
(just look into the short new function in main.cc - it's hopefully
well commented) which only sets full control for everyone. mkdir
OTOH uses the standard POSIX permissions which give permissions
always to user, group and other. The differences are only that
files created by setup are deletable by everyone while files
created by mkdir are only deletable by users which have write and
execute permissions on the parent directory. You can see the
difference only by carefully examining the output in the W2K "advanced"
security tab.

> It seems that setup.exe follows "behavior #2" in Corinna's description 
> (because setup.exe IS a native windows app, after all).
> 
> Two related questions:
> 1) is the difference in directory ACLs a problem?

No. Not if security is a non-issue. Otherwise both variants are
too dangerous.

> 2) should setup.exe contain the same code that security.cc does, so that 
> setup-created dirs have the same ACL as mkdir-created ones? (E.g. with 
> regards to ACL's, should setup.exe behave as a cygwin app according to 
> "behavior #3" in Corinna's description above?)

I don't know what you mean by "behavior #n". Anyway, It might be
an interesting feature for future versions of setup to create the
permissions on NTFS filesystems according to the permissions in
the tarballs. However, it's a lot of work to pull the security.cc
stuff into setup. And it only applies to systems which have `ntsec'
set but the question if `ntsec' shall be used isn't asked anywhere
in the setup dialogs. It wouldn't make any sense at all to people
who install for the first time. And note that neither /etc/passwd
nor /etc/group exist when the tarballs are unpacked the first time.
So which user and group membership makes sense at that point?

> An unrelated question: should setup create /tmp with perms 1777 instead 
> of 0777, as it currently does?

That's impossible with the current simple way to set the permissions
using the default DACL. That requires the above, including security.cc
code into setup.

> --Chuck
> 
> P.S. I did this on my newly-repaired development machine, so "I'm back", 
> except for those pesky dissertation issues.

So, welcome back :-)

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin AT cygwin DOT com
Red Hat, Inc.