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

[David Noveck <[e-mail]>]

I agree.  The existence of prior art would only prevent us from patenting
our protocol, which we don't want to do.

On Tue, Jul 23, 2024, 8:09 PM Trond Myklebust <[e-mail]>
wrote:

> On Tue, 2024-07-23 at 23:15 +0000, Trond Myklebust wrote:
> > On Tue, 2024-07-23 at 21:26 +0000, Chuck Lever III wrote:
> > >
> > >
> > > > On Jul 23, 2024, at 4:39 PM, Trond Myklebust
> > > > <[e-mail]> wrote:
> > > >
> > > > On Tue, 2024-07-23 at 19:06 +0000, Chuck Lever III wrote:
> > > > >
> > > > >
> > > > > > On Jul 23, 2024, at 2:09 PM, 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.
> > > > > >
> > > > > > 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.
> > > > >
> > > > > That's all very nice, but....
> > > > >
> > > > > I'm not talking about mapped NFSv4 ACLs or
> > > > > developing legacy implementations, so let's put
> > > > > aside those straw men, please. You seem to be
> > > > > getting excited about something I didn't write
> > > > > nor did I intend.
> > > > >
> > > > > The proposed fattr4 POSIX ACL support needs to be
> > > > > compatible with NFSACL as well. The view of POSIX
> > > > > ACLs from an NFSv3 mount needs to be compatible
> > > > > with whatever can be seen via the proposed NFSv4
> > > > > POSIX ACLs.
> > > > >
> > > > > At the very least, those compatibility requirements
> > > > > need to be stated in acls-04. I wasn't necessarily
> > > > > looking for an on-the-wire form of compatibility,
> > > > > that's just what Rick brought up in the discussion.
> > > > > And I had no idea that NFSACL had a version 4.
> > > > >
> > > > > But semantic compatibility is needed, and that is
> > > > > complicated by not having a published first-order
> > > > > description of the legacy semantics.
> > > > >
> > > > > Further, acls-04 needs to address the fact that what
> > > > > it is to propose looks semantically and on-the-wire
> > > > > a lot like NFSACL, and that protocol has been in the
> > > > > wild for 25+ years, has no published specification,
> > > > > and is very likely encumbered. This IP issue has to
> > > > > be spelled out and addressed somehow.
> > > > >
> > > > > A simple, concrete proposal would be for Oracle to
> > > > > contribute NFSACL to the IETF via an Informational
> > > > > document similar to RFC 1813.
> > > > >
> > > >
> > > > The draft POSIX ACL spec is not based on some spec for NFSACL.
> > > > The
> > > > draft POSIX ACL spec is IEEE 1003.1e draft 17.
> > >
> > > This distinction is likely to be lost on casual or
> > > even somewhat expert readers -- perhaps a reader
> > > who is not technically informed but is looking for
> > > a legal opportunity. The /purpose/ of NFSACL and the
> > > proposed protocol are the same, and so is the set
> > > of architects who are working on these protocols.
> > >
> > > acls-04 should therefore recognize that NFSACL is
> > > prior art and explain the differences in provenance
> > > that unlink acls-04 from NFSACL. For extra credit,
> > > use the term "clean room implementation" in one or
> > > more complete sentences.
> > >
> > >
> > > > The contents of the NFSACL xdr file are at best a description of
> > > > an
> > > > API
> > > > that we will not be wanting to follow, because it describes an
> > > > RPC
> > > > side
> > > > band protocol, and is based on NFSv3 semantics. It does not
> > > > describe
> > > > draft POSIX acls.
> > >
> > > Which is why I agree that nfs_acl.x by itself is
> > > not up to the task of backing up IP claims, and
> > > would like to see more substantive documentation.
> > >
> > >
> > > > If you want a reference that is independent of the IEEE draft,
> > > > then
> > > > why
> > > > not instead go for Andreas' Freenix paper from 2003?
> > > >
> https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html
> > > > That actually describes in detail the spec that needs to be
> > > > followed.
> > >
> > > IMO this doesn't address the IP issue at all.
> >
> > What IP issue? AFAICS, you've invented the straw man here.
> >
> > Nothing we do here needs to refer to or infringe upon anything Oracle
> > may think it owns w.r.t. nfsacl. There is no need to use anything
> > from
> > nfsacl.x.
>
> Put differently: if you claim there is an IP issue that precludes us
> from defining our own protocol for draft POSIX acls, then you need to
> document what is infringing. The existence of "prior art" for an
> implementation does not automatically imply that there is an
> intellectual property issue to resolve.
>
> --
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> [e-mail]
>
>
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>