[nfsv4] Re: Our different approaches to draft POSIX ACL support in NFSv4

[Trond Myklebust <[e-mail]>]

On Tue, 2024-07-23 at 15:27 +0000, Chuck Lever III wrote:
> 
> 
> > On Jul 23, 2024, at 10:27 AM, Trond Myklebust <[e-mail]>
> > wrote:
> > 
> > On Tue, 2024-07-23 at 13:54 +0000, Chuck Lever III wrote:
> > > 
> > > > On Jul 22, 2024, at 7:13 PM, Rick Macklem
> > > > <[e-mail]>
> > > > wrote:
> > > > 
> > > > I just looked at opensolaris/usr/src/head/rpcsvc/nfs_acl.x
> > > > which I think is the closest thing there is to a spec. for
> > > > NFSACL.
> > > > (FreeBSD does not implement this protocol and all I know about
> > > > it
> > > > is what this little .x file indicates.)
> > > 
> > > That's excellent, thanks for finding it.
> > > 
> > > My concern about this is that the cited .x file falls under
> > > CDDL, and thus cannot be used directly by a GPL-encumbered
> > > OS like Linux, nor can it be contributed to the IETF in its
> > > current form.
> > > 
> > > This is clearly prior art.
> > > 
> > > My question then is whether we should endeavor to produce
> > > an Informational document that describes NFSACL without
> > > encumbrance -- ie, get Sun-Oracle to contribute that work
> > > so that it might be used openly.
> > > 
> > 
> > Why do we care?
> 
> As I explained, we do want to have a protocol specification
> for NFSv4 that will not be disruptive to folks who were using
> NFSv3 and are now accessing the same ACLs via NFSv4.2+

No we don't.

We need a new protocol specification that works correctly with the
draft POSIX acls in use with existing Linux and other filesystem, and
that supports all the features of the IEEE 1003.1e draft 17 document
that were implemented within Linux and the *BSD.
Once we have that, I will happily plug that implementation into the
inode 'get_acl()' and 'set_acl()' callbacks, and people will be able to
use the bog standard getfacl and setfacl utilities to control the POSIX
ACLs as if they were running on a native filesystem.

If people then still want to use the nfs4_getfacl and nfs4_setfacl
tools to use the existing ACL attribute against a server that
implements the draft-ietf-nfsv4-acl-mapping-05 (or whatever it is that
the Linux server actually implements) then they can continue to do so
without any further help from this committee. There will be no need to
encourage the development of further broken implementations, if there
is a real NFSv4.2 API that can replace it.

> 
> And, this is prior art. If the authors and WG are comfortable
> citing a CDDL-encumbered .x file in acls-04, then there's no
> need to author an historical Informative document.
> 
> > The goal of this group should be to make a version that is
> > appropriate
> > for NFSv4. That would need to be a new protocol extension for NFSv4
> > that is separate from the existing ACL attribute.
> > 
> > Even the XDR format of the ACEs will need to be different due to
> > the
> > adoption of name@domain format user and group descriptions that
> > replace
> > the uid/gid format.
> > So there is little overlap with the existing nfsacl.x file (which
> > existed as a file with no valid licence description in the glibc
> > rpc
> > implementation for many years prior to the existence of the CDDL).
> 
> Implementers will need to understand the differences and
> ensure that there is compatibility when presenting ACLs to
> users, for example. It sounds like there are indeed some
> compatibility issues worth mentioning.
> 
> I'm simply asking if additional standards action is needed
> to ensure that the older work is available and citable in
> new documents.

Bruce and Marius' draft should suffice to document the legacy non-
standard. It is still available from the data tracker:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-acl-mapping/

-- 
Trond Myklebust 
CTO, Hammerspace Inc 
1900 S Norfolk St, Suite 350 - #45 
San Mateo, CA 94403 
​
www.hammerspace.com