Hi Corinna,
Corinna Vinschen wrote:
Hi Christian,
On Dec 15 19:46, Christian Franke wrote:
...
BTW: Are there any long term plans to actually implement the acl "mask" ?
Should be possible by mapping the "mask" restrictions to deny acl
entries for each named entry:
There are no such plans, but that doesn't mean I wouldn't take patches
which implement this. In fact I would be *very* happy to get patches
which improve ACL handling, and I'm not finicky in terms of the type
of enhancement. Various ideas come to mind:
- Fix acl(2) by handling deny ACEs at all.
- Implement the POSIX 1003.1e functions (maybe simply in terms of
the existing Solaris API).
- Add missing Solaris ACL functions (acl_get, facl_get, acl_set, facl_set,
acl_fromtext, acl_totext, acl_free, acl_strip, acl_trivial).
- 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.
- 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?
OTOH, if you don't fake the mask entry, you need a way to stick the mask
into the Windows ACL. Even twice, the normal mask and the default mask.
This only works if you have a SID which you use for this purpose.
Hmm...
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:---
Christian
