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

[Rick Macklem <[e-mail]>]

On Fri, Jun 7, 2024 at 1:48 PM David Noveck <[e-mail]> wrote:
>
>
>
> On Fri, Jun 7, 2024, 11:20 AM Chuck Lever III <chuck.lever=[e-mail]> wrote:
>>
>>
>>
>> > 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.
>
>
> Agree.
>>
>>
>>
>> > 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.
>
>
> Complicated is OK but impossible is not.  Although I will not be able to reference this in the current document, with the aclchoices attribute supported you would be able to do the determine the mapping necessary and decide when it is essentially the identity.
>
>>
>>
>> > 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.
Just fyi, I prototyped a POSIX draft (or UNIX) ACL implementation on FreeBSD and
it seems to work ok.

Here's the XDR for what I prototyped:

enum acetag4 {
        POSIXACE4_TAG_USER_OBJ     = 1,
        POSIXACE4_TAG_USER         = 2,
        POSIXACE4_TAG_GROUP_OBJ    = 3,
        POSIXACE4_TAG_GROUP        = 4,
        POSIXACE4_TAG_MASK         = 5,
        POSIXACE4_TAG_OTHER        = 6
};

typedef uint32_t        aceperm4;

/* Bit definitions for aceperm4. */
const POSIXACL4_PERM_EXECUTE    = 0x00000001;
const POSIXACL4_PERM_WRITE      = 0x00000002;
const POSIXACL4_PERM_READ       = 0x00000004;

struct posixace4 {
        acetag4         tag;
        aceperm4        perm;
        utf8str_mixed   who;
};

And I defined two new attributes:

posix_access_acl      posixace4<>;
posix_default_acl     posixace4<>;

which are both RW, per file attributes.
I would not allow any given file to support both the "acl" and
"posix_access_acl/posix_default_acl" attributes.
It also might be preferable to specify that it be one or the other
on a per file system basis.

I have not tried seeing what happens if some files on the server's file
system have the POSIX draft ACLs and others NFSv4 ACLs.
(UFS allows you to flip flop between the two types of ACLs when you
reboot.)

I think we need to wait for feedback from others before proceeding further.

rick
ps: I have no burning desire to write this up, but if no one else is interested,
      I can take a stab at it.
>
>
> Yes.   The documents could be developed at the same time but I think I think it would be a problem to submit the extension to the IESG first, given that acl document is supposed to be  nfsv4-wide.
>
> I think what will happen is that there will need to be a small update of the ACL document once the extension document is published.
>>
>>
>>
>> --
>> Chuck Lever
>>
>>
>> _______________________________________________
>> nfsv4 mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]