[nfsv4] Re: Personal draft related to directory delegations

Rick Macklem <rick.macklem@gmail.com> Mon, 13 May 2024 20:40 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 291DBC1D4A83 for <nfsv4@ietfa.amsl.com>; Mon, 13 May 2024 13:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Status: No, score=-7.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_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 Zrix7tS5U5VY for <nfsv4@ietfa.amsl.com>; Mon, 13 May 2024 13:40:40 -0700 (PDT)
Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 80C44C09036D for <nfsv4@ietf.org>; Mon, 13 May 2024 13:40:40 -0700 (PDT)
Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-2b4aa87e01aso3400033a91.3 for <nfsv4@ietf.org>; Mon, 13 May 2024 13:40:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715632840; x=1716237640; 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=gwprPqlgfkvOOSMg5GyBqLgxq6bTWTlx82brrrGn5vA=; b=dNRYgkcux0DGwpKfJJhHLVGfkSly/CWz6T1k5Ts7ydpCkNNP4q09Kdis+o7sHYGVDV 1gNHV5WpIyahIJk5P4r8wNQYmwZimt0/dHP32W+5FZfed8dP4YOL0dDySvG1LBGY6AeI nRGt7+j+UtKIChMo/EgLaFDdCCbMv5mYC81MgjIsSi884/jdpZmeNv4OxN8J3KLsNWYQ qArUbgXy+FTXfaL2fm44q/Z0hFaa0B+1HqAFUpRT4F/MIff9B+lIiuCEfdsmJDPGw8Nl xswmIpYUCe+st0Zf86LuHUjrsiDeSudbAEoTy+CrpL+nu/o5DT9PJ486RitUY558xA9E 6a7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715632840; x=1716237640; 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=gwprPqlgfkvOOSMg5GyBqLgxq6bTWTlx82brrrGn5vA=; b=iW0SWhJIaIGj2q07gfL//JTO8LPY5S0boA5JJNJmKyte+L0pqEcIRzUUOiBHKfoXZK gINi9wbM4VeZHd3s7Fhdd9SkTNsQjhzwLY5T/APtqBVfum/s4fyQLknXpO6m4A1o92P+ 8ZgD3T2s/WuE+9iHBbtCHH1liTw6TvbQnxVAOGRtrjt3YuZ2mfzJsfKU1bj1fPg0dKmp kQ5/3ULNSKJ5/MHlPtsBpi0G5jI92mNxJnmJr5zC0FHJVG3JrRISsWW5ufXBVFj4nwSX stmZrJsR/2uN5SUIlC5eAVlG8V9CT12twO2ZEfcB+14g0RwJn5fYVb/07snl4JVxWKmr 0h4Q==
X-Gm-Message-State: AOJu0Yxu0FXEcmR+fBGQEs0TrjoXySzY5ZQdJpou+MiEHlI+G4S3+Ztk EnYPJg+/WgBJ2Rqj4UWM1rv6Dv2ViQLyeSCrw1rcRNSgQh3aNqZGERAc0wNxyxY9Clxwy1LLFQS m0NDWFZT/v6xWQvlnZdBLTd+40w==
X-Google-Smtp-Source: AGHT+IHoygw8rtaiCvqDSXYtP6/Nj+gvemBOGrcOiO0I7RAvsUseGfLbX/BnhE5ofXJngRSp54xdJ4qR69I8IxrMi8I=
X-Received: by 2002:a17:90a:e607:b0:2b1:f61a:4a2f with SMTP id 98e67ed59e1d1-2b6ccd80143mr8548931a91.35.1715632839775; Mon, 13 May 2024 13:40:39 -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>
In-Reply-To: <CAM5tNy6MTktCjV8uucJvEd3QS0AevT3-q2m11=Y6J6ex29Ko7Q@mail.gmail.com>
From: Rick Macklem <rick.macklem@gmail.com>
Date: Mon, 13 May 2024 13:40:28 -0700
Message-ID: <CAM5tNy7TwS5Ka8zO=w84zdnEyZvSSJt=Hf28uNHiWeR9h-dSXg@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/4at-V2Xknlkzfxfpe7VRTi8nNmc>
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 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.
(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.


> 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.