[PATCH] vfs_acl_xattr: avoid setting POSIX acls if "ignore system acls" is set

[Uri Simchoni]

On 03/22/2016 11:42 PM, Hemanth Thummala wrote:
> Hi,
>
> 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".

To illustrate:
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?