Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-developers-owner AT cygwin DOT com
Message-ID: <3DF614B3.A127B1EA@ieee.org>
Date: Tue, 10 Dec 2002 11:22:11 -0500
From: "Pierre A. Humblet" <Pierre DOT Humblet AT ieee DOT org>
MIME-Version: 1.0
To: cygwin-developers AT cygwin DOT com
Subject: Re: ntsec, inheritance and sec_acl
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>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Corinna Vinschen wrote:

Hello Corinna

> I made the same tests on XP today and I'm impressed.  I recall that I
> once tested using creator_owner and creator_group (I don't know on
> which system) and for some reason I treated it unusable.  Perhaps
> just due to the GUI ACL interface or I didn't use the correct inheritance
> rules.  It looks very usable now, though.  I tried the following:
> 
>   owner ACE:            This folder only
>   creator_owner ACE:    Only subfolders and files
>   group ACE:            This folder only
>   creator_group ACE:    Only subfolders and files
>   everyone ACE:         This folder, subfolders and files
> 
> 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?

> Interesting:  If the everyone entry doesn't allow creating files, an
> unrelated user can't create files, regardless of the rights given to
> the creator_owner and creator_group ACEs.  And:  Even though all users
> are members of the same primary group 'None' on workstations, they
> can't suddenly create files because the creator_group entry has e. g.
> full permissions.

That's consistent with my understanding:
Firstly the current user needs to have permission to create an object in the
directory.
Secondly, when the object is created, it inherits ACEs and the creator_{owner, group} 
ACEs are then mapped to ACEs for the current user/group.
The creator_{owner, group} ACEs don't grant any direct access, they are like
recessive genes that only get expressed in the next generation.

> So, from what I can tell, this seems like the way
> to go.
> 
> > - Or should we simply give INHERIT_ONLY full access to Everyone?
> >   (probably least likely to generate complaints, but least secure).
> >   One advantage of this last approach is that such an ACE could easily
> >   be detected and suppressed in the getacl code, and "normal" cygwin
> >   directories would stop having a "+" in ls -l.
> 
> I don't see an advantage.  Wouldn't it make sense just to remove the
> creator_owner and creator_group entries from the acl_t completely,
> perhaps?  Hmm, that's only a problem if we actually are concerned by
> the additional '+' in the ls output.  Are we?  OTOH, this invalidates
> the chance to create the correct default:user:: entries in getfacl
> output... looks like we cannot have both.

About + being a problem, there was a mail on the list (Jason Tishler, if I
recall). 
Also, I would like to keep getfacl displaying the default entries,
if they are "special".
What I was thinking in this paragraph is more or less this:
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.
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?

> 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. 
We need precise rules for chmod and chown, no matter what we do when a 
directory is created.

Pierre