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

bfields@fieldses.org Sat, 08 January 2022 22:23 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 A7F683A1094; Sat, 8 Jan 2022 14:23:20 -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 45B1OpO9utwd; Sat, 8 Jan 2022 14:23:15 -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 CE80F3A1092; Sat, 8 Jan 2022 14:23:15 -0800 (PST)
Received: by fieldses.org (Postfix, from userid 2815) id 8F22744D2; Sat, 8 Jan 2022 17:23:11 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 fieldses.org 8F22744D2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fieldses.org; s=default; t=1641680591; bh=U4QA+6v4DMA+s+ALhn2jt3kK+5mglPv8X4eekAafT3c=; h=Date:To:Cc:Subject:References:In-Reply-To:From:From; b=rbuqP6pqKODF4DRYQR548xjPuCaqyqkdf4TMYqnWzITWXaaW5TK5za2P+B1D7dwZP xN0ckq3Jaa9uoSKjyEvpvcWIdCdlMQPe4BQg+W5rOUoGmod3hpeSXNiCajDh6WdGrD y2oQBOXzKuNJYCyn2/tptU3qJwawnJxZXJ5j7xEA=
Date: Sat, 08 Jan 2022 17:23:11 -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: <20220108222311.GA17868@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> <YQXPR0101MB09688A093AD2FDDFA0AF70B2DD4E9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <YQXPR0101MB09688A093AD2FDDFA0AF70B2DD4E9@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/jJbUIaTqN9v-66nYw2MkOhNVe58>
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: Sat, 08 Jan 2022 22:23:21 -0000

On Sat, Jan 08, 2022 at 04:41:03PM +0000, Rick Macklem wrote:
> David Noveck wrote:
> [> Rick Macklem wrote:
> [stuff snipped]
> > > Why?
> > > Well, my understanding is that APPEND_DATA does not apply to
> > > any old Write that happens to start at EOF, but specifically "append-only"
> >
> > The spec says the contrary.  since there are no NFSv4 append-only operations it
> > would not make sense to revise it in line with your understanding.
> Ok, yes. I found a Microsoft document that states APPEND_DATA allows writes
> that start at EOF.
> 
> But what about:
> - Setattr of size, where this size is beyond EOF.
>   (Not covered by APPEND_DATA, so presumably allowed/denied via
>    WRITE_DATA.)
> - A Write with an offset > size (ie past EOF).
>   (Also allowed/denied via WRITE_DATA.)
> 
> So, does WRITE_DATA being set without APPEND_DATA being set make
> sense. Not really, but it is allowed by the RFCs, as far as I can see?
> It just makes no sense to allow a Write that starts beyond EOF, but not
> one that starts at EOF.
> 
> So, I understand your position, but I believe (it is not up to me), that
> FreeBSD's NFSv4 server will simply choose to continue to ignore APPEND_DATA.
> 
> On the PSARC/2010/029 document:
> - The author of the FreeBSD NFSv4 ACL code no longer has a copy, either.
>    However, he recalls the main item in it was an alternate algorithm for
>    converting mode->ACL. The "canonical six" upset Windows, because it
>    mixes allow/deny ACEs and apparently Windows likes all the Allow ACEs
>    to preceed all the Deny ACEs.

It's the other way around.  Googling....:

	https://docs.microsoft.com/en-us/windows/win32/secauthz/order-of-aces-in-a-dacl

>    - This alternate algorithm creates a set of Allow ACEs followed by a set of
>       Deny ACEs that are semnatically equivalent to the "canonical six".

So, we put Deny ACEs before Allow whenever possible.  Or, better yet,
just leave them out.

In theory Windows allows both but I'm told various tools complain if
your ACLs are weird.

--b.