[nfsv4] Re: Personal draft related to directory delegations

Rick Macklem <rick.macklem@gmail.com> Thu, 16 May 2024 21:19 UTC

Return-Path: <rick.macklem@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 4C2C6C18DA20 for <nfsv4@ietfa.amsl.com>; Thu, 16 May 2024 14:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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_DNSWL_NONE=-0.0001, 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 Y9V0q_ewh0EJ for <nfsv4@ietfa.amsl.com>; Thu, 16 May 2024 14:19:43 -0700 (PDT)
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 6B791C18DA07 for <nfsv4@ietf.org>; Thu, 16 May 2024 14:19:43 -0700 (PDT)
Received: by mail-pg1-x533.google.com with SMTP id 41be03b00d2f7-65b4d0a7391so671992a12.2 for <nfsv4@ietf.org>; Thu, 16 May 2024 14:19:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715894382; x=1716499182; 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=LL9Tnwqe1ZnqDsGSj0EwO1m/R3laAj5gp/5Ls5F8wyw=; b=LqbMX7lDQMBMtWRBMQOqaLSUHa9GupS7DT/qVcFqcGfEoqVilzJOP6SZYCzc6sOm4y 4D0VdtKs1jVLUx1UG2uCEJqkB/RL76WHQOwiGbkSPIQ/A3OalqHzXgiMj+o1dv+DkIf/ aazwiOiVFCPEM+CCYRa2t8HNv399hVF3OTWCIX2ESLC6V9TbwDPEZm/QhE2jArl/ua9o H0yit4BDBsCpEKAt2dD+CZ6gOOyELTBRawz5IR0Aj6zQzZWuVtNhoaeD1q7+TDw/0r5N tsxOfYuDcnMmj7FFVJcufIm00IUiOrJJ7mRw/LrqKn0vL5vZALatgA7ZvUcShjVzj6Pu Yttw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715894382; x=1716499182; 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=LL9Tnwqe1ZnqDsGSj0EwO1m/R3laAj5gp/5Ls5F8wyw=; b=o3kurmsAk2CXvp6SZMoQCHeofEzdjDkHfM2q4gtLV3RolmAQuvXDgr0kuwxCg92gkP 5Npd4X5pVs7Kb5EzwI/ZYkvORzsKy0+kyaN0i6lmDiv70u/yfW0K8m39eBhKhUafe0gP 4pQHTLhrhlMAp+/D1Hwq4GHuzLKYd1z7vvjbnQF9zdIXC4yyRQnKpeUqqK0yf7fMxz2R RGrDdqrsag7gGZGtn54Kvo6EwKCCNGS8wj9CPRi6cy83vKgmROzOjQx0ci5TP1cPhiyB r5ZxaCNOHpK2CPETgABDZ8quv5bgYa+x4HG03sXN78pIeJq2rduE5h8txxSxOnokAULZ XHoA==
X-Gm-Message-State: AOJu0YzFQiRaC/wWCz3My/c0C6Yso4CbZXPnAWycpc2fbRSka4sQrY23 2iTYE5z+tif6lhqiBbGH/akfHjbMr00COhvmCnDnPXK8s7VrSFyB2k4Hto5JSP3EHFsr5AqLjCH 74P8FeMAr8wcmc9qZp9AbXIiFAg==
X-Google-Smtp-Source: AGHT+IFXSeM3pX1ZOy3mu9eiKaGMAOzNTiJanV07XmfdZBCR6MeoTS5SSVbzP1sLhlJoqaVAJ26SuelQy4hRZfwQMLs=
X-Received: by 2002:a17:90a:e389:b0:2af:2be3:89c5 with SMTP id 98e67ed59e1d1-2b6cc76d2bamr18631301a91.29.1715894382178; Thu, 16 May 2024 14:19:42 -0700 (PDT)
MIME-Version: 1.0
References: <CAM5tNy6qVZicDksJ=rDK3di+yaPi2BQ2o6=6dp_iYNPXG7bAcQ@mail.gmail.com> <CADaq8jdwtEftS8QWzgNf2a6Vp_QtYWPfpbr4pJ0UAHyhOF+Zvg@mail.gmail.com> <CAM5tNy6mpFNu_SuVPLtAkA94kswxHks0mAGhA80Jg44PvLPXBQ@mail.gmail.com> <CAM5tNy6MTktCjV8uucJvEd3QS0AevT3-q2m11=Y6J6ex29Ko7Q@mail.gmail.com> <CAM5tNy7TwS5Ka8zO=w84zdnEyZvSSJt=Hf28uNHiWeR9h-dSXg@mail.gmail.com> <CADaq8jdftcAOHx_U_3t7=nQNWB0Nd3+udigLpWYyYnLvigGBnQ@mail.gmail.com>
In-Reply-To: <CADaq8jdftcAOHx_U_3t7=nQNWB0Nd3+udigLpWYyYnLvigGBnQ@mail.gmail.com>
From: Rick Macklem <rick.macklem@gmail.com>
Date: Thu, 16 May 2024 14:19:30 -0700
Message-ID: <CAM5tNy4_k-44AhX1X=SDUBP6g-+JtUYNRuof_=2wFZmN83nbKQ@mail.gmail.com>
To: David Noveck <davenoveck@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Personal draft related to directory delegations
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/UCxcbw0w89OpNKdao1CSoyWrb2k>
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 Tue, May 14, 2024 at 7:09 AM David Noveck <davenoveck@gmail.com> wrote:
> Thanks for your comments.  There are some notes below regarding my current plans for the bis and the issues you raise.
> LOOKUP and READDIR Authorization
> Current Plans for Bis
> Regarding your desire to support (A) and (B),  I think that what I'm planning for the  is will give you both of those plus some opportunities to reduce ACCESS calls:
> When creating a delegation you get three  bits (one for each of owner, group others) that indicate it is OK to use the cached directory  content for LOOKUPs and READDIRs without doing ACCESS calls.
I think implementing @Everyone is easier than "other". The problem
with owner/group/other is that it depends on the
credential mapping in the server. These mapping can change at any time
and may be difficult for the NFS server to
notice. For example, the mapping from a Kerberos principal to a <uid,
gid-list> is done, at least in FreeBSD, by the
userland gssd daemon. Another example would be "TLS identity
squashing" (Chuck's term for it. He's much better
at naming stuff than I am.), where the kernel RPC ignores the
credential in the RPC header and uses one based
on the client's X.509 cert. provided during TLS handshake. This one is
hidden in the kernel RPC layer.

