Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Fri, 13 Dec 2002 13:57:02 +0100
From: Corinna Vinschen <vinschen AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: ntsec, inheritance and sec_acl
Message-ID: <20021213135702.Q7796@cygbert.vinschen.de>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <3 DOT 0 DOT 5 DOT 32 DOT 20021205222631 DOT 007d3920 AT mail DOT attbi DOT com> <20021210112403 DOT B7796 AT cygbert DOT vinschen DOT de> <3DF614B3 DOT A127B1EA AT ieee DOT org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3DF614B3.A127B1EA@ieee.org>
User-Agent: Mutt/1.3.22.1i

Hi Pierre,

On Tue, Dec 10, 2002 at 11:22:11AM -0500, Pierre A. Humblet wrote:
> > This results in (even from a POSIX view) correct ACLs for newly created
> > files and the same plus the additional entries for creator_owner and
> > creator_group for new subdirectories.
> 
> I assume you are using the words from the XP GUI (I don't have it).
> The mapping would be:
> This folder only => NO_INHERIT
> Only subfolders and files: => INHERIT_ONLY |  SUB_CONTAINERS_AND_OBJECTS_INHERIT
> 
> OK?

yes, that's correct.  Sorry for assuming too much.

> 1 when a directory is created, the only inheritance is INHERIT_ONLY full 
>   access to Everyone, which is suppressed by the getacl sec_acl routine.
> 2 if setfacl is called explicitly with a default :: entry, a creator_owner
>   or group ACE is inserted and it is displayed by getfacl.
>   Also if setfacl is called with *any* default entry, the INHERIT_ONLY 
>   full access to Everyone is not inserted anymore, we strictly follow the user
>   wishes.
> 3 when chmod is called, alloc_sd will detect that there is a current ACL. 
>   Any INHERIT ACE is reproduced in the new ACL and the the INHERIT_ONLY 
>   full access to Everyone is not inserted anymore (thus we preserve the 
>   user wishes). Note that chmod would only change the permissions on the
>   directory itself, not the inheritable (default) permissions.
>   An {owner, group, everyone} ACE that both affects the current directory 
>   and that is inheritable would be split in two ACEs: one with the new 
>   permissions for the directory, and one INHERITABLE ONLY ACE with the old
>   (default) permissions. I think that consistent with Sun acl logic.

Up to here:  Everything's fine for Cygwin but Cygwin applications are
ok anyway.  What about native Windows application in that scenario?

> 4 I am still struggling with exactly what to do during a chown.
>   Perhaps chown_worker should pass attribute = NULL and alloc sd should then
>   simply build the new ACL from the current ACL, changing the owner/group SIDs
>   as needed. Should it change the the SID on inheritable ACEs? 
>   If not, an owner ACE that both affects the current directory and that is 
>   inheritable would be split in two ACEs: one with a new owner SID for the 
>   directory, and one INHERITABLE ONLY ACE with the old owner SID.
>   Isn't that the Sun acl logic?

Ah, uh, oh, dunno.  I don't have enough access to a sun machine supporting
ACLs to test this.  

> > Another problem is that this only makes sense if there are write
> > permissions present for everyone or the group entry.  Or for an
> > unrelated group or user entry.  That's tricky.  If *anybody* has
> > write access to the directory, the everyone inheritance would then
> > give *everybody* write access.  Oh oh...
> 
> Yep, that's why I hesitate... On the other hand if a user is running Windows 
> applications, then the inheritances should be set appropriately (from outside
> Cygwin if needed) as they are more critical. 
> The rules given above try to insure that Cygwin won't disturb inheritance
> rules specified from outside Cygwin, or with setfacl. 

Aren't we discussing the exact opposite in the first place?  We do
have the situation where a directory has been created by Cygwin and
we try to be nice to native Win apps.  This seem to work surprisingly
good by using the creator_owner/group inheritance ACEs.  The resulting
ACLs created by the native app gives useful access to the native apps
*and* it also makes sense in the Cygwin case.  How do you get this
with using the Everyone INHERIT_ONLY approach?  It seem to require
a bunch of tricks inside of Cygwin for only having the advantage of
getting rid of the '+' in ls output...

Corinna

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