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

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

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


>> And, this is prior art. If the authors and WG are comfortable
>> citing a CDDL-encumbered .x file in acls-04, then there's no
>> need to author an historical Informative document.
>> 
>>> The goal of this group should be to make a version that is
>>> appropriate
>>> for NFSv4. That would need to be a new protocol extension for NFSv4
>>> that is separate from the existing ACL attribute.
>>> 
>>> Even the XDR format of the ACEs will need to be different due to
>>> the
>>> adoption of name@domain format user and group descriptions that
>>> replace
>>> the uid/gid format.
>>> So there is little overlap with the existing nfsacl.x file (which
>>> existed as a file with no valid licence description in the glibc
>>> rpc
>>> implementation for many years prior to the existence of the CDDL).
>> 
>> Implementers will need to understand the differences and
>> ensure that there is compatibility when presenting ACLs to
>> users, for example. It sounds like there are indeed some
>> compatibility issues worth mentioning.
>> 
>> I'm simply asking if additional standards action is needed
>> to ensure that the older work is available and citable in
>> new documents.
> 
> Bruce and Marius' draft should suffice to document the legacy non-
> standard. It is still available from the data tracker:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-acl-mapping/

So again, it sounds like there does need to be standards
action if the WG feels that this expired draft cannot
be legitimately cited by a new document. My recollection
of the citation rules suggests that it cannot, but I
might be wrong.

But even if it can be cited, I don't see how that
addresses the IP concerns at all.


--
Chuck Lever