[PATCH][WIP] Make vfs_acl_xattr use hash of the posix ACL
abartlet at samba.org
Wed Oct 17 03:57:00 MDT 2012
On Wed, 2012-10-17 at 11:41 +0200, Christian Ambach wrote:
> 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
I think you mean the hash of the native blob, but this looks correct to
> 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?
This is exactly what we do, and exactly why we do it (in my proposal).
acl_get_file() returns a structure, but smb_acl.idl encodes essentially
the same structure, with only one-to-one translation from the per-vendor
acl_t on all our posix ACL implementations.
The the only reason we have any 'intermediate
representation' (smb_acl_wrapper) is to capture the extra things that
are part of the acl, but not actually in the ACL (user/group/mode) and
to have something we can linearise trivially into NDR.
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
More information about the samba-technical