[PATCH] Add tests for our NFSv4 ACL code

[Andrew Bartlett]

On Wed, 2013-05-01 at 05:09 +0200, Alexander Werth wrote:
> On Mon, 2013-04-29 at 08:18 +1000, Andrew Bartlett wrote:
> > Can you please add clear documentation as to what specialcreator is,
> > what it does differently to simple and special.  I take it that the
> > migration patches are still separate, but in those we should also
> > include details on how you can migrate to it?
> I just realized that I've forgot to cherry-pick the README.nfs4acl
> patches describing that option.
> Also the README could contain a much more extensive documentation than
> the man page for vfs_gpfs for example which also needs an update.
> Both should be very clear that there is one recommended mode (either
> nfs4:mode simple or specialcreator) which is the default.
> Personally I would tend to recommend nfs4:mode simple because the mode
> specialcreator can be quite slow while creating files unless the NFS4
> ACL to Security Descriptor to NFS4 ACL conversion there is optimized
> out.

I think it needs to be, for correctness in the case where we can't map a
UID or GID. 

> > I'm still a little lost as to what all the different modes do, so I
> > think others would be similarly confused.  I still think we should be
> > able to figure out a way to just do this correctly, but that will take
> > further thought and examples.
> I don't think there is a correct way to do this. We are limited by the
> nfs4 specs and the implementations and we have to work around this or we
> limit our use cases.
> If we don't have an option in samba then the only other option to get
> reasonable mode bits would be an option in the nfs4 filesystems to
> toggle between various nfs4 to mode bit mappings.

I'm still not convinced.  I was convinced, and that was that we should
set specialcreator to be the default, but you want to keep simple
around.  I think therefore we need to fix things up more, as I suggest
below:

> In either case I'm posting some wip, collecting the pro and cons of the
> various nfs4:mode settings:
> 
> nfs4:mode simple
> 
> Pro
> - Working inheritance
> - Creator owner support with new code
> - No overhead on file creation.
> - Owner changes have no side effect on the ACL with the exception of a
> not rewritten creator owner entry.
> - Recommended option for SMB only file servers.
> 
> Con
> - No Posix mode bits for file owner and group.

This is just the same as if a file is created over NFS or directly in
the shell, correct?

> - Files with creator owner or creator group entries do have mode bits
> after file creation but lose them by rewriting the ACL through SMB.
> - Files lose mode bits applied through chmod by rewriting the ACL with
> SMB.

Why can't we get this feature (of specialcreator) in simple?  Isn't it
just a matter of expressing the creator owner stuff properly for simple
mode-based permissions?

> 
> nfs4:mode specialcreator
> 
> Pro
> - Working inheritance
> - Creator owner support with new code.
> - Expected Posix mode bits on all files created with SMB.
> - Files keep mode bits applied through chmod when rewriting the ACL with
> SMB.
> - Mode bit's on files created through SMB can be controlled with creator
> owner and creator group entries.
> - Recommended for mixed SMB/NFS file servers.
> 
> Con
> - Slow file creation without special optimizations skipping the UID/GID
> 2 SID 2 UID/GID conversion. Maybe we could use a VFS call to read and
> write nfs4 ACLs instead of using a callback?

Yes, we should do this, for multiple reasons.  We shouldn't convert from
an NFS ACL to an NT ACL unless we must, because even this good
conversion is lossy - if for example the idmapping isn't possible. 

Just like the posix ACLs have VFS APIs, so should this. 

> - Additional system calls are required after file creation to update the
> ACL with the mode bits. There's a slight chance that someone changes the
> ACL between these calls. Relatively low risk since the rewritten ACL is
> the one from before and the access with that ACL could be gained anyway
> by opening thefile before the other process changes the ACL.

I'm not worried by this.

> - Files created on nfs with inheriting ACLs might not have the expected
> mode bits but could get them after rewriting the ACL through SMB.
> - Additional code necessary to handle owner changes through SMB well.

We can only hope that we can apply some pressure to NFSv4 ACL-aware FS
developers to create a sensible solution here.  This is still new
ground, and even so I've seen zfs has a 2 sets of at least 4
configuration modes.  I can reasonably assume that at some point when
these come to native Linux file systems, similar concerns will be
expressed and possibly fixed there, at least optionally. 

> nfs4:mode special
> 
> Pro
> - Posix mode bits on files.
> - Files keep mode bits applied through chmod when rewriting the ACL with
> SMB.
> - No overhead on file creation
> - Compatibility: Required to read ACLs written with mode special in a
> way that the written ACL and the read ACL matches.
> 
> Con
> - Inheritance of ACL entries for the file owner and file group is
> broken.
> - Can't support creator owner and creator group entries.
> - Owner changes through SMB doesn't work.

I think we need to clearly mark mode special as broken and deprecated.

Andrew Bartlett

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