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]
Other format: [Raw text]

Re: ntsec, inheritance and sec_acl


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@cygwin.com
Red Hat, Inc.


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