Return-Path: 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 1277CC14F5F7 for ; Sun, 8 Sep 2024 16:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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_NONE=-0.0001, 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 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 Nk1bVsEblzQo for ; Sun, 8 Sep 2024 16:24:39 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FEC9C14F5F3 for ; Sun, 8 Sep 2024 16:24:39 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id 6a1803df08f44-6c3603292abso21989676d6.1 for ; Sun, 08 Sep 2024 16:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725837878; x=1726442678; 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=gTHYosPLEOTN8vHW/6CmUZkAT2tQLBYnfN0YXxVEjWM=; b=OQr0TPLlopBaN0H1sMX5AOOMvDx3RcEMlYBdcuXPNTssSlxL7VAmV5lUGibEQ0D+2x bFT1MtPaR1ifULZswvT9HFiEQr1lqEgtz26xPDeVRugQQNZosM7V+0A+BJ18jTGe6Kgg IX8vKEz9BJrVlMwDA9900YKAWpakRQQrFhlrqXfs/mM2DRd+llIwoOfozPLOY+DPT1U6 pI1JUClcIvAgZSauK/mq1W4axkWLT4XtyUZBPCeupPLuzvQMNISKxihQ5TbNaggSfpfq xIjKUt4tKGnTc94+hQmUjY1QiZM7/OOUwri/+YwjNl9yV+joTbJId27vQr+UC6UqdfMs 7LYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725837878; x=1726442678; 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=gTHYosPLEOTN8vHW/6CmUZkAT2tQLBYnfN0YXxVEjWM=; b=M0XdmC/AiWqwM8hHWmW3Q6b5cXe/1M1mXML8N6n/cGp0lEmhYpdI/0Ym0VS/7Xljrh GQy0ngHm3aWfXG1yjZIdDvipDhF7Z2fXOX0tv67tc7L/nT5b4cPBNLNXMcH9+ittSddU nF7+RQpHwCk6Svl4vmLb1ahQove/a/NVx/xroAJeIbzUQLSVQ0OWKbQQWxN5i0yU5Ekw jmvRO1rzhOawBy6TRZPc2pXa3DnI3QMp3ViTXwjv0vlr/cjgh3qVMupX/q++6EVNX7J5 Ysei3VH3a/GAg0mFl1KXVw7RZSsohVJtDptS7PXcbdpZUz8G3eqpEwZvVNiHzvXQx8wE W+Hg== X-Forwarded-Encrypted: i=1; AJvYcCWq1CgkSgvVV7jwfe1v7Xfz8WszZNH6M1AzbiO8yo6/N0s2FEkk9TC+TIKhOSS66EUsw1ztPQ==@ietf.org X-Gm-Message-State: AOJu0Yy3Llp7Z+3L/2sMG+Or3S4YUG6ej15OdlN6ly4KyUitd2Bm8gQA URHneeaDdBJ64ioeHCzkUCYvBQ67KtolomdWoe1G56vREAkph8+OiIF6BTDQ+gMRHWdRe1AlKvO amQUhd3DF/AdvQ0mLqk/F2Gd5fHxH5A== X-Google-Smtp-Source: AGHT+IGCwu0b7qgpp8hv9vTtJScjMVNnqcgQGLK03XRRiLRoQUWSUsG7GxbJ4X4Fz7Q3HqLKveOuJTeUUSpZ2ahoLTg= X-Received: by 2002:a05:6214:3205:b0:6c3:5b9e:699d with SMTP id 6a1803df08f44-6c5282fa26bmr123544226d6.2.1725837878534; Sun, 08 Sep 2024 16:24:38 -0700 (PDT) MIME-Version: 1.0 References: <20240908163411.e2vobyl7yhaz6sdt@pali> In-Reply-To: From: David Noveck Date: Sun, 8 Sep 2024 19:24:27 -0400 Message-ID: To: Rick Macklem Content-Type: multipart/alternative; boundary="000000000000b0aabc0621a3f17e" Message-ID-Hash: MJQXEN5T2IBUUXX7SAFITGWFCENNBMPF X-Message-ID-Hash: MJQXEN5T2IBUUXX7SAFITGWFCENNBMPF 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: =?UTF-8?Q?Pali_Roh=C3=A1r?= , NFSv4 X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bnfsv4=5D_Re=3A_Interim_meeting_agenda_topics?= List-Id: NFSv4 Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000b0aabc0621a3f17e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Sep 8, 2024, 6:12=E2=80=AFPM Rick Macklem = wrote: > On Sun, Sep 8, 2024 at 9:34=E2=80=AFAM Pali Roh=C3=A1r > wrote: > > > > On Sunday 08 September 2024 12:05:54 David Noveck wrote: > > > On Fri, Sep 6, 2024, 4:35=E2=80=AFPM Rick Macklem > wrote: > > > > What is left to be resolved / is controversial on the POSIX_ACL > draft? > > > > > > Nothing from my point of view. I don't know of any issues Rick has. > It > > > is reasonable to expect that anyone who does have issues to raise the= m > on > > > the list. We may need to confirm the non-existence of such issues a= t > the > > > forthcoming interim meeting. I think we should allocate five minutes > for > > > this. > > > > Hello, I have already pointed one issue on the list - problem with mode > > attribute (two meaning modes: NFS4 and POSIX) and its backward/forward > > compatibility on existing NFS4 servers for clients without POSIX ACL > > extension. > I'll admit I just do not understand what you are thinking. > My response is the same. I guess we need to discuss this at the next interim meeting. For the proposal, at any one moment in time, a file object on the server > will have, at most, one "true form" ACL. (Where "true form" is the ACL > that is stored for the file object and used to determine access to the > file.) > The treatment in the latest acl draft is consistent with that model. It provides for extensions such as yours, which define additional ACL models with the assumption being that there will be at most one ACL model in effect for any fike system object at any time. The job of defining new ACL models is left to extensions as such as yours. > > As such, I cannot understand why you would think there are two modes? > (Where "mode" refers to the low order 9 bits of the mode attribute.) > > The interaction between setting of the low order 9 bits of mode and the > setting of an ACL is determined by which "true form" the ACL has. > Yes. According to the latest ACL draft, the job of defininin those interactions in job of the acl document only when the ACL model in effect for that object I'd the NFSv4 ACL model. When it is any other ACL model, it is the job of the standards-track extension defining that new ACL model. > > For the weird case where a SETATTR is allowed to set an ACL of the > other "true form" for a file object, the mode bits will be updated the > same way as they would be if that ACL was set for the file object at > any other time (ie. no previous ACL or a previous ACL of the same "true > form" > Agree. Although you describe this case as wierd, I cannot disagree but have to point out that this is much less weird than a number of presidential candidates :-) > > W.r.t. clients that do not support the extension... > These clients might set the mode bits and the effect would be no > different than what occurs now. > --> For a server that uses a "true form" of POSIX draft ACL, that > ACL might change, just as would happen now. It's just that the clien= t > cannot actually "see" the ACL. > > W.r.t. servers that do not support the extension... > The attributes will not be in the supported_attrs list and any > attempt to GET/SET them should fail. > > rick > --000000000000b0aabc0621a3f17e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Sep 8, 2024, 6:12=E2=80=AFPM Rick Macklem <= rick.macklem@gmail.com> wr= ote:
On Sun, Sep 8, 2024 at 9:34=E2= =80=AFAM Pali Roh=C3=A1r <pali-ietf-nfsv4@ietf.pali.im>= wrote:
>
> On Sunday 08 September 2024 12:05:54 David Noveck wrote:
> > On Fri, Sep 6, 2024, 4:35=E2=80=AFPM Rick Macklem <rick.ma= cklem@gmail.com> wrote:
> > > What is left to be resolved / is controversial on the POSIX_= ACL draft?
> >
> > Nothing from my point of view.=C2=A0 I don't know of any issu= es Rick has.=C2=A0 =C2=A0It
> > is reasonable to expect that anyone who does have issues to raise= them on
> > the list.=C2=A0 =C2=A0We may need to confirm the non-existence of= such issues at the
> > forthcoming interim meeting.=C2=A0 I think we should allocate fiv= e minutes for
> > this.
>
> Hello, I have already pointed one issue on the list - problem with mod= e
> attribute (two meaning modes: NFS4 and POSIX) and its backward/forward=
> compatibility on existing NFS4 servers for clients without POSIX ACL > extension.
I'll admit I just do not understand what you are thinking.

