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

[Trond Myklebust <[e-mail]>]

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]