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

[David Noveck <[e-mail]>]

On Wed, Jul 24, 2024 at 11:25 PM Trond Myklebust <[e-mail]>
wrote:

> On Wed, 2024-07-24 at 08:43 -0400, David Noveck wrote:
>
>
>
> On Tue, Jul 23, 2024 at 8:34 PM Trond Myklebust <[e-mail]>
> wrote:
>
> On Tue, 2024-07-23 at 20:17 -0400, David Noveck wrote:
>
> I agree.  The existence of prior art would only prevent us from patenting
> our protocol, which we don't want to do.
>
>
> An existing patent might preclude us from using whatever method is being
> patented. Copyright might prevent us from using specific code in nfsacl.x,
> but only if that code was not part of the IEEE draft or there exists some
> other claim that precedes the publication of the IEEE draft and hence might
> pre-empt the use of the spec that was documented there.
>
> Either way, we should be able to work around any IP claim in order to
> publish our own implementation, provided that we know what the claim is.
>
>
> The problem we have  is what do we do in the meantime?
>
> It doesn't seem that a clear answer is likely in the near future.  I don't
> think we can wait indefinitely for a potential claim.  There may be some
> defensive things we can do in advance of any potential claim but if so,
> that work needs to start fairly soon.
>
> On a lighter note, if, as you say, Chuck has "*invented *a straw man"
> (emphasis added),  does that raise an IP issue?   Given that Chuck
> probably has no intention of patenting his invention (lack of usefulness,
> tons of prior art ...), how does he disclaim any possible IP? Perhaps Chris
> knows of some declaration he could make :-)
>
>
> I suspect even Oracle's army of lawyers could not draft a patent for the
> concept of a straw man proposal given the vast quantities of prior art. 🙂
>
>
> Now, more seriously, there is an important clarification that needs to be
> made.  *draft-dnoveck-nfsv4-acls-04 * does not, as some suppose it does,
> define a protocol to be used to support draft POSIX.   As a result, any IP
> issues that arise in the future would be unlikely to apply to that document
> and there seems no reason to update it to refer to how that protocol
> might be implemented in the future, when such a protocol is defined.  I
> think there is room to clarify the discussion and referencing and andreas'
> document seem likes something I could do in -05.
>
> What this document does do is specify how the existing protocol, with a
> few minor protocol extensions, could support the semantics of draft POSIX
> ACLs .  I can see how one would like to do more than this in v4.1 but I
> don't think it is possible to add to v4.1 now.  That work would have to be
> done as an NFsv4.2 extension.   There has been some discussion of this
> possibility but there is as yet no protocol-level specification.  The
> following have been discussed:
>
>    1. Rick has discussed the possibility of a v4.2 extension but using
>    new attributes has not committed to writing it up.   I'm worried that he
>    might lose interest given the possibility of IP horrors, but I really don't
>    know. From my point of view, the weakness in Rick's approach is that it
>    does not address migration and coexistence issues.  I think that is
>    essential given the history here but many files with ACLs exist on file
>    systems and I think it's important to address the issues of how the
>    existing model and a new one will interact.
>    2. Appendix C of the ACLs document has some suggestions about building
>    a potential v4.2 extension on some of the extensions in acl-04.  My focus
>    is on the migration and coexistence issues and I hope it is adequate from
>    others point of view.
>
> I'd like to discuss these two and see how we can work together to
> support everybody's needs.   The only alternative seems to be to go back in
> time and do this as it should have from the beginning.  That's almost
> certainly not possible but it would make an interesting IPR declaration :-)
>
>
> As I said in my reply to Rick's email, I believe we need to treat the two
> ACL models as being different,
>

True, but we do have to take account of the fact one one is a subset of the
other.

and I think we want to be careful about trying to define further mappings
> between the two models.
>

Fair enough.


> While the model that Marius and Bruce drafted over 20 years ago now is
> sufficient to describe how to map POSIX draft acls reversibly into NFSv4
> acls.
>

Yes it does.


> it has no answers when it comes to mapping arbitrary NFSv4 acls into POSIX
> draft acls.
>

True but that is not because Mariius and Bruce failed in any way.   This
could not be done because it is impossible.  In fact, the NFSv4 ACL
was *designed
*to result in that situation since these ACLs were intended to be able to
specify things that could not be specified in the draft POSIX ACL model.



> 20 years of hindsight does not appear to have yielded any new
> possibilities in that respect, but teaches us that we will always be able
> to find NFSv4 acls that cannot be reversibly mapped into POSIX acls.
>

without much effort.  They are easy to find.

>
> At this point, therefore, my proposal is that we punt the issue of
> mappings into userspace libraries so that we do not attempt to enforce a
> particular set of compromises through a spec that gets enforced at the
> kernel and server levels.
>
> There are several points that I'd like to make:

   - There is a large set of NFSv4 ACLs that *can be *reversibly mapped to
   NFSv4 ACLs.
   - Because of some gaps in the original NFSv4 ACL model, many of the
   extensions in the NFSv4 ACL model cannot be reliably used.  As a result,
   whille it is easy to formulate non-mappable cases, in many environments the
   number of such ACLs that exist is liable to be small.
   - If one punts mapping in general to userspace, then this complicates
   the handling of the common case to accommodate a case that will not often
   be seen.  In any case, if this mapping is to be done, there has to be
   implementation guidance about how to do it.
   - I think it would be simpler and better to describe the unproblematic
   mapping in a standards-track document. and leave the mapping of the
   difficult cases to implementer judgment, wherever the actual mapping
   happens.
   - Even apart from the mapping issue, they cannot be kept entirely
   separate.  For example, when I set a draft POSIX acl using a
   draft-posix-acl-specific attribute, one would expect that to supersede an
   existing NFSv4 ACL.  Having two ACLs on a single file is kind of a drag
   from a fs implementation point of view.   QA-ing that is a total nightmare.


>
>
> 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
> CTO, Hammerspace Inc
> 1900 S Norfolk St, Suite 350 - #45
> San Mateo, CA 94403
> www.hammerspace.com
>
>