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

David Noveck <davenoveck@gmail.com> Fri, 07 June 2024 20:31 UTC

Return-Path: <davenoveck@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 04C57C151527 for <nfsv4@ietfa.amsl.com>; Fri, 7 Jun 2024 13:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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] 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 PFLToJ-vM3VA for <nfsv4@ietfa.amsl.com>; Fri, 7 Jun 2024 13:31:37 -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 41ED9C14F6EA for <nfsv4@ietf.org>; Fri, 7 Jun 2024 13:31:37 -0700 (PDT)
Received: by mail-qv1-xf35.google.com with SMTP id 6a1803df08f44-6afbf9c9bc0so14305826d6.3 for <nfsv4@ietf.org>; Fri, 07 Jun 2024 13:31:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717792296; x=1718397096; 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=AphfzZycH2OM0L7oAckA3fjulBJUfJvR8yqNpVx/dv8=; b=R2L3GclpVmW6sUbRqwO7nboYQWbYsOxJjLDuqhYUlYF/ymUdjLppfaqtSN7867E6o2 kw3UL+7F7sDFBiPsVqjAafwcCoivSUTgVkjqIplJBDKhLESYqIdcSVwbttwsd/3l/KD5 PncZc69dqlZjRww/F8Wm1Zo+5xycle2iHiHpgAq/z6WeyK0VZ1VC5FEp3Y+h3W0FnGLn rCH9oKt7Sn/+8+smdMSjgtlLfq8pLPL6hDq6cfPEOs2HEYvAG7q+6ZUOeDC7LtagPqCe iZ+mczH6NE4VyKiIN689lLNQi6cb0bBgIddZ2IsFMkI5wcfeXcaN9goSNM/ZyNZrJfk8 hGgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717792296; x=1718397096; 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=AphfzZycH2OM0L7oAckA3fjulBJUfJvR8yqNpVx/dv8=; b=VEBFX1sPvAT8lU4aRZ8314H8d/kHSIq/LuEM3yERHH7d+ozz0IT0FTEy2raS2D3dNY 9engs69NftH1bUr/VEj7rTTaNpFn5cZAZocIy1gpzDoPkCDIYBAth3FsF+5UXg1c8GSd C1m1W6vW0tPEA/SOer6LlRK1Wa7j/rnQ6iA+9Ydmw+xIaPJko/k6GcGwUsdrhq061oyV QkoBvQ1vb60se7oTjHU3qu+8biJ/W0eG8yDPSR4lDG5m53jAGKOoKJN7cLZXc5S05Obv k5JQaSrN0ZkBxRNcEVrKh0/GLuobadoiLuWr0xPyWcZrHRgD8GOqk7dpShA8aqN6nkch JSJQ==
X-Forwarded-Encrypted: i=1; AJvYcCV4UDB0lBc+3COMKe/Zi5cCbzRJYihZpSGmWz7+uxanzFX8G7+UcG1b79+DZHwd3a6EslIjh/vHQcfnvlp61w==
X-Gm-Message-State: AOJu0YxmDCrdsV3M4VGF/Szoo4bKF+8UkUym9vux+/BxH+SO/DEKBh9X Ee3ETTuhnPR0t6sDenSTC13ksgJh5+AJsICoF5xGPXUHzOmHO9SbvYgsAxxXu3EAyofVup1SqlH m7PDtPBSIkO20pGOGQGMoNTHOlkkdUgp6U+s=
X-Google-Smtp-Source: AGHT+IGfhIOLnDGYIri7d1jw9l5k3gsUkG0dvtGac2a8SF4kStdt+HJnpxLjLa8xo5oBdNf5MU6Qpphw3nPJ7uu5c8A=
X-Received: by 2002:a05:6214:5c09:b0:6a9:75ff:8ed4 with SMTP id 6a1803df08f44-6b059f7b42emr31480496d6.42.1717792295960; Fri, 07 Jun 2024 13:31:35 -0700 (PDT)
MIME-Version: 1.0
References: <CADaq8jfNeu9ZAibEBLp=+EtczS69k1rQK1X57mvmbMLGdY8ztg@mail.gmail.com> <CAM5tNy6RndufxNq3+2CYvQYzt2PAoiLyyQiZErMcoSQDwVmm6A@mail.gmail.com> <CADaq8jdqsJQ5pMQsj0obENvmMqF6oKkiQffHVVcFygMucPMmxg@mail.gmail.com> <CAM5tNy5K64ULERss8tyx0EL10iSrNQiPbpeVWNidhixuLVrzWA@mail.gmail.com> <CADaq8jdURkr2MDQBBbB74DVEBO9f=B8mdA9vgyc4vX0YAFZ6aw@mail.gmail.com> <CAM5tNy41WeF3_FYp=oMx0wti7T9nfcRLvNc46CHUb57HivYwgw@mail.gmail.com> <CAM5tNy5L4sBTU3cZquo8rDQosPMwVN71QbEQ9g4EM+52Gah-HA@mail.gmail.com> <0f0f820e4b56670e6b120402ade6daad6e279d5a.camel@poochiereds.net> <CAM5tNy5LXOHHDZB42cxL9+n7As_UvpiOsmAkCr2V1KOLkiEEKQ@mail.gmail.com> <d76024c77a9fa70d2704e6f3a4ec98bd7fe7a973.camel@poochiereds.net> <20240607154822.GA10667@lst.de>
In-Reply-To: <20240607154822.GA10667@lst.de>
From: David Noveck <davenoveck@gmail.com>
Date: Fri, 07 Jun 2024 16:31:24 -0400
Message-ID: <CADaq8jeRkMUBEVWg8GZ4KFggs0WHjKhnuHj0Q8NRVYmKGTXXWg@mail.gmail.com>
To: Christoph Hellwig <hch@lst.de>
Content-Type: multipart/alternative; boundary="000000000000994977061a52af14"
Message-ID-Hash: QB6NAZ64ZMSIAKWLDUBBFJ2CJ65MNUHX
X-Message-ID-Hash: QB6NAZ64ZMSIAKWLDUBBFJ2CJ65MNUHX
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/bVfLc_W4doEPWQ1d8rCf5VehGCQ>
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 Fri, Jun 7, 2024, 11:48 AM Christoph Hellwig <hch@lst.de> wrote:

> On Thu, Jun 06, 2024 at 06:57:27PM -0400, Jeff Layton wrote:
> > 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.
>
> Agreed.  There is no need to introduce new operations when file
> attributs work perfectly fine.  And I suspect that new file attributes
> (one for the access ACL and one for the default ACL) would be a lot
> cleaner than overloading the existing ones.
>
> > 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.
> >
> > I understand David not wanting to take on more scope creep though.
>

Beyond that,  I don't  really understand POSIX ACLs well enough to do this.

> Maybe we should consider it as a separate document / project?
>

It certainly can't be a requirement to complete rfc5661bis.


> It would supersede a large part of this document, to the extent where
> there rest should just be part of the bis document.
>

Not sure exactly what you mean by thus.


> _______________________________________________
> nfsv4 mailing list -- nfsv4@ietf.org
> To unsubscribe send an email to nfsv4-leave@ietf.org
>