Re: [nfsv4] Fwd: New Version Notification for draft-dnoveck-nfsv4-security-04.txt
David Noveck <davenoveck@gmail.com> Sat, 25 December 2021 13:24 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 062493A07E9 for <nfsv4@ietfa.amsl.com>; Sat, 25 Dec 2021 05:24:07 -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 Y4je3UXM8K1f for <nfsv4@ietfa.amsl.com>; Sat, 25 Dec 2021 05:24:02 -0800 (PST)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 DAD2D3A07E6 for <nfsv4@ietf.org>; Sat, 25 Dec 2021 05:24:01 -0800 (PST)
Received: by mail-ed1-x530.google.com with SMTP id j6so42869341edw.12 for <nfsv4@ietf.org>; Sat, 25 Dec 2021 05:24:01 -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=RcKkXnHcORchXuisKJG6YIEfpn+l8M4va++dakqAqZw=; b=h97PAfk6TIx3DgIkXQt7/TxpgYlT0Qqk+uqtSoul2dl8sxOJSvIgz1HlIRnq0X8wdW gdnLnJIkZs++D+WuAqPhjI4Vz6kF8y+htloeQmFipkK2dNzGCWD9ftVuVkXoWYoFRSvc sw8y35uad1CkB9PurWXXfDnjDQREZCAyZ/SM4Y2plC926d7qrJ9dvikAk6sG71iS6Km4 y6sxHCoUp3nripYoKvcseN9jTxRb4gDu8qRmxWd7qNzpPa/91VlHBdkWYKHHEU7n5CXe sBVgNry+f0v+aqrt1uOHCQ8qpGD8dUffuaBoez0enILdcXxRnXXOg3L1KP5ZdNO+w2E1 rVxw==
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=RcKkXnHcORchXuisKJG6YIEfpn+l8M4va++dakqAqZw=; b=47e/4M0fJsDihKU7myrnrPiS2vcGbVhJszmIhmL1X65Ki5z/AFWrEyyf1FwLf4iZ5N JSILxsKvTtSXUS8AaI8wCLADxI+4s0+q0KwPWFIfWD0mx4oJIZdgvA9Jusq6gO6PEXS0 GheogB+EKeqasmRPcrNTWUGMa+Y7K16hsmr+WHEBpBedUdJZcAuKMGcJnulN+9LSIpve WXMES0BTJ9Kj9kCpTe86X5eKmil/qk88ifNcf84HIFWJmvuj1c7MLNirc7bOJ3V+M55+ xzCU7oBh9wjMYt2lnPK1B6YelYxEciQDlTU5C9aLm6rKqVykFQEKvQE3QbXHByMKKJbn +iEg==
X-Gm-Message-State: AOAM531KTxV1PbVRHolDbP463/pWNl1Np9DtHf25C9L9UYuioRHIIFSH aBq7YJ+e6xudyOAiJnYlfMRhE7ujG0w6FJELQOtP4jiC
X-Google-Smtp-Source: ABdhPJwrI3dMEOPtsFjAbMvJXZrUP4DN7FS5WVXWuTCdZWv/sGgZZOpmcbWzQI4wr5xBU9DC1oHaFv+uCZdrlOGhB5A=
X-Received: by 2002:a17:907:6091:: with SMTP id ht17mr8660282ejc.407.1640438638982; Sat, 25 Dec 2021 05:23:58 -0800 (PST)
MIME-Version: 1.0
References: <164035267965.25968.10921853654415505678@ietfa.amsl.com> <CADaq8jcXitpCCA+y3u6dYxGM95rfX6UtuZTm27g=Ht6=8x3+Qw@mail.gmail.com> <YQXPR0101MB096858749741A1191DE75279DD7F9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
In-Reply-To: <YQXPR0101MB096858749741A1191DE75279DD7F9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
From: David Noveck <davenoveck@gmail.com>
Date: Sat, 25 Dec 2021 08:23:47 -0500
Message-ID: <CADaq8jdgPWmvDQBZ-f2R3e0OjmXPKn3AFmiMLaBSoFVXBSztnQ@mail.gmail.com>
To: Rick Macklem <rmacklem@uoguelph.ca>
Cc: NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005a3a2e05d3f862dd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/uMVNytVocfayY8kYFbBYtylroFU>
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, 25 Dec 2021 13:24:07 -0000
On Fri, Dec 24, 2021, 6:32 PM Rick Macklem <rmacklem@uoguelph.ca> wrote: > I think I will address each issue I see in this document separately, to try > and keep the discussion focused. > Good idea. With a focused discussion, we could get this issue and possy others you raise resolved in -05. In Sec. 8.1 (page 64), it says: > > * RFC8881 [8] contains the following, which is now superseded: > > Many servers implement owner-override semantics in which the > owner of the object is allowed to override accesses that are > denied by the ACL. This may be helpful, for example, to allow > users continued access to open files on which the permissions > have changed. > > Regardless of the truth of the first sentence above, either when > it was written or today, it needs to be stressed that the fact > that a server manifests a particular behavior does not imply that > it is valid according to the protocol specification. In this > case, the supposed "owner-override semantics" clearly are not > valid, since they contradict the specification of both the mode- > based and ACL-based approaches to file access authorization. > > Well, I cannot see how the FreeBSD client (or other NFSv4 clients on > POSIX-like systems) can function without the "owner-override". > I am prepared to make this a MAY if others agree and there is a clear statement of what specifically this overide semantics consists of. I note, however, that your statement which implies that such clients cannot function with servers that do not implement this override makes me skeptical. In POSIX, permission checking is done only when the POSIX open(2) > syscall is performed. If successful, I/O is expected to work, despite any > changes done to owner/owner_group/mode/ACL after the POSIX open(2) > while I/O is done on the open_fd. > I was unaware of that. I was recently looking at ontap's handling of this (for a reason not connected with this document) and noted that the code does read permission checks for reads using NFSv4 open files but not for SMB/CIFS open files. I presume that is because Microsoft specifies that behavior. --> Although NFS cannot be a POSIX compliant file system, allowing the > owner of the file to do the Read/Write avoids frequent unexpected > I/O failures due for owner/owner_group/mode/ACL changes. > I don't have any problem with the spec saying that the server MAY allow IO to proceed without permission checks if access was valid at the time of open or MAY do so if the owner of the file is doing the IO. --> I believe that "owner-override" has been common practice since NFSv2 > and should remain specified, It cannot "*remain* specified" (emphasis added) since it has never been specified or defined. That has to change. even if it does appear to be in violation > of other parts of the RFCs. > We cannot have RFCs that contradict themselves. A new read-only per-file system attribute could be defined that tells a > client if "owner-override" is implemented, although not doing it will > probably cause a lot of grief for extant NFSv4 clients on POSIX like > systems. > That could be part of a miscellaneous attributes I-D you were missing about. In any case, I intend to mention the possibility in the future section of -05 once I have a clear definition of "owner override". > > Does the Linux client expect "owner-override"? > If no one familiar with the Linux client answers this, I'll run a test on > a Linux > mount. > I may wind up doing some testing in this area with Linux clients and will report on what I see. FWIW, I don't expect server choices in this area to discomfit the client per se but don't expect that fact to be dispositive. I think any grief will be felt by users and applications and the spec should try not to create problems for them. > rick > > ________________________________________ > From: nfsv4 <nfsv4-bounces@ietf.org> on behalf of David Noveck < > davenoveck@gmail.com> > Sent: Friday, December 24, 2021 8:49 AM > To: NFSv4; nfsv4-chairs; nfsv4-ads@ietf.org > Subject: [nfsv4] Fwd: New Version Notification for > draft-dnoveck-nfsv4-security-04.txt > > CAUTION: This email originated from outside of the University of Guelph. > Do not click links or open attachments unless you recognize the sender and > know the content is safe. If in doubt, forward suspicious emails to > IThelp@uoguelph.ca > > > I've just posted security-04. Thanks to Rick Macklem and Chuck Lever who > made important suggestions that I hope are correctly addressed in this > version. An rfcdiff with -03 is not small but it is helpful to see what > has changed. > > As previously discussed, I am proposing that the working group adopt this > draft as a working group document. I expect Brian and Zahed to set the > timeline for that discussion. > > Please let me know about your suggestions for -05. > > ---------- Forwarded message --------- > From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> > Date: Fri, Dec 24, 2021 at 8:31 AM > Subject: New Version Notification for draft-dnoveck-nfsv4-security-04.txt > To: David Noveck <davenoveck@gmail.com<mailto:davenoveck@gmail.com>> > > > > A new version of I-D, draft-dnoveck-nfsv4-security-04.txt > has been successfully submitted by David Noveck and posted to the > IETF repository. > > Name: draft-dnoveck-nfsv4-security > Revision: 04 > Title: Security for the NFSv4 Protocols > Document date: 2021-12-24 > Group: Individual Submission > Pages: 129 > URL: > https://www.ietf.org/archive/id/draft-dnoveck-nfsv4-security-04.txt > Status: > https://datatracker.ietf.org/doc/draft-dnoveck-nfsv4-security/ > Html: > https://www.ietf.org/archive/id/draft-dnoveck-nfsv4-security-04.html > Htmlized: > https://datatracker.ietf.org/doc/html/draft-dnoveck-nfsv4-security > Diff: > https://www.ietf.org/rfcdiff?url2=draft-dnoveck-nfsv4-security-04 > > Abstract: > This document describes the core security features of the NFSv4 > family of protocols, applying to all minor versions. The discussion > includes the use of security features provided by RPC on a per- > connection basis. > > This preliminary version of the document, is intended, in large part, > to result in working group discussion regarding existing NFSv4 > security issues and to provide a framework for addressing these > issues and obtaining working group consensus regarding necessary > changes. > > When a successor document is eventually published as an RFC, it will > supersede the description of security appearing in existing minor > version specification documents such as RFC 7530 and RFC 8881. > > > > > The IETF Secretariat > > >
- [nfsv4] Fwd: New Version Notification for draft-d… David Noveck
- Re: [nfsv4] Fwd: New Version Notification for dra… Rick Macklem
- Re: [nfsv4] Fwd: New Version Notification for dra… Rick Macklem
- Re: [nfsv4] Fwd: New Version Notification for dra… David Noveck
- Re: [nfsv4] Fwd: New Version Notification for dra… David Noveck
- Re: [nfsv4] Fwd: New Version Notification for dra… Rick Macklem
- Re: [nfsv4] Fwd: New Version Notification for dra… Rick Macklem
- Re: [nfsv4] Fwd: New Version Notification for dra… David Noveck
- Re: [nfsv4] Fwd: New Version Notification for dra… Rick Macklem
- Re: [nfsv4] Fwd: New Version Notification for dra… Rick Macklem
- Re: [nfsv4] Fwd: New Version Notification for dra… David Noveck
- Re: [nfsv4] New Version Notification for draft-dn… Brian Pawlowski
- Re: [nfsv4] New Version Notification for draft-dn… Chuck Lever III
- Re: [nfsv4] Fwd: New Version Notification for dra… bfields
- Re: [nfsv4] Fwd: New Version Notification for dra… Rick Macklem
- Re: [nfsv4] Fwd: New Version Notification for dra… Rick Macklem
- Re: [nfsv4] Fwd: New Version Notification for dra… David Noveck
- Re: [nfsv4] Fwd: New Version Notification for dra… Rick Macklem
- Re: [nfsv4] Fwd: New Version Notification for dra… bfields
- Re: [nfsv4] Fwd: New Version Notification for dra… Rick Macklem
- Re: [nfsv4] Fwd: New Version Notification for dra… Rick Macklem
- Re: [nfsv4] Fwd: New Version Notification for dra… David Noveck
- Re: [nfsv4] Fwd: New Version Notification for dra… Rick Macklem
- Re: [nfsv4] Fwd: New Version Notification for dra… bfields
- Re: [nfsv4] Fwd: New Version Notification for dra… bfields
- Re: [nfsv4] Fwd: New Version Notification for dra… Rick Macklem
- Re: [nfsv4] Fwd: New Version Notification for dra… David Noveck
- Re: [nfsv4] Fwd: New Version Notification for dra… J. Bruce Fields
- Re: [nfsv4] Fwd: New Version Notification for dra… Chuck Lever III
- Re: [nfsv4] Fwd: New Version Notification for dra… David Noveck
- Re: [nfsv4] Fwd: New Version Notification for dra… David Noveck
- Re: [nfsv4] Fwd: New Version Notification for dra… Trond Myklebust