[PATCH] Fix open bug found at Microsoft interop event - version 2

[Andrew Bartlett]

On Thu, 2013-06-20 at 14:57 -0700, Jeremy Allison wrote:
> Here is a (much better :-) patch to fix the specific
> issue found at the MS-test event in Redmond. The underlying
> issue is that on ZFS filesystems using the vfs_zfsaacl module
> do not add in the FILE_DELETE_CHILD permission on ACE entries
> on files that have all other permissions set (as the posix
> acl mapping code does).
> 
> Introduces (and fully documents :-) a parameter
> "nfs4:map full control" that controls this activity. Also
> includes a new (previously missing :-) man page for
> the vfs_zfsacl module.
> 
> Also includes a new torture test that tests the NFSv4
> ACL module with this parameter turned on for the raw.acls
> test.
> 
> I'm pretty happy with this patch. Once it's in the
> only follow-up argument is whether the new parameter
> should default to "true" by default (as Ira would
> like :-), or to "false" by default (which will preserve
> any acl_xattr Windows ACLs stacked on top of a vfs_zfsacl
> module share).
> 
> By default (and to be conservative for the acl_xattr
> users) I've set it to false in this patch, but we
> can argue about this after it's gone in :-).

I would really, really prefer we didn't have yet another nfsv4 option.
I worked very hard with Alexander Werth to avoid adding another nfsv4
mode, and we essentially agreed to deprecate the 'special'.  

If we must have it, I will argue to change the default, because I
strongly dislike 'broken by default, works if you know the magic
incantation'.  

One way around the upgrade issue is to have the HASH_SECURITY_INFO that
vfs_acl_xattr passes down include a flag for mode 'false', and then
fetch it again without that flag if we do want to use the underlying
ACL.  That would allow us to honour the previous mapping and hash
information.  (Of course, this reminds me that we need to extend the ACL
blob handler to ZFS). 

We have already changed the mapping for 4.1, when we changed some of the
mappings in mode 'simple', but this should have (only?, mostly?)
impacted files not created via Samba anyway. 

> Samba-on-ZFS users, please look at this (Ira, Richard,
> Andrew).

On broader things, I would like to have the common nfsv4 stuff in an
included section, so we keep them in sync between zfs and gpfs. 

In the knownfail file, I there is a typo

+^^samba3.base.delete.deltest16a

Finally, thanks for extending the testsuite to cover this!  So much of
or combinational complexity is in our VFS layer, and it's really good to
see tests extended when options are added.

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org