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