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

Rick Macklem <rick.macklem@gmail.com> Mon, 03 June 2024 01:47 UTC

Return-Path: <rick.macklem@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CDFC14F5FE for <nfsv4@ietfa.amsl.com>; Sun, 2 Jun 2024 18:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlOFA3mjByRT for <nfsv4@ietfa.amsl.com>; Sun, 2 Jun 2024 18:47:36 -0700 (PDT)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A4AC14F5F5 for <nfsv4@ietf.org>; Sun, 2 Jun 2024 18:47:36 -0700 (PDT)
Received: by mail-pg1-x52e.google.com with SMTP id 41be03b00d2f7-652fd0bb5e6so3055035a12.0 for <nfsv4@ietf.org>; Sun, 02 Jun 2024 18:47:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717379255; x=1717984055; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=loYZfrgZn4gtohSket2doV40Ly8TUzr0lf1muFwQw5k=; b=HnXQxB9mFKIN+axlEjIQAnQALHAD1sxsoAXchjcNJMOVWg2Vjj5LjGwW0ejNGDo9s5 6YLwG27hYpu0yuOOtYz+/jfwwmDYEr1TmWxKfAoa1Wgj5RXB3x7Zhag8SJYzByyeRHGu wMj546kFAUeySkXtOZiBYovZZYZGxZXZvsNOpJ/fu4+Ban/9bazWD9wj9W70alm68PUC zYUZ9ZoCV/Iyp17wBBA1QS8vp3vnHc3bGdYC2TVNOB7myAxL0tCbqbqKLkmVYYUmpY9o OmRfLViV83xVIjswV3MH/DT44ZIAUTzAaZckJoSJytlE8wWo07rUkdpJeyUjxF9Wh/Kg b3ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717379255; x=1717984055; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=loYZfrgZn4gtohSket2doV40Ly8TUzr0lf1muFwQw5k=; b=qznGpMZaAT85JuHsw9TdLqtcJnkBpfim14ktGJtMRGfJNoz9hHUT6SpvBM7l3eIVWy Wi3sPw8ZlNgbDrCbDey/4APgDpsl6iDlIQq9I5s4etRFhkkj4+HAIyNBhLHBMaJuyhkC IVP61lkIlYNK1d0g/7zg+169touQUBbr+5c6Kx4iq3gkrXmfB/FCRSRD4XjMwhrPph6A lAfZQkpcisgwIlqIi71PZOqs7xhzyiuZfHzss/ESnXcDVLr0mA5qDuqffEyyq6zNhwZm JCljK1nf7Cg4MSeU9NxulfhQTzDAPxSW9KLceggVJvMCH2xaZQeLdKhGT6QipxT+90t9 i7Iw==
X-Gm-Message-State: AOJu0YySoYxCm5fgup5ZlAWKVAKUBW/Vr8nQPwezv1H9yCIgpYDq2aZq r78QajiP2kqCknul2CkpI2V/NoIEXhh/eJfb31h7DVcieKAMLVdWkR3dmDgJXYrPcW7lqpgnDP3 Yz24I/SaqCjz/pqSTWOi2iSU58UKP
X-Google-Smtp-Source: AGHT+IGV5phCZd8+HSgPG6JCuyfAX4H2Hp3AnqVDf92PMBi/uEoYEYmnXVrgneP2PzOHgGBpXGtTZ1LOmKwwuYgdJR0=
X-Received: by 2002:a05:6a20:f3a6:b0:1b2:5573:2f3c with SMTP id adf61e73a8af0-1b26f30d800mr7117786637.54.1717379255288; Sun, 02 Jun 2024 18:47:35 -0700 (PDT)
MIME-Version: 1.0
References: <171415518303.3337.11515633260776443720@ietfa.amsl.com> <CADaq8jfNeu9ZAibEBLp=+EtczS69k1rQK1X57mvmbMLGdY8ztg@mail.gmail.com> <CAM5tNy6RndufxNq3+2CYvQYzt2PAoiLyyQiZErMcoSQDwVmm6A@mail.gmail.com> <CADaq8jdqsJQ5pMQsj0obENvmMqF6oKkiQffHVVcFygMucPMmxg@mail.gmail.com> <CAM5tNy5K64ULERss8tyx0EL10iSrNQiPbpeVWNidhixuLVrzWA@mail.gmail.com> <CADaq8jdURkr2MDQBBbB74DVEBO9f=B8mdA9vgyc4vX0YAFZ6aw@mail.gmail.com>
In-Reply-To: <CADaq8jdURkr2MDQBBbB74DVEBO9f=B8mdA9vgyc4vX0YAFZ6aw@mail.gmail.com>
From: Rick Macklem <rick.macklem@gmail.com>
Date: Sun, 02 Jun 2024 18:47:24 -0700
Message-ID: <CAM5tNy41WeF3_FYp=oMx0wti7T9nfcRLvNc46CHUb57HivYwgw@mail.gmail.com>
To: David Noveck <davenoveck@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: YP2PAD2DKGYEZC7DZ6OYZOSKBDBR2YVJ
X-Message-ID-Hash: YP2PAD2DKGYEZC7DZ6OYZOSKBDBR2YVJ
X-MailFrom: rick.macklem@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-nfsv4.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: NFSv4 <nfsv4@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [nfsv4] Re: New Version Notification for draft-dnoveck-nfsv4-acls-01.txt
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/CC3e9vraFRF-Oz6NoZnZSzx9tio>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Owner: <mailto:nfsv4-owner@ietf.org>
List-Post: <mailto:nfsv4@ietf.org>
List-Subscribe: <mailto:nfsv4-join@ietf.org>
List-Unsubscribe: <mailto:nfsv4-leave@ietf.org>

