Re: [nfsv4] RFC 7530: Filehandle of opened file after the REMOVE

David Noveck <davenoveck@gmail.com> Sat, 10 December 2016 12:20 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 BE8571296C4 for <nfsv4@ietfa.amsl.com>; Sat, 10 Dec 2016 04:20:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCdxRnvjrTlE for <nfsv4@ietfa.amsl.com>; Sat, 10 Dec 2016 04:20:20 -0800 (PST)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068901296BC for <nfsv4@ietf.org>; Sat, 10 Dec 2016 04:20:20 -0800 (PST)
Received: by mail-oi0-x22e.google.com with SMTP id v84so45147253oie.3 for <nfsv4@ietf.org>; Sat, 10 Dec 2016 04:20:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fBGL6H7RuxAo5yxpnVujm2KngCLxLFu49DTlAO6Bb0U=; b=vSUH+2S6kAu1xRj/Ay/uIgNPVajZr+HgpK4aIEGkB5hUz1UpzaxYVUbbuZq95Lg2Va GJWPGSQKiwpZ31+q97pH9pV9IjmJgAoyb9C1fAuRHLkpSOM5F9zIB5Nmmktsi8u+lg/p RcaJ0NtvubL9wc4vevL9cuO5c1NrMWEHpi3QoPCOYQP81J79XB/nNH0ZNNG4NDOTX+A3 EoXKT23gyZr24LWHSPLc0TXMhrkqRV6ANryIJKeg+ahGK2fiLw6nhstO3yGLJ6owWy0w yXtUG6xGey8IUUpXj8uuhlp7cmp/vPLTvjAslHfYSjIDTxmnfIcGpFXAHiXX98miFown s14w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fBGL6H7RuxAo5yxpnVujm2KngCLxLFu49DTlAO6Bb0U=; b=k+q5wLwxNrxqy7fMM8x6SX39xfq/O0sfcKBesVjfn6m8m7WVLaXJXlVbC2+CTGSagS oD5OwthSRSn4OqBv1VA4otSxGiGfkKgAVFOGlp7QVEJyvwdSwuBjygkC2yBoKmNOzWVJ BsRox0/gJg7eU4UgHHIgNG6qV6fKwlr3LflJRZV6285wjeDOTwTDJVBR25D4EfwHHJRX tR0omX59cQHDIoovK4uud3ZSvQNC5khIA+MUOiWIeQX+eqeRKhYoBSB7onmSFtH3+PVA /jfMsJ6Lk1N4kdPwixi5cdxlheAT3zVTH7l/yG0lxTw9KbPxIpGO/L92bd/IrR6rMEzx NmrQ==
X-Gm-Message-State: AKaTC004wzqHsn/ymQ/lsiRYpa44KnSeTzV60r/KBoKahVxOLBn3iDx0+9g2T/XxA7pTJUfyxA27HUaZwnWzSA==
X-Received: by 10.157.58.119 with SMTP id j110mr44422341otc.208.1481372419252; Sat, 10 Dec 2016 04:20:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.137.202 with HTTP; Sat, 10 Dec 2016 04:20:18 -0800 (PST)
In-Reply-To: <20161209222500.GB1514@telcontar>
References: <20161209222500.GB1514@telcontar>
From: David Noveck <davenoveck@gmail.com>
Date: Sat, 10 Dec 2016 07:20:18 -0500
Message-ID: <CADaq8jck1P2vcDZjaFSnQRFYUnAyjJCqDgxqdWPDhEjPP7hDmA@mail.gmail.com>
To: Marcel Telka <marcel@telka.sk>
Content-Type: multipart/alternative; boundary=001a11493caed46bb905434ce42e
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/7NemlTXkCozQuHdYzQ0FAFTJEiE>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: [nfsv4] RFC 7530: Filehandle of opened file after the REMOVE
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2016 12:20:23 -0000

>The above clearly says that for clientB the filehandle for the file
> after the REMOVE operation MAY be valid.

As I read it, it MAY be either valid or invalid and this applies to
validity as perceived by any client.

> The clientB just removed the file, so it should not be surprised
> the filename (obtained in step 2) is no longer valid.

He shouldn't, but if he was a stickler for unix semantics, he would have a
problem.

