[Samba] NFSv4 acls inheritance flags

[Sabuj Pattanayek]

On Thu, May 8, 2014 at 1:50 PM, Volker Lendecke
<Volker.Lendecke at sernet.de>wrote:

> On Thu, May 08, 2014 at 09:49:22AM -0500, Sabuj Pattanayek wrote:
> > >
> > >
> > > It is worse than that. If you have to do a file restore then the files
> > > get different inodes and the ACL's are screwed.
>

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.