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

Alexander Werth werth at linux.vnet.ibm.com
Fri Oct 12 09:15:01 MDT 2012

On Fri, 2012-10-12 at 14:18 +0200, Christian Ambach wrote:
> Hi Andrew,
> On 10/12/2012 01:26 PM, Andrew Bartlett wrote:
> > By defining this interface, vfs_acl_common does not need to know what
> > the system ACL is, be it posix or nfsv4 or AFS.  It can (if returned)
> > just hash the contents of the data_blob and store it.
> >
> > At a later time, if the contents matches, then the exact NT ACL that
> > the windows client set is returned.  If the hash does not match, the
> > the posix, NFSv4 or AFS ACL must have been changed outside Samba,
> > and an imperfect mapping to an NT ACL is returned instead. [...] I
> > would welcome patches to linearise NFSv4 into NDR in the same way I
> > did for posix ACLs in smb_acl.idl
> Shouldn't we better have one datatype that fits all variants instead of
> having datatypes for each style of ACL? And the common denominator here
> would be the general Windows SD format (as it has all fidelity).

Using the xattr module on top of NFS4 can be useful to store local SIDs
and to support some appliances that store arbitrary data in the ACL.
And keep in mind that the VFS layer of samba allows to interface with
custom filesystems. It's possible that the system can distinguish a call
changing the ACL via smbd from a call through another program.

Maybe we need a VFS call that can be used to figure out if any ACL
relevant information had been changed in the FS?
What about a VFS function that accepts a hash and returns another one?
A matching hash indicates that nothing changed and a changed one that
something changed. Something like:
static NTSTATUS vfs_acl_hash_changed(uint16_t hash_type,
                                     uint8_t oldhash[SD_HASH_SIZE],
                                     uint8_t *newhash[SD_HASH_SIZE]);

To save context switches it might be an option to return a pointer to
the new security descriptor which will be needed anyway on a change.


More information about the samba-technical mailing list