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

[simo]

On Fri, 2012-10-12 at 17:15 +0200, Alexander Werth wrote:
> 
> 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.

I was thinking in a similar direction.

We should keep all the details about how things are hashed and where
they are stored as an opaque operation. Obviously we can provide helper
functions that vfs modules can choose to use or ignore.

However I am not sure we need a call like the above.
Ideally the whole acl mapping is completely opaque and the vfs module
does check internally where acls come from and validate them also
internally.

So that when you do call a vfs function to get the Windows ACL, you just
get the 'right' ACL back. That is:
- if the vfs module can store the ACL directly in the FS it just
retrieves it
- if the vfs module needs to map acls it does that internally and check
hashes and what not.

Maybe this is something to consider in the new direction where Jeremy
and Volker said they want to take the fileserver where a more NT like
upper VFS layer and more lower level posix VFS layer coexist. 

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>