[nfsv4] Re: New Version Notification for draft-dnoveck-nfsv4-acls-01.txt

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

> On Jun 6, 2024, at 6:57 PM, Jeff Layton <[e-mail]> wrote:
> 
> On Wed, 2024-06-05 at 12:47 -0700, Rick Macklem wrote:
>> On Wed, Jun 5, 2024 at 8:56 AM Jeff Layton <[e-mail]>
>> wrote:
>>> 
>>> On Mon, 2024-06-03 at 16:50 -0700, Rick Macklem wrote:
>>>> On Sun, Jun 2, 2024 at 6:47 PM Rick Macklem
>>>> <[e-mail]>
>>>> wrote:
>>>>> 
>>>>> On Sun, Jun 2, 2024 at 4:36 PM David Noveck
>>>>> <[e-mail]>
>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Sun, Jun 2, 2024, 4:35 PM Rick Macklem
>>>>>> <[e-mail]> wrote:
>>>>>>> 
>>>>>>> On Sun, Jun 2, 2024 at 4:50 AM David Noveck
>>>>>>> <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Saturday, June 1, 2024, Rick Macklem
>>>>>>>> <[e-mail]> wrote:
>>>>>>>>> 
>>>>>>>>> On Fri, Apr 26, 2024 at 11:17 AM David Noveck
>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>> 
>>>>>>>>>> I've just posted the new draftof the acls doc, split
>>>>>>>>>> out
>>>>>>>>>> from security as suggested during previous working
>>>>>>>>>> group
>>>>>>>>>> discussions.   For summary information on this
>>>>>>>>>> document,
>>>>>>>>>> see slides 11-15 of the attached slide deck.
>>>>>>>>>> 
>>>>>>>>>> At the recent interim meeting, both Chris and Tom H
>>>>>>>>>> suggested that it would be good, at this point, to
>>>>>>>>>> get
>>>>>>>>>> people's opinions about the best way to proceed
>>>>>>>>>> forward
>>>>>>>>>> in dealing with ACLs.  I agree that this is a good
>>>>>>>>>> idea
>>>>>>>>>> and join with them in asking people to contribute
>>>>>>>>>> their
>>>>>>>>>> views.
>>>>>>>>>> 
>>>>>>>>>> I've already provided my own outline of a set of
>>>>>>>>>> suggestions regarding ways forward in slides 21-24 of
>>>>>>>>>> the
>>>>>>>>>> attached slide deck.  My updated response will be two
>>>>>>>>>> parts:
>>>>>>>>>> 
>>>>>>>>>> As the preliminary step in the process: Read The
>>>>>>>>>> Fabulous
>>>>>>>>>> Draft :-)
>>>>>>>>>> I'll be sending out updated suggestions regarding the
>>>>>>>>>> choice of ways forward in the next few days.   While,
>>>>>>>>>> broadly speaking, this is consistent with what is in
>>>>>>>>>> the
>>>>>>>>>> slide deck, there are changes beyond those involved
>>>>>>>>>> in
>>>>>>>>>> presenting these ideas in a non-powerpunctual way,
>>>>>>>>>> e.g.
>>>>>>>>>> by writing coherent paragraphs.
>>>>>>>>> 
>>>>>>>>> I have been working through the draft slowly and beyond
>>>>>>>>> the
>>>>>>>>> proposed
>>>>>>>>> ACLFeatures attribute,
>>>>>>>>> I do not see how this resolved the problem for the
>>>>>>>>> POSIX
>>>>>>>>> draft ACL
>>>>>>>>> folk (aka Linux). The
>>>>>>>>> draft talks about how this is working to resolve the
>>>>>>>>> POSIX-
>>>>>>>>> draft vs
>>>>>>>>> NFSv4 ACL situation.
>>>>>>>>> David, maybe you can point out where to look in the
>>>>>>>>> draft
>>>>>>>>> to understand this?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> There have been some changes in plans that I discussed at
>>>>>>>> the
>>>>>>>> 5/21 interim meeting.
>>>>>>>> 
>>>>>>>> To quickly summarize:
>>>>>>>> 
>>>>>>>> I discovered that Section 9 of RFC8178 allow limited so
>>>>>>>> that
>>>>>>>> I am planning in acls-02, of taking advantage of that, by
>>>>>>>> add
>>>>>>>> an optional aclchoice attribute, much simpler than
>>>>>>>> ACLFeature
>>>>>>>> to v4.1, rather than waiting for v4.2.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> The current target date for acls-02: is 6/20.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I do not know if it has already been discussed, but has
>>>>>>>>> revisiting
>>>>>>>>> this decision been considered?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> It was discussed early on.  The response was quite
>>>>>>>> negative
>>>>>>>> (it seemed people didn't want to hear about it) so I
>>>>>>>> dropped
>>>>>>>> it.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> *  Defining support for the two types of ACLs by means
>>>>>>>>> of
>>>>>>>>> two
>>>>>>>>>       separate attributes.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I personally think this is a good idea but I think it is
>>>>>>>> too
>>>>>>>> big to do in v4.1 but would require a v4.2 extension.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>    *  Providing the client other means (e.g. a per-fs
>>>>>>>>> read-
>>>>>>>>> only OPTIONAL
>>>>>>>>>       attribute) by which the client can determine
>>>>>>>>> which
>>>>>>>>> semantic model
>>>>>>>>>       was implemented.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> That is pretty close to what aclchoice turns out to be
>>>>>>>> for
>>>>>>>> those providing the UNIX acl model.  Those providing the
>>>>>>>> nfsv4 model or a hybrid would need to make few more
>>>>>>>> choices
>>>>>>>> about what extensions they do support.
>>>>>>> So, is the plan to have an "inverse algorithm"
>>>>>> 
>>>>>> 
>>>>>> Almost certainly not since I have no idea what you are
>>>>>> talking
>>>>>> about.  Sigh!
>>>>> I was referring to...
>>>>> f(X) -> Y
>>>>> f'(Y) -> X
>>>>> the f'() { or f-prime } function that  generates X given Y, if
>>>>> f(X)
>>>>> is
>>>>> the basic function.
>>>>> (Sorry, my math from the 1970s has just gone away, so I cannot
>>>>> remember what the
>>>>> term for f'(Y) is, given f(X).)
>>>>> 
>>>>>> 
>>>>>>> (for want of a better
>>>>>>> term)
>>>>>> 
>>>>>> 
>>>>>> The particular term is not the problem.
>>>>>> 
>>>>>>> that the
>>>>>>> 
>>>>>>> client can use to generate a NFSv4 ACL that translates
>>>>>>> cleanly
>>>>>>> to a UNIX
>>>>>>> ACL.
>>>>>> 
>>>>>> 
>>>>>> The specification should provide enough information for a
>>>>>> client
>>>>>> to generate the ACL in this case.  Is that what you are
>>>>>> looking
>>>>>> for?
>>>>> I am looking for f'(Y), so that the FreeBSD client can generate
>>>>> a
>>>>> NFSv4 ACL to put on the wire, such that it gets translated back
>>>>> to the same UNIX ACL that the FreeBSD client wanted to set.
>>>>> 
>>>>>> 
>>>>>>> when the Linux function nfs4_acl_nfsv4_to_posix() is
>>>>>>> applied to
>>>>>>> it?
>>>>>> 
>>>>>> 
>>>>>> I suppose so although I am just guessing about that function.
>>>>>> 
>>>>>>> 
>>>>>>> If such an algorithm exists (I cannot recall if I have ever
>>>>>>> heard of
>>>>>>> one?), .
>>>>>> 
>>>>>> 
>>>>>> If it doesn't, one can be written.
>>>>>> 
>>>>>>> a client
>>>>>>> could use an attribute to indicate the server is following
>>>>>>> the
>>>>>>> UNIX acl model
>>>>>> 
>>>>>> 
>>>>>> That is probably not needed since, in NFSv4, the UNIX ACL
>>>>>> model
>>>>>> is embedded in the full NFSv4 ACL model, i.e. every UNIX ACL
>>>>>> is
>>>>>> an NFSv4 ACL but the reverse is not the case.
>>>>>> 
>>>>>>> to
>>>>>>> enable use of such an algorithm to convert a UNIX acl to a
>>>>>>> NFSv4 ACL to go
>>>>>>> on the wire
>>>>>> 
>>>>>> 
>>>>>> Yes.
>>>>>> 
>>>>>>> (and see the same ACL in a Getattr/ACL done against such a
>>>>>>> server).
>>>>>> 
>>>>>> 
>>>>>> Probably not exactly.  For example, a client that does not
>>>>>> support the mask bits that are finer-grained correlates of
>>>>>> the
>>>>>> write privilege bits may see these in the acls that come back
>>>>>> from serves that do support these.  Acls-02 will be clear a
>>>>>> out
>>>>>> the possible need to mask these out.
>>>>> The case I was trying to solve via GetPosixACL/SetPosixACL
>>>>> would be
>>>>> UNIX ACLs, not ones using other
>>>>> flags or finer granularity.
>>>>> 
>>>>>> 
>>>>>> Another problem is the orphan mask bits which don't fit in
>>>>>> the
>>>>>> varying-granukarity model.  There are more complexities with
>>>>>> regard to these but it will be possible to mask these out for
>>>>>> ACLs that are within the UNIX semantic model.
>>>>>>> 
>>>>>>> 
>>>>>>> I do not think the Linux client does this at this time. I
>>>>>>> have
>>>>>>> assumed
>>>>>>> (quite possibly
>>>>>>> incorrectly) that the "inverse algorithm" did not exist.
>>>>>>> All I can see (I'm an not conversant with the Linux
>>>>>>> sources) is
>>>>>>> client
>>>>>>> side support
>>>>>>> for the NFSv3 ACL protocol.
>>>>>> 
>>>>>> 
>>>>>> That  doesn't sound right to me.  It  implies that there is 
>>>>>> no
>>>>>> ACL support in NFSv4 Linux clients.  I don't think k that is
>>>>>> the
>>>>>> case.
>>>>> Well, the Linux client folk will need to answer this.
>>>> I tried a test with the Linux client NFSv4 mounting a FreeBSD
>>>> server
>>>> and all I saw
>>>> on the wire were Getattrs for things like "mode". I never saw a
>>>> Getattr for "acl" when
>>>> I did getfacl on the Linux client.  Setfacl on the Linux client
>>>> failed
>>>> with "operation not supported",
>>>> although there was no such error reply from the FreeBSD server,
>>>> on
>>>> the
>>>> wire (and there was no
>>>> Setattr operation on the wire, either).
>>> 
>>> 
>>> That's expected. The NFSv4 client does not present POSIX ACLs to
>>> userland. You need nfs4_get/setfacl for to see the v4 ACLs.
>>> 
>>>> 
>>>> There is Linux kernel client support for the NFSv3 NFSACL
>>>> sideband
>>>> protocol for NFSv3,
>>>> but FreeBSD does not support that.
>>>> 
>>>> And, as I noted before, there are separate userspace commands
>>>> (not
>>>> usually in the distros)
>>>> nfs4_getfacl/nfs4_setfacl available as open source (used to be
>>>> maintained by Bruce Fields).
>>>> They do not build easily for the Linux system I have, so I have
>>>> not
>>>> tried them, but I would assume
>>>> similar results to what I get with the FreeBSD client. (See
>>>> below.)
>>>> 
>>> 
>>> This is shipped in fedora in the nfs4-acl-tools package, if you're
>>> using that. Other distros probably ship the same package.
>>> 
>>> FWIW: there is this document too from Bruce several years ago,
>>> which
>>> lays out the "rules". We could resurrect that if it's helpful:
>>> 
>>>  
>>> https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-acl-mapping-05
>> Thanks Jeff. This clears things up nicely for me. It does specify an
>> algorithm
>> and notes the one case where a UNIX ACL->NFSv4 ACL mapping cannot be
>> done.
>> 
>> For me, it is either:
>> a) - implement the UNIX ACL->NFSv4 ACL algorithm in the
>>       above document
>> or
>> b) -  define an extension to NFSv4.2 which includes operations
>>         to get/set UNIX ACLs (GetPosixACL/SetPosixACL or whatever
>> they
>> get called)
>> 
>> Understandably David is not interested in b), but I will wait to see
>> what others think.
>> (I think it would be nice if some of the above draft could be
>> captured
>> in David's draft,
>>  but I understand if that is not practicable.)
>> 
>> rick
>> ps: I will look at David's next draft, to see how it correlates with
>> what OpenZFS currently
>>       implements.
>> 
> 
> 
> FWIW, I'd love to see POSIX ACL extensions for v4, as would most Linux
> NFSv4 users.
> 
> Given that v4 ACLs are implemented as file attributes, I'd probably
> suggest not defining new operations, but instead defining an optional
> POSIX ACL file attribute that is settable. Something like section 6.2.1
> in RFC8881, but that mirrors draft POSIX ACLs.

A new fattr4 attribute for accessing Posix ACLs would be nifty.


> Servers that are exporting filesystems that natively support POSIX ACLs
> can then offer that attribute to clients and users could once again use
> "standard" getfacl/setfacl tools to deal with them.

Interoperability with NFSv4 access control, or with servers
that support only NFSv4 ACLs, might still be complicated.


> I understand David not wanting to take on more scope creep though.
> Maybe we should consider it as a separate document / project?

It would have to be an extension to NFSv4.2, by current rules.


--
Chuck Lever