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

simo idra at
Mon May 21 06:34:59 MDT 2012

On Mon, 2012-05-21 at 17:23 +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. 

If the mapping was wrong, wouldn't it be a 'good' think to break the
ACL ? After all it means the 2 are not equivalent.

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

Why ? If we go with acl_hash method in the VFS we should make it a
requirement, and Samba should replace any ACL it find that uses the old


Simo Sorce
Samba Team GPL Compliance Officer <simo at>
Principal Software Engineer at Red Hat, Inc. <simo at>

More information about the samba-technical mailing list