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

[Andrew Bartlett]

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

> 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

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org