Re: ntsec, inheritance and sec_acl

[Corinna Vinschen <vinschen at redhat dot com>]

Hi Pierre,

sorry for the delay.

On Thu, Dec 05, 2002 at 10:26:31PM -0500, Pierre A. Humblet wrote:
> There is a thread on the cygwin list
> http://cygwin.com/ml/cygwin/2002-11/msg01127.html
> where ntsec is blamed for permission troubles with
> non cygwin applications.

Yes, I read it.

> [snip]
> - What behavior are we trying to achieve?

The inheritance is only to support Windows natives.

> - If we do not set any inheritances on directories and a file is
>   created, by default the user (or Administrators) and System
>   have full access, period. That's clearly worse than today.

I agree.

> - Should we set inheritance rights for "well_known_creator_owner_sid"
>   (and not for the directory owner sid)?
>   For the group, define similarly a "well_known_creator_group_sid"
>   (S-1-3-1).
>   That is, we could insert these special sids in INHERIT_ONLY ACEs on 
>   directories, mirroring the owner/group/everyone, both deny and
>   allow. I have verified that the inherited ACEs have the correct
>   order, even if it isn't canonical. 

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.  

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.  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.

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...

> A related matter is that the getfacl output for "." above is incorrect.
> For example, the line "default:user::rwx" 
> should be "default:user:PHumblet:rwx"
> i.e. apply to a specific user although PHumblet is the owner.
> This is easily seen from the output of "getfacl testuser_nontsec"
> 
> An unnamed user line "default:user::abc"
> should only be generated when well_known_creator_owner_sid is
> present. Similarly for group.

In the light of the above discussion, yes, you're right.

> Following an unrelated problem using setfacl, I have looked more into 
> the acl functions and noticed difference with Sun on two points:
> the number of colons and on the input formats
> See below. Comments on right side. "midi" is a Sun.  
> [snip]
> I can take a stab at some of this after we finish the internal
> passwd business and converge on what to do about inheritances.

Ok, I didn't notice this difference.  We can change that at a later
point.  It doesn't really matter unless we actually use the
creator_owner and creator_group entries.

I'm trying to review (finally) your second patch to the internal passwd
patch today or tomorrow.

Corinna

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