My response i= s the same.=C2=A0 I guess we need to discuss this at the next interim meeti= ng.

For the proposal, at any one moment in time, a file object on the server will have, at most, one "true form" ACL. (Where "true form&q= uot; is the ACL
that is stored for the file object and used to determine access to the file= .)

The treatment in the latest acl draft is consistent with that model.=C2= =A0 It provides for extensions such as yours, which define additional ACL m= odels with the assumption being that there will be at most one ACL model in= effect for any fike system object at any time.=C2=A0 The job of defining n= ew ACL models is left to extensions as such as yours.

As such, I cannot understand why you would think there are two modes?
(Where "mode" refers to the low order 9 bits of the mode attribut= e.)

The interaction between setting of the low order 9 bits of mode and the
setting of an ACL is determined by which "true form" the ACL has.=

= Yes.=C2=A0 According to the latest ACL draft, the job of defininin those in= teractions in job of the acl document only when the ACL model in effect for= that object I'd the NFSv4 ACL model.=C2=A0 When it is any other ACL mo= del, it is the job of the standards-track extension defining that new ACL m= odel.=C2=A0=C2=A0

For the weird case where a SETATTR is allowed to set an ACL of the
other "true form" for a file object, the mode bits will be update= d the
same way as they would be if that ACL was set for the file object at
any other time (ie. no previous ACL or a previous ACL of the same "tru= e form"

Agree. Although you describe this case as wierd, I cannot disag= ree but have to point out that this is much less weird than a number of pre= sidential candidates :-)
=

W.r.t. clients that do not support the extension...
These clients might set the mode bits and the effect would be no
different than what occurs now.
--> For a server that uses a "true form" of POSIX draft ACL, t= hat
=C2=A0 =C2=A0 =C2=A0ACL might change, just as would happen now. It's ju= st that the client
=C2=A0 =C2=A0 =C2=A0cannot actually "see" the ACL.

W.r.t. servers that do not support the extension...
The attributes will not be in the supported_attrs list and any
attempt to GET/SET them should fail.

rick
--000000000000b0aabc0621a3f17e--