What I am trying to say is that it may be difficult for the server to
recognize a change in these mappings has
occurred and, as such, the permission bits for (owner, group, other)
no longer apply for a given client user.

Anyhow, the nice thing about Everyone is that it is independent of
credentials and can be checked/monitored
via the mode and acl attributes. (For mode, all of MODE4_XUSR,
MODE4_XGRP and MODE4_XOTH set or
an ACE Allow/@Everyone/ACE4_LIST_DIRECTORY preceding any Deny ACE for

At least for the FreeBSD server, implementing a permission bit for
Everyone would be easier than (owner/group/other).

> When there is a request to use that data by a user and the corresponding bit is not set, an ACCESS call is done.  The result is cacheable so that repealed calls for the same user do not need to be done.
> There is a new notification to report authorization changes. It is asynchronous but not subject to batching and delay.  It contains three sets of three bits.  Two of those are for the allowability of various groups of users to safely do LOOKUP and READDIR.  The third is to flush the cache of ACCESS results for the various classes of use.
I'll admit you've lost me w.r.t. what these 3 groups of bits
represent, but I can wait until you've published the words...

> Quagmire Avoidance
> The interface is designed to allow the client to not concern itself with looking at the acls and keeps the burden of interpretation on the server.  One item that might be troublesome is that it depends on the ability of the client to determine whether a given user is a member of the owning group which. However, a client can simply ignore the group bit and treat all users, not the owner using the bit other users.  That requires more ACCESS calls but is safe.
> The server will generally need to look at ACLs on the directory but could punt and always turn off all of three bits if an acl is not present.  The ACL analysis necessary is not onerous, however.  If there are no DENY ACLs, reporting the results of looking only at OWNER@, GROUP@, and EVERYONE@ ACEs will work fine and turning all bits off if they exist is probably good enough.
> Input Needed
> I'm OK with immediate comments if anything in the above is troubling.  However, it is probably best if you wait until the next pre-draft of -05 which probably will be out this week.  When -05 is actually out (current target 5/30), I'm hoping you could review the relevant changes FYI, I will present plans for -05 at the 5/21 interim meeting.
Basically, I'd like to see a bit for Everyone. I do not care if it is
in addition to other or replaces other.

It would be nice to avoid Access operations, rick

> Child Attribute Notifications
> Multiply-linked Files
> You make an important point regarding the implementability of this feature.  With 20-20 hindsight, I now see this was a mistake.  I'm not sure if it counts as "defect" according to Section 9 of RFC8178 but I will be thinking about that issue.
> How would you feel about a modified version that only provides updates for singly-linked files? A related alternative would require recall in the event that there were any multiple-linked files in the directory.  I'm looking for seven-eighths of a loaf here but would settle for half or a third.  Anyway, I'm a pretty bad negotiator😉
> GETATTR Authorization
> I think we need to (and can) avoid dealing with the ase in which GETATTR is not (or might not be) authorized   I think it has to be the case that the client does not have to worry about this and the server essentially certifies that GETATTRs are authorized and the delegation will be recalled if that ceases to be the case.  The only case I know of is from the heart of the quagmire (specifically ACE4_READ_ATTRIBUTES).. So far, we have not found any servers that allow this privilege to be denied.  Onap support this bit and will accept DENY AC Es that contain it but, whenever this privilege bit is needed to do an operation it is automatically granted no matter what the ACL says.  I still need to research AUDIT and ALARM ACEs that specify this bit.
> I haven't drafted the text for -05 yet but it is clear that it needs to take the approach above.  For most servers this will no be an issue since there are very few servers supporting  ACE4_READ_ATTRIBUTES.  I will try to provide an opportunity for servers who do supot tis to implement delegation.  I hope this o be doable in this bis, but intend to address this in an extension if not.  I will give a shot in -05.
> On Monday, May 13, 2024, Rick Macklem <rick.macklem@gmail.com> wrote:
>> On Mon, May 13, 2024 at 1:12 PM Rick Macklem <rick.macklem@gmail.com> wrote:
>> >
>> > On Mon, May 13, 2024 at 12:57 PM Rick Macklem <rick.macklem@gmail.com> wrote:
>> > >
>> > > On Mon, May 13, 2024 at 10:40 AM David Noveck <davenoveck@gmail.com> wrote:
>> > > >
>> > > > I'll take a look.  You should be aware that I am considering adding new notifications to rfc5661bis based on Section 9 of RFC8178 which discusses the possible use of protocol extensions to correct protocol defects.  So far, they do not include the position information extensions we have been discussing but might wind up there depending on  my decision about what is appropriate to consider a "defect"
>> > > >
>> > > > I am looking at authorization issues for cached use of directory contents.  The current spec doesn't say much about those but it is clear that the is will have to address these issues.  What I'd like to know is what you were expecting to do about these issues based on rfc8881.  Even if I add new notifications or flag bits for better handling, I have to specify some default for those following RFC8881.  Even though you might believe none exist and I have no reason to disagree, one generally has to provide some default for hypothetical implementations of features when one is changing them.  The only exception is the persistent rply cache in which the existing specification essentially precludes implementation.
>> > > When you look, you'll see that it defines CB_NOTIFY_WANT_VALID flag
>> > > bit that indicates the extension is supported.
>> > > Without that in the GET_DIR_DELEGATION request/reply, RFC8881
>> > > semantics are assumed.
>> > > (It was not clear what error reply would be sent by a server when a
>> > > RFC8881 compliant implementation sees
>> > > an unknown bit set in gdda_notification_types, but after taking out
>> > > the error returns that mean other things,
>> > > and indicated that
>> > > any of those replies would indicate a RFC8881 compliant server.
>> > >
>> > > >
>> > > > It would help me to understand what approach to the authorization issue you would expect given the material that is in rfc8881.  If a hypothetical server did exist with directory delegation support, how do you suppose it might deal with authorization issues?
>> > > Hmm, I'll admit I haven't thought much about this.
>> > > For what the experimental code I have written does..it will issue a
>> > > directory delegation
>> > > if the same credential permits a READDIR for the same directory.
>> > >
>> > > As for what the server/client do when directory attributes change...
>> > > RFC8881 Sec. 10.2 specifically mentions GET_DIR_DELEGATION, so I'd
>> > > assume the rules there apply to directory delegations? (It includes SETATTR in
>> > > the list, although other entries in the list obviously do not apply to directory
>> > > delegations, such as WRITE.)
>> > >
>> > > The two para. in Sec. 18.30.4 for SETATTR related to directory delegations
>> > > do look like they could use further thought. They indicate that a CB_NOTIFY
>> > > can be generated, but do not discuss when a CB_RECALL needs to be done.
>> > > --> It appears to leave the decision up to the client. I guess it comes down to
>> > >      whether the client is expected to do a ACCESS to check that the directory
>> > >      is still readable or whether the server does a CB_RECALL and the text
>> > >      in Sec. 18.30.4 does not seem to be clear on this?
>> > > --> For the case where NOTIFY4_CHANGE_DIR_ATTRS was not granted,
>> > >      I'd say that the server must CB_RECALL, but that does not seem to
>> > > be stated.
>> Upon thinking about this a little more, it might be a candidate for
>> yet another flag bit.
>> (A) - I can see some clients wanting either a NOTIFY4_CHANGE_DIR_ATTRS or a
>>   CB_RECALL whenever the directory attributes change. This would allow the
>>   client to invalidate its Access cache and force a ACCESS operation
>> be performed
>>   against the server when a directory is about to be read.
>> OR
>> (B) - I could see some clients just doing a ACCESS whenever they need
>> to decide if
>>   a directory can be read and, therefore, saying "I don't care if
>> directory attributes change".
>> So, I can see that it might be reasonable to define another flag bit
>> (not in the current
>> draft) that allows the client to select between (A) or (B) above.
>> rick
>> > Btw, for the case of NOTIFY4_CHANGE_CHILD_ATTRS, I do not have much
>> > of an opinion. I do not see any way this CB_NOTIFY would be implemented in
>> > FreeBSD, due to the fact that there is no practical way to tie a
>> > change in attributes
>> > to the list of directories that have links to the file.
>> >
>> > Also, FreeBSD leaves permission checking for GETATTR up to the underlying
>> > file system (ie. you are into the quagmire called ACLs), so I have no idea how
>> > a FreeBSD server would decide if a client holding a directory delegation can
>> > be told about child attribute changes. (Another good reason to not
>> > implement it;-)
>> >
>> > rick
>> >
>> > >
>> > > rick
>> > >
>> > >
>> > >
>> > > >
>> > > > On Sun, May 12, 2024 at 8:35 PM Rick Macklem <rick.macklem@gmail.com> wrote:
>> > > >>
>> > > >> Hi,
>> > > >>
>> > > >> I just put a personal draft in the ietf datatracker called
>> > > >> https://www.ietf.org/archive/id/draft-rmacklem-nfsv4-directory-delegations-00.txt
>> > > >>
>> > > >> It defines new flag bits that a client can use for GET_DIR_DELEGATION to
>> > > >> request specific behavior for the CB_NOTIFYs.
>> > > >>
>> > > >> Please take a look and comment.
>> > > >>
>> > > >> Thanks, rick
>> > > >> ps: Jeff, if you give me a little info about your implementation status,
>> > > >>       I will add it to the draft.