[PATCH][WIP] Make vfs_acl_xattr use hash of the posix ACL

[Christian Ambach]

Hi Andrew,

On 10/16/2012 11:19 AM, Andrew Bartlett wrote:

>>> Yes, that data type is DATA_BLOB.  The hash code needs no more than that
>>> (I initially proposed it to be the sha256, but was requested to pass up
>>> the data_blob).
>>
>> GPFS supports to retrieve the filesystem ACL as an opaque blob (for
>> backup applications), so I guess this would be an ideal candidate for
>> hashing, correct?
>
> Great, that's perfect!
>
> We might then be able to skip the call to the posix helpers in that
> case, which would make things more uniform.
>
>> If so, where would this information now be stored?
>
> It would be hashed into the xattr stored by vfs_acl_common.c as the
> system acl.  See smb_acl.idl and xattr.idl.
>
> If there is additional metadata that essentially forms part of the ACL
> (owner/group/mode is stored for the posix ACL), then see
> smb_acl_wrapper for an example of what wrapper around a DATA_BLOB to
> create.

What would be potential downsides of eliminating the intermediate 
representation that gets stored in the EA and just store a hash of the 
native ACL blob that the file systems return to us?

So vfs_acl_xattr would work like this:
1. let VFS store the ACL
2. ask for the native blob in the file system
3. store native blob + Windows SD in EA

This way we wouldn't have to render EAs invalid if we change the mapping 
algorithms from native -> Windows SD and we still will be able to detect 
any changes that were performed on the file system directly.

So for POSIX ACLs, we would store whatever acl_get_file(3) returns, for 
other platforms like GPFS, we would store the blob that the filesystem 
returns. They all are able to return a blob of some sort or another and 
it would be up to the filesystem module maintainers to choose the most 
appropriate one.

This would eliminate various conversions and should still address your 
needs. What do you think?

Cheers,
Christian