This is the mail archive of the cygwin-patches 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: [PATCH] Ensure that the default ACL contains the standard entries


On Dec 20 22:33, Christian Franke wrote:
> Corinna Vinschen wrote:
> >- Add Solaris NFSv4 ACLs, which, coincidentally, are almost equivalent
> >   to Windows ACLs.  This would work nicely for NTFS ACLs, of course.
> >   See http://docs.sun.com/app/docs/doc/819-2252/acl-5?l=en&a=view
> 
> Yes NFSv4 ACLs would make much sense. Coreutils copy-acl.c
> apparently supports these if available (It copies first POSIX ACL
> and then NTFS ACL). This may allow that 'cp -a source dest' keeps
> the NTFS ACL unchanged.

Sounds good.  We should definitly implement this at one point.

> >- Last but not least:  Actually handle "mask".
> >
> >Adding deny entries which correspond to the mask value sounds like an
> >interesting idea.  Of course they shouldn't be added if they are not
> >necessary since deny entries and the problems with the so-called
> >"canonical ACL order" are such a bloody mess.
> >
> 
> Does this mean "deny ACEs must precede non-deny ACEs" or are there
> more requirements?

The order and the way they are evaluated.  In POSIX the evaluation of
the user permissions always preceeds the evaluation of the group and
other permissions.  In a Windows ACL the ACEs are always evaluated in
the order they are given in the ACL.  So, consider a user is in a
specific group for which access is denied.  Since in canonical order the
deny ACEs preceed the allow ACEs, the access will be denied to this
user, even if the user is the owner of the file and there's an allow ACE
in the ACL.  That has a very unfortunate impact on the way you have to
create certain rights, as I describe in
http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping

> >What about redefining the NULL SID?  Right now three bits in the
> >NULL SID acess mask are used:
> >
> >   S_ISUID     ->   FILE_APPEND_DATA
> >   S_ISGID     ->   FILE_WRITE_DATA
> >   S_ISVTX     ->   FILE_READ_DATA
> >
> >I don't see that anything speaks against adding other meanings to
> >the remaining 29 bits.  For instance:
> >
> >   mask-r      ->   FILE_READ_EA
> >   mask-w      ->   FILE_WRITE_EA
> >   mask-x      ->   FILE_EXECUTE
> >   def-mask-r  ->   FILE_READ_ATTRIBUTES
> >   def-mask-w  ->   FILE_WRITE_ATTRIBUTES
> >   def-mask-x  ->   FILE_DELETE_CHILD
> >
> >If we do this, we can add an actual mask and we can not only use it
> >in acl(), but also in alloc_sd().
> >
> >Does that sound useful?
> >
> 
> Yes.
> 
> Some few draft 0.0001 ideas:
> 
> setacl: If the mask is set and not 'rwx' then add a NTFS deny ACE
> for each input ACE except 'user::' and 'other:'. The permissions
> bits of all deny ACEs are set equivalent to ~mask. Use current
> algorithm to build remaining NTFS non-deny ACE.
> 
> getacl: If the mask is set and not 'rwx' then use the current
> algorithm but ignore all NTFS deny ACEs with permission bits
> equivalent to ~mask.
> 
> chmod: If a mask is set or the current ACL is not minimal then set
> the mask to group permissions and add deny ACEs accordingly.
> Otherwise set the owner group ACE to group permissions.
> 
> 
> With this ACL:
> 
> user::rwx
> group::r-x
> user:foo:rwx
> group:bar:r-x
> mask:rwx
> other:r-x
> 
> a chmod 0740 would result a NTFS ACL equivalent to:
> 
> deny:group::-wx
> deny:user:foo:-wx
> deny:group:bar:-wx
> user::rwx
> group::r-x # effective:r--
> user:foo:rwx # effective:r--
> group:bar:r-x # effective:r--
> mask:r--
> other:---

That won't work for the reason I outlined above.  The canonical ordering
now disallows read access to the user, even though there's an allow ACE
with allows this access to the user.

The problem is, we can either adhere to the canonical order and are
unable to express certain POSIX permissions.  Or, we abandon the
canonical order (as we already do now in alloc_sd in the border cases
like "rw-r-xrw-") and will suffer whining of Windows tools like the
security tab of the file properties dialog in case the ACL is not
canonical.

What you have to do to get POSIX-like permissions even in case of
complex ACLs like the above is to create the ACL in a POSIX-canonical
order.  POSIX-canonical means, the ACLs must be order user->group->other
in the first place.  Only then deny must preceed allow:

  user 1 deny
  user 1 allow
  user 2 deny
  user 2 allow
  [...]
  group 1 deny
  group 1 allow
  group 2 deny
  group 2 allow
  [...]
  other allow
  mask (null ACE)
  defaults

or

  user 1 deny
  user 2 deny
  user 1 allow
  user 2 allow
  [...]
  group 1 deny
  group 2 deny
  group 1 allow
  group 2 allow
  [...]
  other allow
  mask (null ACE)
  defaults

So the above ACL should be, for instance

  deny:user:foo:-wx
  user::rwx
  deny:group::-wx
  deny:group:bar:-wx
  group::r-x # effective:r--
  user:foo:rwx # effective:r--
  group:bar:r-x # effective:r--
  mask:r--
  other:---


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


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