Re: POSIX ACL support for NFSV4 (using sideband protocol)

["J. Bruce Fields" <bfields@fieldses.org>]

On Wed, Sep 02, 2009 at 01:56:23PM -0500, Steve French wrote:
> "J. Bruce Fields" <bfields@fieldses.org> wrote on 09/02/2009 11:42:43 AM:
> > On Wed, Sep 02, 2009 at 05:54:20PM +0530, Aneesh Kumar K.V wrote:
> > > This patch series implement POSIX ACL support for NFSV4 clients
> > > using sideband protocol.
> >
> > What motivates this?  Who exactly wants this and why?   What would be
> > the advantages compared to other options, such as:
> 
> The most obvious reason to me is that security information
> can be lost as the ACL which was generated by Linux utilities and
> client acl tools (which get/set posix acls) are converted by the Linux nfs
> v4 client

The kernel v4 client doesn't do that--it passes untouched v4 acls to and
from userspace.

(We do have some patches which do that conversion in libacl, but I don't
believe any distribution has ever applied them.)

> to NFSv4 ACLs on the wire and then the server converts them back to posix
> to save them in ext3 (or ext4 or xfs etc.).  This double conversion can
> result
> in a different ACL returned on subsequent queries (e.g. getfacl) than the
> one that the user just set.

Do you have an example?  I may be forgetting some corner case, but I
don't believe there should be any, *except* for those due to name<->id
conversion.

Which is a much larger problem.

(There may also, of course, be translation problems even when only one
side is translating--but I think the id/name translation is still the
bigger problem.)

> At worst this is a security exposure and at
> best it is confusing to the user (and we don't control the tools).
> And Linux client to Linux server is worse than Linux client to some other
> servers because of the extra conversion (which is counter intuitive)
> 
> >    - native v4 support in filesystems, or
> Doesn't help now.  In the future would be nice to have something
> similar to native cifs/ntfs/nfsv4 ACLs in btrfs - but that wouldn't help
> for years - and won't help all of the other Linux
> file systems.

Here's one attempt for ext3:

	http://www.suse.de/~agruen/nfs4acl/

> CIFS and NTFS (and SMB2 in the future) could be modified to return
> something like an NFSv4 ACL, but local file systems aren't likely to
> change.

Could be.  I'd expect serious resistance, but nobody has really tried
yet that I'm aware of.

> In the meantime we don't even have
> a generalized system interface to set/get nfsv4/cifs/ntfs acls so

The current client is using raw xdr-formatted v4 acls in an extended
attribute.  We could consider some other interface if that would be more
useful to other projects.  (Andreas' patches have a different
xattr-based interface which might serve as another example.)

> Linux ACL tools and libraries and server software
> like Samba could be updated to handle something other than
> posix ACLs.   I expect that jra and others of us on the Samba team
> would love to see a few Linux file systems support CIFS/NFSv4/NTFS
> ACLs but as he has reminded people - posix acls are Linux's native
> ACL model.
> 
> >    - improved client-side acl tools that provided a user interface
> >      for v4 acls closer to that for v3 acls, or
> Problem is that ACLs are a "system feature" and the OS tools,
> utilities and desktop GUI tools for Linux use POSIX ACLs since
> Linux's "native acl interface" is the posix one.   It would make
> sense to add a way to query the "preferred acl interface"
> for a file system (and NFSv4 client could query the server
> perhaps via a named attribute to determine the ACL type
> preferred by the server fs).  It is important to use the
> native ACL model of the server operating system
> so that information is not lost unnecessarily in the conversion.
> 
> >    - a v4.x extension to add support to the main protocol?
> 
> Sounds fine to me to add an extension to the main protocol
> but I doubt that it would be necessary - no extension was
> formally added when v3 was extended for posix acls.
> By analogy with cifs - we defined a new request and a new capability
> bit for posix acl support.   CIFS ACL support is expected
> ("should" implement) but posix acl support is optional.  The
> Linux client uses posix acls if the server claims support for it
> and it has not been disabled on the client by mount option.

I'm sympathetic to this kind of argument, but it should be made at
nfsv4@ietf.org.  It will be much harder to push patches that aren't
based on something well on its way to standardization.

--b.