Re: [nfsv4] Fwd: New Version Notification for draft-dnoveck-nfsv4-security-04.txt

David Noveck <davenoveck@gmail.com> Sun, 16 January 2022 09:03 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 AC86F3A0E78; Sun, 16 Jan 2022 01:03:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 yOl8kufOf14H; Sun, 16 Jan 2022 01:03:26 -0800 (PST)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 0AB413A0E76; Sun, 16 Jan 2022 01:03:26 -0800 (PST)
Received: by mail-ed1-x532.google.com with SMTP id u21so52092326edd.5; Sun, 16 Jan 2022 01:03:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J6VF7g5zu3s94SewnbJdkOXK1VbcBmx8O1pl1CI8zZ4=; b=OClrqKRf+YkFBZ57MSEdZilmlaREqPMiURwrSCVU40n7UtcVFd0238x+c7FdK+lGW8 HpHk47Fuq65m1/WcBsjj1ernthIlf/oylw13H8KfK7dOCMMO/YBhEi48L2eSvy1PoXXi W6I/MZxpklotk/B1j3Hj/o/bI8LCpS8NXMVqIMB6i1mE+1zWSTINW01CQB8oaXouK9SP muIhX2/Sr8IgZfFfwHUhuwfYvjOzTGYqm2Xzso5c2rz9DU98mbhCMbmimYuRrrvG2ey5 BNIUvldg0uMF7AoDfUjIR0zZe/cDsMb6TsyXdjg5OP7MyA+VY9eZC45OTPH1jhzZCX/p 90aA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J6VF7g5zu3s94SewnbJdkOXK1VbcBmx8O1pl1CI8zZ4=; b=ImbTWZgVQOzJal2xDG6z6Xr/fzA/rb03kJ1x3InUIwJrF51cfPyf1O3J8s23mSZ/Qt 8E50BpFrqd8haTkqUFWwYwS0FTirWnsm9nCATT5lQrVvebLkx/tV/QalFwtiNWs+2FM5 W1gPJVNs2czTYfrP760KtcTqcm7650nwtuLakdDmHg4Bj3gcBe0jhSl6axyD/HWu2mk3 OmeeFvR6yvxTtHm9RVISjoQJjxQ6baFCBifXijAY7J43dKrHLMR4G+0PE+blNYniItYN wl5pyRlIlX6ZZ2vvH1I92ZjbOhdH0XZOvP4eNN1tmAGQvwGZMRlIV/vPlu8ZOWRTxvoq AFdw==
X-Gm-Message-State: AOAM532qfs8iPgUfQ1V+wbqGPkjps0JDMRxJ13ugUfSjzmICgEcl+8aP cqbTt3tdJhJfgC1kigVv5wD3wGQuX3pIh3V/IyNhJluu
X-Google-Smtp-Source: ABdhPJzfYjdJ3H74VyEZSWYlDkvQu4h0MCPA9LjlwIds4fyTY8lWZnQzoIhBBqSv+7GR9x8DyBjyN9Ici35BH/+qubg=
X-Received: by 2002:a17:906:7945:: with SMTP id l5mr13032822ejo.82.1642323803736; Sun, 16 Jan 2022 01:03:23 -0800 (PST)
MIME-Version: 1.0
References: <164035267965.25968.10921853654415505678@ietfa.amsl.com> <CADaq8jcXitpCCA+y3u6dYxGM95rfX6UtuZTm27g=Ht6=8x3+Qw@mail.gmail.com> <YQXPR0101MB0968955CCDDFC660EE9180D1DD449@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <CADaq8jeitOwexgH2tq5azmCj9937SBw6e18+qrAYAFC==LhsRA@mail.gmail.com> <YQXPR0101MB09686A72FA4279392797EA36DD4F9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <20220114214509.GA22366@fieldses.org> <YQXPR0101MB0968EA5EAF51A989B1AB034CDD549@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
In-Reply-To: <YQXPR0101MB0968EA5EAF51A989B1AB034CDD549@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
From: David Noveck <davenoveck@gmail.com>
Date: Sun, 16 Jan 2022 04:03:12 -0500
Message-ID: <CADaq8jcF=6+WB-Ai4mDJ-Xjj2qzQL6qguQtvF-fK8z18qkOKyQ@mail.gmail.com>
To: Rick Macklem <rmacklem@uoguelph.ca>
Cc: "J. Bruce Fields" <bfields@fieldses.org>, NFSv4 <nfsv4@ietf.org>, nfsv4-ads@ietf.org, nfsv4-chairs <nfsv4-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ed8f3305d5af4e18"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/BYc5f6jDysYmeVDZTlm2TiE0JAk>
Subject: Re: [nfsv4] Fwd: New Version Notification for draft-dnoveck-nfsv4-security-04.txt
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 16 Jan 2022 09:03:31 -0000

I'd like to thank Rick and Bruce for their helpful comments.

It seems to me that, given the absence, of an append-write in the NFSv4
protocol, APPEND_WRITE belongs in the same bucket as SYNCHRONIZE and I am
planning to draft -05 on that basis.

Looking forward to -06, I'd like to get away from the text which makes each
mask bit its own optional feature,. Clearly READ_DATA, WRITE _DATA, and
EXECUTE should be mandatory but what about the others?  Should any of these
be mandatory?  If not, why isn't it implemented? Are there
applications/clients that rely on it?

On Fri, Jan 14, 2022, 6:48 PM Rick Macklem <rmacklem@uoguelph.ca> wrote:

> J. Bruce Fields wrote:
> > On Sun, Jan 09, 2022 at 11:15:34PM +0000, Rick Macklem wrote:
> > > From: David Noveck wrote:
> > > > If I understand correctly, you are intending to accept an acl that
> APPEND_DATA and not
> > > > WRITE_DATA  and then not let the user open the file for write.   I
> don't know about your
> > > > users but I would certainly feel that was a "weird, irritating
> inconsistency".
> > > Yes, but it is consistent with local behaviour on FreeBSD.
> > > A file with APPEND_DATA, but not WRITE_DATA cannot be open'd with a
> POSIX
> > >   open("foo", O_APPEND | O_WRONLY, 0)
> > > either locally nor over NFS.
> > > (O_APPEND is a modifier and cannot be specified by itself.)
> >
> > How would an NFS client write to it, anyway?  Do you just tell people
> > they need to use O_SYNC for such files?
> When a file is POSIX open(...O_APPEND..)'d in FreeBSD on an NFS mount
> point, each write is pushed through to the server (with an exclusive lock
> held on the vnode) FILESYNC.
> The result maintains ordering, but is very slow compared to doing the
> same on local file systems. For a test case doing 10,000 writes, it
> takes 13sec over NFS vs 0.3sec locally for UFS (even slower for ZFS,
> takes 2minutes for ZFS with sync enabled and no ZIL log).
>
> > Otherwise writes are likely to get reordered, and then the writer gets
> > random EACCES (and random unfillable holes, if you allow writes at
> > offsets past EOF).  Seems like a bit of a foot-gun.
> Yep, it forces O_SYNC basically.
>
> > Oh well, out of scope here, I suppose.
> Not really. If another client writes to the file, it could still get
> "random"
> EACCES failures.
> As I mentioned, the FreeBSD server stores APPEND_DATA, but ignores it.
> I recall Robert Watson (who designed the FreeBSD NFSv4 ACL stuff)
> stating as the reason "because it's such a pita".
> For FreeBSD, this is also true of ZFS. (The ACL enforcing part of ZFS
> is in the port specific code, so I don't know what Linux/Solaris does
> w.r.t. APPEND_DATA for ZFS.)
>
> rick
>
> --b.
>
>