[Samba] NFSv4 acls inheritance flags

[Jeremy Allison]

On Thu, May 08, 2014 at 02:52:50PM -0500, Sabuj Pattanayek wrote:
> 
> Thinking about this more and Volker's comment about hard links, the ACLs
> are screwed anyways because the .tdb would have no idea whether you want to
> restore the ACLs from the TDB (let's say it holds onto every deleted ACL
> using a absolute path : inode : acl key value pair) or the acl's as
> inherited from POSIX default acl's. the problem there is let's say you have
> a tdb that looks like this :
> 
> /smb/foo/bar -> 9873493 -> nt acl info for inode 9873493
> /smb/foo/baz -> ""
> 
> You delete /smb/foo/baz . It's been deleted from the FS, but the entry
> still exists in the .tdb with some sort of deleted flag. You do the restore
> or just touch the file back into existence. How does smb then know to put
> the acl's from the tdb or just posix inherited acl's on it? Your backup
> program really needs to know how to backup this metadata, which I'm glad
> TSM knows how to do for GPFS with either extended attributes or NFSv4 ACLs!
> Setting permissions using mmputacl is much faster than via the windows
> dialog -> vfs_gpfs -> samba -> gpfs. It's just added overhead.

And that's why we only use acl_tdb as part of the test suite,
and don't recommend it being used in production :-).

acl_xattr is the right one to use !

Jeremy.