[PATCH][WIP] Make vfs_acl_xattr use hash of the posix ACL
ambi at samba.org
Wed Oct 17 03:41:10 MDT 2012
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
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
This would eliminate various conversions and should still address your
needs. What do you think?
More information about the samba-technical