[Samba] NFSv4 acls inheritance flags

[Volker Lendecke]

On Thu, May 08, 2014 at 02:11:41PM -0700, Jeremy Allison wrote:
> 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 !

Indeed. There is just no sane way out of this dilemma. Unix
for good reason has a very simple file concept, but this
brings problems for everybody who wants to add arbitrary
metadata to a file. The other big one is alternate data
streams. There is just no way to support them in a sane
manner if you want to also keep NFS/Unix compatibility. For
pure SMB servers that really do not allow any side-channel
to the file exports at all you could imagine all sorts of
schemes how to turn a Unix file or directory into a NTFS
file with all bells and whistles, but then you have to drop
the interoperability with other access methods.

If you want better integration, you should lobby for Unix
file systems to give us something equivalent to alternate
data streams. You should be able to openat(2) xattrs of
arbitrary size on any file. If Samba gets that, we can talk
about better integration :-)

With best regards,

Volker Lendecke

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de