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

David Noveck <davenoveck@gmail.com> Sun, 02 June 2024 11:50 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 45A1CC14F699 for <nfsv4@ietfa.amsl.com>; Sun, 2 Jun 2024 04:50:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Status: No, score=-7.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id SeRhMt1ehjYX for <nfsv4@ietfa.amsl.com>; Sun, 2 Jun 2024 04:50:02 -0700 (PDT)
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 5AAADC14F5E7 for <nfsv4@ietf.org>; Sun, 2 Jun 2024 04:50:02 -0700 (PDT)
Received: by mail-qv1-xf35.google.com with SMTP id 6a1803df08f44-6ae259b1c87so24507196d6.1 for <nfsv4@ietf.org>; Sun, 02 Jun 2024 04:50:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717329001; x=1717933801; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uHKaNphXmcjzPYE7+ZzbExzDyILNcSzcZSRZon+TLK8=; b=klzd+Fzms082K75Y7Kq8Aidx70vmI/eJ7CsTjJOfSoGijvX52cw7prIzsjRwH3kDtw pIh6TzGUpyacDxLsXclBnW/jGexkPMObrZtV0ScAMQF3YMrygdaRxCQ+X61XK6b0IkrC UNo5eht2scQUQ1A8kpfEkrnL++N4Wv9O198aFwmGBhEXJfU9+qheXKoshmJLmp0BMWgN IuxoyRnBe/Q0RCDCT/R9draazBVFJJiM8xsQKDhoBR4C9ZVUlQyfnZpJO5uTQ1dsK89J qn1/rq8t7SaigpAuVtsKgPFM/wvohBPhlKZ4kfG4MwikMLnGqwnqKq5qrbDIzyyQYth+ QaRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717329001; x=1717933801; h=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=uHKaNphXmcjzPYE7+ZzbExzDyILNcSzcZSRZon+TLK8=; b=oBNry/wCbURrKuLaadvIBaLyU+ajA7Pw2JHr/909gBJnYGrEP9DUbwcy+vuVtr+CgH xbyaDLZDnMImob3WcYGuz9Z34o+ujjrzQlb0bTJ/y/2MMHSTqrELYv50E7soqdh2pQah qEAH/3NSq97bHlZpBz9UT/mFBBYF76BkXksbYl9/U5eCtXk8+sM7SiSN9nxrVSz8rkCl h88HRvQlkb07ddiTNqLrhVwI3hrVs3e5yTsPKizGRztvQPsve62OWGYuKWavBhjY4UKA knawWXZIq+m/UIpWAsXa0+aBuBJgG4SE3VstP+KDBb9ZEtn5R9OKKAi6RHBUPLfhCr1F R4Ew==
X-Gm-Message-State: AOJu0YwRorpn+JnS2Mx1apDcEM3Ck9QHBKO10dMGplJyvd3hg60W0kpX zLdQFbRs6yWqOotusvuRvDOTIaWlqpCV4F73LpCPpYfgqCdra31LBepZfxCGAtDVz49V5AAuhmE tje2OTB83hNR0+SUJR0hKiXw+bVA=
X-Google-Smtp-Source: AGHT+IFyYMFUinGC7vtOHjIjkaeLjsk5oVs9spiaaNHvx5gqisiCUVC1gn9VNNxRuoTyy5aMGaGg0/CJkqRvpPpimoM=
X-Received: by 2002:a0c:eb08:0:b0:6af:351b:bb0e with SMTP id 6a1803df08f44-6af351bbdc3mr50704086d6.14.1717329000675; Sun, 02 Jun 2024 04:50:00 -0700 (PDT)
MIME-Version: 1.0
References: <171415518303.3337.11515633260776443720@ietfa.amsl.com> <CADaq8jfNeu9ZAibEBLp=+EtczS69k1rQK1X57mvmbMLGdY8ztg@mail.gmail.com> <CAM5tNy6RndufxNq3+2CYvQYzt2PAoiLyyQiZErMcoSQDwVmm6A@mail.gmail.com>
In-Reply-To: <CAM5tNy6RndufxNq3+2CYvQYzt2PAoiLyyQiZErMcoSQDwVmm6A@mail.gmail.com>
From: David Noveck <davenoveck@gmail.com>
Date: Sun, 02 Jun 2024 07:49:48 -0400
Message-ID: <CADaq8jdqsJQ5pMQsj0obENvmMqF6oKkiQffHVVcFygMucPMmxg@mail.gmail.com>
To: Rick Macklem <rick.macklem@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000000c43830619e6d1b9"
X-MailFrom: davenoveck@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/iD3MUDRKmggztbNBwu6oQ4E1-YI>
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 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

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.

>    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

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

> 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

> 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