[PATCH] vfs_acl_xattr: avoid setting POSIX acls if "ignore system acls" is set
uri at samba.org
Tue Mar 22 22:28:47 UTC 2016
On 03/22/2016 11:42 PM, Hemanth Thummala wrote:
> I have a question.
> If the intention of “ignore filesystem ACLs” is to just ignore the underlying POSIX ACLs, we shouldn’t be ignoring the NTACL hash computation in get_nt_acl_internal() right? Otherwise we would end up not using HASH(for NTACL) at all. As Uri pointed out, we might even go back back to version 1 which has just SD. Is intentional to skip the hash check for NTACL when “ignore filesystem ACLs” is set? If so, is it for performance reasons?
If I understand correctly, the function of the NT ACL hash is to detect
changes in the POSIX ACLs - This is NOT a hash of the NT ACL stored in
the xattr! it's a hash of an NT ACL computed by reading the POSIX ACL
and converting it back to NT ACL. A hash mismatch would usually mean
that the POSIX ACL has changed (usually, because it could also occur
because the sid->unix id mapping has changed, and the v4 system ACL hash
is resilient to that).
Therefore "ignore system acls" means "don't compute and compare this hash".
Suppose there's an ACE which says John has DELETE and READ access. We
store this ACE as-is in xattr. But when we translate to POSIX ACL -
there's no such thing as DELETE access, so it translates to just 'r' bit.
We rebuild the NT ACL from the POSIX ACL in order to hash it - we get an
ACE with just READ access - this is what we hash and store.
Later we read the NT ACL - again we rebuild the NT ACL from POSIX, get
this ACE with just READ (if it hasn't changed), hash it and compare - if
it compares OK, then the NT ACL in xattr is valid, and we return the ACE
with DELETE+READ. If not, we return the rebuilt ACL.
> Also I found a comment which is misleading.
Not sure I follow - misleading in what way?
More information about the samba-technical