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

[Chuck Lever III <[e-mail]>]

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


--
Chuck Lever