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

[Rick Macklem <[e-mail]>]

On Tue, Jul 23, 2024 at 11:09 AM Trond Myklebust <[e-mail]>
wrote:

> 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.
>
Ok. It sounds like you support the concept of extending NFSv4.2
to support POSIX draft ACLs.  If this is not the case, please
clarify this?

Given the above, I will get back to writing a IETF draft describing
POSIX draft ACL attributes as I prototyped them, as a starting point
w.r.t. this.

rick


> 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
>