On Sun, Jun 2, 2024 at 4:36 PM David Noveck <davenoveck@gmail.com> wrote:
>
>
>
> On Sun, Jun 2, 2024, 4:35 PM Rick Macklem <rick.macklem@gmail.com> wrote:
>>
>> On Sun, Jun 2, 2024 at 4:50 AM David Noveck <davenoveck@gmail.com> wrote:
>> >
>> >
>> >
>> > On Saturday, June 1, 2024, Rick Macklem <rick.macklem@gmail.com> wrote:
>> >>
>> >> On Fri, Apr 26, 2024 at 11:17 AM David Noveck <davenoveck@gmail.com> 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.

>
>> There is the userspace nfs4-acl-tools for Linux, but
>> I thought they assumed a server that supports NFSv4 ACLs.
>
>
> That makes sense.
>
>> and not the NFSv4
>> ACLs translated via nfs4_acl_nfsv4_to_posix() to UNIX ACLs for storage
>> in the file system.
>
>
> Leaving aside the name of Linux routines, from what are these NFSv4 ACLs generated.   I don't expect user use the NFSv4 format ACLs directly.  Are they translated from POSIX-style ACLs?
The Linux knfsd server translates whatever the client has sent via
Setattr of the acl attribute (if I understand the code?).
And, as far as I understand it, the Linux kernel client never does a
Setattr of the acl attribute.
(Again, someone conversant with Linux needs to step in and answer this.)

In the case of FreeBSD, user commands do generate most NFSv4 ACLs. The
limitations are the
ones already mentioned related to ZFS, such as only Allow/Deny.
However, the FreeBSD setfacl/getfacl
commands can also do UNIX ACLs and UFS on FreeBSD can store/use either
model, based on a mount
flag. (If the NFSv4 server only handles UNIX ACLs and there is a way
for the FreeBSD client to know that,
it could set the UNIX ACL flag for the mount, as well.)
The NFSv4 ACLs also get used locally for ZFS stores (which in FreeBSD
have no support for UNIX ACLs at all).

