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

[Rick Macklem <[e-mail]>]

On Thu, Jul 25, 2024 at 5:50 AM David Noveck <[e-mail]> wrote:

>
>
> 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.
>
> Christoph pointed out to me that having multiple ACLs on a file is not
reasonable.  The draft I am writing will require a server to only support
one ACL model/file. (I think it needs to be a server choice and could be
indicated to the client by which attributes are supported for the fiile.
(This is related to the last point.  I'll leave the rest for others.)

It would be nice if, somehow, the Linux folk could determine how often
the mapped NFSv4 ACLs are used on the Linux NFSv4 servers?

rick


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