acl_xattr storage format (Re: Moving forward towards releasing Samba 4.0)

[Jeremy Allison]

On Mon, May 21, 2012 at 05:23:12PM +1000, Andrew Bartlett wrote:
> On Mon, 2012-05-21 at 09:00 +0200, Stefan (metze) Metzmacher wrote:
> > Hi Andrew,
> > 
> > > I would also like to make the change to the acl_xattr storage format I
> > > discussed on the list (move to a hash of the raw posix ACL, not the
> > > mapped NT ACL), but I will not let this put off the beta. 
> > 
> > That's not possible, as there might be other things than raw posix ACL's
> > (e.g. simple posix permissions, NFSv4 ACL's ...),
> > the only thing that matters is the mapping between the NTACL we try to
> > store and the one that will be returned by the underlying layers.
> 
> All those different backends will need to provide an acl_hash VFS
> operation, returning a sha1 of whatever the OS layer they have is. 
> 
> Otherwise, even a change to our id mapping to map a previously unmapped
> ID will invalidate the NT ACL, as if the posix ACL had been modified. 
> 
> I'm particularly concerned that any change in our POSIX ACL -> NT ACL
> mapping (to fix a bug in the mapping, such as might be required for
> #8938 if confirmed) would otherwise invalidate all mappings on disk. 
> 
> Perhaps it will be all to hard to do in a generic way, but where
> possible I want to make this less fragile (the existing codepath and
> system will remain, both for backwards compat and for any path that
> doesn't declare an acl_hash method). 

Actually I've been thinking about this and the right way
to code it (IMHO) is not to have an acl_hash method, but
to have an acl_blob method, that returns a DATA_BLOB
containing the raw form of the underlying ACL.

That then allows the upper layer to change the hash
mechanism (md4, SHA1 etc.) without having to encode
knowledge of the specific hash algorithm in every
lower layer.

Essentially it's doing the same work that acl_hash
would have to do, just leaving the final hash to
the upper layer.

Does that make sense ?

Jeremy.