Mail Archives: cygwin-developers/2002/12/13/07:57:07
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.
- Raw text -