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
