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

bfields@fieldses.org Fri, 14 January 2022 21:45 UTC

Return-Path: <bfields@fieldses.org>
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 44E243A1017; Fri, 14 Jan 2022 13:45:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fieldses.org
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 r2QN3CGoHzy1; Fri, 14 Jan 2022 13:45:11 -0800 (PST)
Received: from fieldses.org (fieldses.org [IPv6:2600:3c00:e000:2f7::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCF153A1014; Fri, 14 Jan 2022 13:45:10 -0800 (PST)
Received: by fieldses.org (Postfix, from userid 2815) id 394A172FB; Fri, 14 Jan 2022 16:45:09 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 fieldses.org 394A172FB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fieldses.org; s=default; t=1642196709; bh=/ywI4BcU7Z7FYF8Ub23b9YWBm/OoHeZy21RWqTBo6hM=; h=Date:To:Cc:Subject:References:In-Reply-To:From:From; b=YqxGRRrwhoVfUGmbiEXT0NF6vxrIh2jQFaQoLlSJjN9eeJ9eDaI9ENOy1DzGUdvC6 jcisw/AUVKehPEIgCw7fKskTEsZRtI4QIxuRSm9DioA4O1yjO/oIx823OcLR/jGtyo iPIDV8yIb/WgVVKBpKRh4RFPAT0MUHE24Jjs67Gs=
Date: Fri, 14 Jan 2022 16:45:09 -0500
To: Rick Macklem <rmacklem@uoguelph.ca>
Cc: David Noveck <davenoveck@gmail.com>, NFSv4 <nfsv4@ietf.org>, "nfsv4-ads@ietf.org" <nfsv4-ads@ietf.org>, nfsv4-chairs <nfsv4-chairs@ietf.org>
Message-ID: <20220114214509.GA22366@fieldses.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <YQXPR0101MB09686A72FA4279392797EA36DD4F9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
User-Agent: Mutt/1.5.21 (2010-09-15)
From: bfields@fieldses.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/gVMgKr6WcdgZtFHf2mPr1ngkVps>
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: Fri, 14 Jan 2022 21:45:16 -0000

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?

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.

Oh well, out of scope here, I suppose.

--b.