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

[Hemanth Thummala]

On 3/22/16, 3:28 PM, "Uri Simchoni" <uri at samba.org> wrote:

>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".

Thanks for the clarification. I was thinking that these hashes are computed separately for POSIX ACL and NT ACL. 
Yes. Now it make sense to skip the hash computation if this option is enabled. Thanks again!

>
>>
>> Also I found a comment which is misleading.
>>
>>
>
>Not sure I follow - misleading in what way?
>
Currently in get_nt_acl_internal(), if we are able to read the underlying SD, ret will be zero. The comment just above the condition "if (ret == 0) {“ is actually referring to failure scenario. Not a major concern. Thought that comment might not even be needed.

Thanks,
Hemanth.

>