rick
>
>>
>> rick
>>
>> >>
>> >>
>> >>    As things turned out, neither of these approaches were taken, for
>> >>    reasons that will not be discussed here.
>> >
>> >
>> > To summarize, AclFeatures turned out to be too complicated for most clients to use and I decided on a simpler attribute to be included in v4.1 based on the approach in Section 9 of RFC8178.
>> >
>> >>
>> >> What about added two new NFSv4.2 operations: SetPosixACL/GetPosixACL
>> >
>> >
>> > I think it is better to add an attribute than a new set of operations.  The latter would be more complicated to deal with when you  address mode/acl interactions.
>> >
>> >> which are designed
>> >> by the Linux NFSv4 folk, so that they work well for both the Linux
>> >> client/knfsd server?
>> >
>> >
>> > They would have to be acceptable to everyone supporting the UNIX ACL model. That being said, I would like to understand their needs.
>> >
>> >>
>> >> (In particular, what do the Linux implemenation folk think of this?)
>> >
>> >
>> > If they think that is too much work, I would be interested in their comments on acls-02.
>> >>
>> >>
>> >> The FreeBSD client could provide POSIX draft ACL support for a mount,
>> >> if that is what the
>> >> server supports. (UFS on FreeBSD can do either POSIX-draft or NFSv4
>> >> style ACLs, controlled
>> >> by a mount flag, so the NFSv4 client should be able to do the same.)
>> >>
>> >> To be honest, the FreeBSD server will mostly be exporting ZFS file
>> >> stores and, given that users
>> >> use the ZFS NFSv4 style ACLs directly, I cannot see the semantics that
>> >> ZFS supports for NFSv4
>> >> style ACLs, no matter what an RFC says. They currently do Allow/Deny
>> >> in the manner the PSARC
>> >> email explains.
>> >
>> >
>> > I haven't seen that.  Please send reference/link since this is likely to be one of the important hybrids aclchoice will want to deal with cleanly.
>> >
>> >>
>> >>  (This is really up to the OpenZFS folk, so I cannot
>> >> really say, but I do not see any
>> >> interest in ACL implementation changes.)
>> >
>> >
>> > I'm not asking for any.  I just want a clear definition of what they do implement.
>> >>
>> >>
>> >> I have not yet determined if the ACLFeature attribute would be useful
>> >> for the FreeBSD client.
>> >> Currently it simply does a Setattr/ACL which either succeeds or fails.
>> >> I could see ACLFeature
>> >> being used at mount time to determine if ACL support should be
>> >> enabled, however this only
>> >> works if it is "per server" and not "per server file system".
>> >
>> >
>> > What is the problem with a per-fs attribute?  After all, different filesystems on the same server can differ in the type of acl support they provide.
>> >>
>> >>
>> >> rick
>> >>
>> >> >
>> >> >
>> >> > ---------- Forwarded message ---------
>> >> > From: <internet-drafts@ietf.org>
>> >> > Date: Fri, Apr 26, 2024 at 2:13 PM
>> >> > Subject: New Version Notification for draft-dnoveck-nfsv4-acls-01.txt
>> >> > To: David Noveck <davenoveck@gmail.com>
>> >> >
>> >> >
>> >> > A new version of Internet-Draft draft-dnoveck-nfsv4-acls-01.txt has been
>> >> > successfully submitted by David Noveck and posted to the
>> >> > IETF repository.
>> >> >
>> >> > Name:     draft-dnoveck-nfsv4-acls
>> >> > Revision: 01
>> >> > Title:    ACLs within the NFSv4 Protocols
>> >> > Date:     2024-04-26
>> >> > Group:    Individual Submission
>> >> > Pages:    138
>> >> > URL:      https://www.ietf.org/archive/id/draft-dnoveck-nfsv4-acls-01.txt
>> >> > Status:   https://datatracker.ietf.org/doc/draft-dnoveck-nfsv4-acls/
>> >> > HTML:     https://www.ietf.org/archive/id/draft-dnoveck-nfsv4-acls-01.html
>> >> > HTMLized: https://datatracker.ietf.org/doc/html/draft-dnoveck-nfsv4-acls
>> >> > Diff:     https://author-tools.ietf.org/iddiff?url2=draft-dnoveck-nfsv4-acls-01
>> >> >
>> >> > Abstract:
>> >> >
>> >> >    This document describes the structure of NFSv4 ACLs and their role in
>> >> >    the NFSv4 security architecture.  While the focus of this document is
>> >> >    on the role of ACLs in providing a more flexible approach to file
>> >> >    access authorization than is made available by the POSIX-derived
>> >> >    authorization-related attributes, the potential provision of other
>> >> >    security-related functionality is covered as well.
>> >> >
>> >> >    While the goals of the description are similar to that used in
>> >> >    previous specifications, the approach taken is substantally
>> >> >    different, in that the relationship of the multiple ACL models
>> >> >    supported has changed.  A core set of functionality, derived form the
>> >> >    the now-withdrawn POSIX draft ACLs is presented as the conceptual
>> >> >    base of the feature set.  Additional features used to provide the
>> >> >    functionality within the NFSv4 ACL model are presented as OPTIONAL
>> >> >    extensions to that core.
>> >> >
>> >> >    The current version of the document is intended, in large part, to
>> >> >    result in working group discussion regarding repairing problems with
>> >> >    previous specifications of ACL-related features and to enable work to
>> >> >    provide a greater degree of interoperability than has been available
>> >> >    heretofore.  The drafts a framework for addressing these issues and
>> >> >    obtaining working group consensus regarding necessary changes.
>> >> >
>> >> >    When the resulting document is eventually published as an RFC, it
>> >> >    will supersede the descriptions of ACL structure and semantics
>> >> >    appearing in existing minor version specification documents for
>> >> >    NFSv4.0 and NFSv4.1, thereby updating RFC7530 and RFC8881.
>> >> >
>> >> >
>> >> >
>> >> > The IETF Secretariat
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > nfsv4 mailing list
>> >> > nfsv4@ietf.org
>> >> > https://www.ietf.org/mailman/listinfo/nfsv4