[nfsv4] [Editorial Errata Reported] RFC8275 (5198)

RFC Errata System <rfc-editor@rfc-editor.org> Tue, 05 December 2017 20:37 UTC

Return-Path: <wwwrun@rfc-editor.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 4440C126DFF for <nfsv4@ietfa.amsl.com>; Tue, 5 Dec 2017 12:37:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 I7EdlB10GLKa for <nfsv4@ietfa.amsl.com>; Tue, 5 Dec 2017 12:37:36 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914A012025C for <nfsv4@ietf.org>; Tue, 5 Dec 2017 12:37:36 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id DA98CB8125A; Tue, 5 Dec 2017 12:37:18 -0800 (PST)
To: bfields@redhat.com, agruenba@redhat.com, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, beepee@gmail.com, spencer.shepler@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: neil@brown.name, nfsv4@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20171205203718.DA98CB8125A@rfc-editor.org>
Date: Tue, 05 Dec 2017 12:37:18 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/j5UwKYjFPqDbq6_nf5JMAhSy6d4>
Subject: [nfsv4] [Editorial Errata Reported] RFC8275 (5198)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 05 Dec 2017 20:37:38 -0000

The following errata report has been submitted for RFC8275,
"Allowing Inheritable NFSv4 Access Control Entries to Override the Umask".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5198

--------------------------------------
Type: Editorial
Reported by: Neil Brown <neil@brown.name>

Section: 1

Original Text
-------------
The same solution should work for NFS.  However, the NFSv4 protocol
   does not currently give the client a way to transmit the umask of the
   process opening a file.  And clients have no way of atomically
   checking for inheritable permissions and applying the umask only when
   necessary.  As a result, the server receives an OPEN with a mode
   attribute that already has the umask applied.

Corrected Text
--------------
Implementing a comparable solution for NFS is not currently possible.
It cannot be implemented in the server as the server does not know
the umask, and the protocol does not allow the client to tell it.
It cannot be implemented in the client as the client cannot atomically
check the inheritable permissions on the containing directory and
apply the umask selectively. As a result, the server receives an
OPEN with a mode attribute that already has the umask applied.

Notes
-----
The intent of the paragraph is obscured by clumsy language.  It is explaining how neither the server
nor the client can currently make the required decision, but this is not immediately obvious.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8275 (draft-ietf-nfsv4-umask-05)
--------------------------------------
Title               : Allowing Inheritable NFSv4 Access Control Entries to Override the Umask
Publication Date    : December 2017
Author(s)           : J. Fields, A. Gruenbacher
Category            : PROPOSED STANDARD
Source              : Network File System Version 4
Area                : Transport
Stream              : IETF
Verifying Party     : IESG