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

Christoph Hellwig <hch@lst.de> Mon, 17 June 2024 06:00 UTC

Return-Path: <hch@lst.de>
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 B5458C14F616 for <nfsv4@ietfa.amsl.com>; Sun, 16 Jun 2024 23:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 m5prsJCV1csh for <nfsv4@ietfa.amsl.com>; Sun, 16 Jun 2024 23:00:12 -0700 (PDT)
Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78396C14F615 for <nfsv4@ietf.org>; Sun, 16 Jun 2024 23:00:11 -0700 (PDT)
Received: by verein.lst.de (Postfix, from userid 2407) id 49B2D68B05; Mon, 17 Jun 2024 08:00:07 +0200 (CEST)
Date: Mon, 17 Jun 2024 08:00:06 +0200
From: Christoph Hellwig <hch@lst.de>
To: Rick Macklem <rick.macklem@gmail.com>
Message-ID: <20240617060006.GD17051@lst.de>
References: <d76024c77a9fa70d2704e6f3a4ec98bd7fe7a973.camel@poochiereds.net> <E45C97DE-5D16-4566-A88A-A172657A4548@oracle.com> <CADaq8je4taT8E5PgMsMJ-c2YuPbgzXwt26YTZfFHPymqneQ0Wg@mail.gmail.com> <CAM5tNy7Dbu=B0EJ2K9OGOe=QUKvhcAg36DtcwCWGDw8s-TpiAw@mail.gmail.com> <CAM5tNy77DCPiJ7QLxC72ZRmEMZYVCG6P0wsAH3ReLKg-h7vcbw@mail.gmail.com> <CADaq8jcNb7HyyixDsvYG-dZgBZgyRaPwtQGuW6u0B72+25cS+A@mail.gmail.com> <CAM5tNy7qrhQTYmnUOurbkBE9YyUt+ejF846HDUOY5bXHt_j1Hw@mail.gmail.com> <CADaq8jekb8jF6SPaRwnef+_C5XQowANcU4DvyUwz33PmOzTfWg@mail.gmail.com> <CADaq8jc+eyzv=pSbHc+C7RtezQ=trQixcGUaXKTK2YY2k2spdw@mail.gmail.com> <CAM5tNy5gnxWku3H+=Bwa=LtChpPQbYU6SA=24H994SDOY=vREQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAM5tNy5gnxWku3H+=Bwa=LtChpPQbYU6SA=24H994SDOY=vREQ@mail.gmail.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Message-ID-Hash: HR57EK2TZO4SPEHTPQOH2SMLU4YQRI2G
X-Message-ID-Hash: HR57EK2TZO4SPEHTPQOH2SMLU4YQRI2G
X-MailFrom: hch@lst.de
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: Fwd: 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/GtM63FY6uAeFtI1mn3hEf-2cblQ>
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 Thu, Jun 13, 2024 at 01:29:24PM -0700, Rick Macklem wrote:
> > I don't think this an important issue since section 5 describes it as a "minor eccentricity" and section 6.1 calls it a "minor exception".
> 
> You are correct, in that I do disagree. Although it describes an
> uncommon case, I think
> someone will encounter it, sooner or later.  I'd rather have something
> the "just works all
> the time" than a "minor exception" that fails. I also do not see how
> NFSv4 ACLs can
> accurately mimic the POSIX draft default ACL? (For POSIX draft ACLs, a
> directory can
> have two ACLs, one for access and the other for inheritance. How do
> you reliably map
> both of these to one NFSv4 ACL?)

I don't think it can map that concept.

> Actually, I do not recall any RFC that specifies how long an attribute for a
> file object is supported. Forever is probably an answer, although I would not
> be surprised if it can change after a server reboot.
> A persistent file handle is guaranteed to be T-stable.
> Does the same rule apply to the supported_attrs attribute?

Btw, that is generally a good question independent of the ACLs supported
question.  A server software upgrade can easily provide new functionality,
and in corner cases might remove some.

> I can see a Linux knfsd server presenting attributes for both ACL models
> on-the-wire for a POSIX draft ACL stored on a file object, to maintain
> backwards compatibility.

Presenting both at the same time would be a very bad idea.  The way
we handle that in other protocols is by doing the equivalent of a
mount-time opt-in to the new incompatible features (in this case the
Posix draft ACLs).  I'm not entirely sure how to best model that in
NFS yet.