> What is unclear to me is clientA.  Is it okay for the server to
> 'forget' the filehandle even for clientA?

It is allowed by the spec.

> If the filehandle won't be valid for clientA (after the REMOVE
> by clientB), then clientA might lost the access to the file anytime, >
and it have no easy chance to prevent that (and no way to recover > from
that).

> This sounds unfortunate and it breaks the traditional unix
> semantics: the file is there while I hold it opened.

True but people have been OK with this for two reasons:

   1. Most clients will implement NFSv3 sillyrename which is alluded to in
   the paragraph above the bulltets you quote.  Interestingly, it is a
   "should" rather than a "SHOULD", since interoperability is not affected.
   2. In the case of other clients, NFS users may have have been bringing
   expectations formed on the basis of experiences with NFSv3, and from an
   NFSv3 perspective, this server behavior is unexceptionable.


A possible extension to NFSv4.2 could provide an attribute to allow the
client to determine how the server dealt with this issue.

> The only way to make sure the file is available until the final
> CLOSE seems to be to open the file with
> OPEN4_SHARE_DENY_WRITE or
> OPEN4_SHARE_DENY_BOTH,

I'm don't think you can be sure of this, since

   1. In speaking of the directory entry it only says "SHOULD NOT"
   2. The text doesn't say explicitly that processing should stop at this
   point, with an error returned.
   3. there seems to be no text at all regarding continued access to the
   file by existing opens in the DENY case.  This may need some sort of
   correction but I'm not sure at this point exactly what sort of correction
   we could put in, given the need to be compatible with all existing
   implementations.


> which sounds like overkill.

Not exactly:

   1. It prevents stuff you don't want to prevent
   2. It is not guaranteed to prevent what you really want to prevent.


> Am I overlooking something?

I think you are overlooking sillyrename.

In your example either or both of A and B might by implementing
silllyrename and it isn't clear how things would work if both A and B did.
:-(

I think it would help if we considered this issue in historical context.
Making NFSv4 stateful was a wrenching change and it is not surprising if we
have adapted to that change incompletely.  Some of the IESG commentary
about RFC3530 expressed reserve or uncertainty (although no actual
objection) about making this change, saying essentially "Well if you guys
*really* want to do this, OK".

On Fri, Dec 9, 2016 at 5:25 PM, Marcel Telka <marcel@telka.sk> wrote:

> Hi,
>
> I'm not sure I understand RFC 7530 properly.  Here is the scenario I'm not
> sure
> about:
>
> 1. clientA opens a file named with OPEN4_SHARE_DENY_NONE.
> 2. clientB opens the (same) file with OPEN4_SHARE_DENY_NONE.
> 3. clientB removes the file using the REMOVE operation.
>
> In section 16.26.5. there is this:
>
>    o  If the file was not opened with OPEN4_SHARE_DENY_WRITE or
>       OPEN4_SHARE_DENY_BOTH, the server SHOULD delete the file's
>       directory entry.  However, until the last CLOSE of the file, the
>       server MAY continue to allow access to the file via its
>       filehandle.
>
> The above clearly says that for clientB the filehandle for the file after
> the
> REMOVE operation MAY be valid.  The clientB just removed the file, so it
> should
> not be surprised the filename (obtained in step 2) is no longer valid.
>
> What is unclear to me is clientA.  Is it okay for the server to 'forget'
> the
> filehandle even for clientA?  If the filehandle won't be valid for clientA
> (after the REMOVE by clientB), then clientA might lost the access to the
> file
> anytime, and it have no easy chance to prevent that (and no way to recover
> from
> that).  This sounds unfortunate and it breaks the traditional unix
> semantics:
> the file is there while I hold it opened.  The only way to make sure the
> file
> is available until the final CLOSE seems to be to open the file with
> OPEN4_SHARE_DENY_WRITE or OPEN4_SHARE_DENY_BOTH, which sounds like
> overkill.
>
> Am I overlooking something?
>
>
> Thank you.
>
> --
> +-------------------------------------------+
> | Marcel Telka   e-mail:   marcel@telka.sk  |
> |                homepage: http://telka.sk/ |
> |                jabber:   marcel@jabber.sk |
> +-------------------------------------------+
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>