Internet Engineering Task Force (IETF) J. Fields
Request for Comments: 8275 A. Gruenbacher
Category: Standards Track Red Hat
ISSN: 2070-1721 December 2017
Internet Engineering Task Force (IETF) J. Fields
Request for Comments: 8275 A. Gruenbacher
Category: Standards Track Red Hat
ISSN: 2070-1721 December 2017
Allowing Inheritable NFSv4 Access Control Entries to Override the Umask
允许可继承的NFSv4访问控制项覆盖Umask
Abstract
摘要
In many environments, inheritable NFSv4 Access Control Entries (ACEs) can be rendered ineffective by the application of the per-process file mode creation mask (umask). This can be addressed by transmitting the umask and create mode as separate pieces of data, allowing the server to make more intelligent decisions about the permissions to set on new files. This document proposes a protocol extension to accomplish that.
在许多环境中，通过应用每进程文件模式创建掩码（umask），可继承的NFSv4访问控制项（ACE）可能会变得无效。这可以通过将umask和create模式作为单独的数据块进行传输来解决，从而使服务器能够更智能地决定对新文件设置的权限。本文提出了一个协议扩展来实现这一点。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8275.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8275.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Protocol Extension Considerations . . . . . . . . . . . . . . 3
4. XDR Extraction . . . . . . . . . . . . . . . . . . . . . . . 3
5. The mode_umask Attribute . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Protocol Extension Considerations . . . . . . . . . . . . . . 3
4. XDR Extraction . . . . . . . . . . . . . . . . . . . . . . . 3
5. The mode_umask Attribute . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
On Unix-like systems, each process is associated with a file mode creation mask (umask). The umask specifies which permissions must be turned off when creating new file system objects.
在类Unix系统上，每个进程都与文件模式创建掩码（umask）关联。umask指定在创建新文件系统对象时必须关闭哪些权限。
When applying the mode, Section 6.4.1.1 of [RFC7530] recommends that servers SHOULD restrict permissions granted to any user or group named in the Access Control List (ACL) to be no more than the permissions granted by the MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP bits. Servers aiming to provide clients with Unix-like chmod behavior may also be motivated by the same requirements in [SUSv4]. (See the discussion of additional and alternate access control mechanisms in "File Permissions", Section 4.4 of [SUSv4].)
应用该模式时，[RFC7530]第6.4.1.1节建议服务器应将授予访问控制列表（ACL）中指定的任何用户或组的权限限制为不超过MODE4_RGRP、MODE4_WGRP和MODE4_XGRP位授予的权限。旨在向客户机提供类似Unix的chmod行为的服务器也可能受到[SUSv4]中相同要求的推动。（参见[SUSv4]第4.4节“文件权限”中关于附加和备用访问控制机制的讨论。）
On many existing installations, all ordinary users use the same effective group ID by default. To prevent granting all users full access to each other's files, such installations usually default to a umask with very restrictive permissions. As a result, inherited ACL entries (inheritable ACEs) describing the permissions to be granted to named users and groups are often ignored. This makes inheritable ACEs useless in some common cases.
在许多现有安装上，默认情况下，所有普通用户都使用相同的有效组ID。为了防止授予所有用户对彼此文件的完全访问权限，此类安装通常默认为具有非常严格权限的umask。因此，通常会忽略描述要授予命名用户和组的权限的继承ACL条目（可继承ACE）。这使得可继承的ACE在某些常见情况下毫无用处。
Linux solves this problem on local file systems by ignoring the umask whenever a newly created file inherits ACEs from its parent; see [LinuxACL].
Linux通过在新创建的文件从其父文件继承ACE时忽略umask，在本地文件系统上解决了这个问题；参见[LinuxACL]。
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.
同样的解决方案也适用于NFS。但是，NFSv4协议目前没有为客户端提供传输打开文件的进程的umask的方法。客户端无法自动检查可继承权限，也无法仅在必要时应用umask。结果，服务器接收到一个带有模式属性的OPEN，该属性已经应用了umask。
This document solves the problem by defining a new attribute that allows the client to transmit umask and the mode specified at file creation separately, allowing the client to ignore the umask in the presence of inheritable ACEs. At least in the Linux case, this allows NFSv4 to provide the same semantics available using local access.
本文档通过定义一个新属性来解决此问题，该属性允许客户端分别传输umask和文件创建时指定的模式，允许客户端在存在可继承ACE的情况下忽略umask。至少在Linux中，这允许NFSv4使用本地访问提供相同的语义。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document presents an extension to minor version 2 of the NFSv4 protocol as described in [RFC8178]. It describes a new OPTIONAL feature. NFSv4.2 servers and clients implemented without knowledge of this extension will continue to interoperate with clients and servers that are aware of the extension (whether or not they support it).
本文档提供了[RFC8178]中所述的NFSv4协议次要版本2的扩展。它描述了一个新的可选特性。NFSv4.2在不知道该扩展的情况下实现的服务器和客户端将继续与知道该扩展的客户端和服务器进行互操作（无论它们是否支持该扩展）。
Note that [RFC7862] does not define NFSv4.2 as non-extensible, so [RFC8178] treats it as an extensible minor version. This Standards Track RFC extends NFSv4.2 but does not update [RFC7862] or [RFC7863].
请注意，[RFC7862]没有将NFSv4.2定义为不可扩展，因此[RFC8178]将其视为可扩展的次要版本。本标准跟踪RFC扩展NFSv4.2，但不更新[RFC7862]或[RFC7863]。
The additional lines of External Data Representation (XDR) [RFC4506] description embedded in this document can be extracted by feeding this document into the following shell script:
通过将此文档输入以下shell脚本，可以提取嵌入此文档中的外部数据表示（XDR）[RFC4506]描述的附加行：
<CODE BEGINS>
<代码开始>
#!/bin/sh
grep '^ *///' $* | sed 's?^ */// ??' | sed 's?^ *///$??'
#!/bin/sh
grep '^ *///' $* | sed 's?^ */// ??' | sed 's?^ *///$??'
<CODE ENDS>
<代码结束>
That is, if the above script is stored in a file called "extract.sh", and this document is in a file called "umask.txt", then the reader can do:
也就是说，如果上述脚本存储在一个名为“extract.sh”的文件中，并且该文档存储在一个名为“umask.txt”的文件中，那么读者可以执行以下操作：
sh extract.sh < umask.txt > umask.x
sh extract.sh<umask.txt>umask.x
The effect of the script is to remove leading white space from each line, plus a sentinel sequence of "///".
脚本的作用是删除每行的前导空格，以及“//”的哨兵序列。
Once that extraction is done, these added lines need to be inserted into an appropriate base XDR of the generated XDR from [RFC7863] together with XDR from any additional extensions to be recognized by the implementation. This will result in a ready-to-compile XDR file.
提取完成后，需要将这些添加的行插入到[RFC7863]生成的XDR的适当基本XDR中，并与实现识别的任何其他扩展的XDR一起插入。这将产生一个准备编译的XDR文件。
<CODE BEGINS>
<代码开始>
/// struct mode_umask4 {
/// mode4 mu_mode;
/// mode4 mu_umask;
/// };
///
/// %/*
/// % * New For UMASK
/// % */
/// const FATTR4_MODE_UMASK = 81;
/// struct mode_umask4 {
/// mode4 mu_mode;
/// mode4 mu_umask;
/// };
///
/// %/*
/// % * New For UMASK
/// % */
/// const FATTR4_MODE_UMASK = 81;
<CODE ENDS>
<代码结束>
+------------+----+-------------+-----+------------+
| Name | Id | Data Type | Acc | Defined in |
+------------+----+-------------+-----+------------+
| mode_umask | 81 | mode_umask4 | W | Section 5 |
+------------+----+-------------+-----+------------+
+------------+----+-------------+-----+------------+
| Name | Id | Data Type | Acc | Defined in |
+------------+----+-------------+-----+------------+
| mode_umask | 81 | mode_umask4 | W | Section 5 |
+------------+----+-------------+-----+------------+
Table 1
表1
The NFSv4.2 mode_umask attribute is based on the umask and on the mode bits specified at open time, which together determine the mode of a newly created UNIX file. Only the nine low-order mode4 bits of mu_umask are defined. A server MUST return NFS4ERR_INVAL if bits other than those nine are set.
NFSv4.2 mode_umask属性基于umask和在打开时指定的模式位，它们共同确定新创建的UNIX文件的模式。仅定义了mu_umask的九个低阶mode4位。如果设置了九位以外的位，服务器必须返回NFS4ERR_INVAL。
The mode_umask attribute is only meaningful for operations that create objects (CREATE and OPEN); in other operations that take fattr4 arguments, the server MUST reject it with NFS4ERR_INVAL.
mode_umask属性仅对创建对象（创建和打开）的操作有意义；在采用fattr4参数的其他操作中，服务器必须使用NFS4ERR_INVAL拒绝它。
The server MUST return NFS4ERR_INVAL if the client attempts to set both mode and mode_umask in the same operation.
如果客户端试图在同一操作中同时设置mode和mode_umask，则服务器必须返回NFS4ERR_INVAL。
When the server supports the mode_umask attribute, a client creating a file should use mode_umask in place of mode, with mu_mode set to the unmodified mode provided by the user and mu_umask set to the umask of the requesting process.
当服务器支持mode_umask属性时，创建文件的客户端应使用mode_umask代替mode，mu_mode设置为用户提供的未修改模式，mu_umask设置为请求进程的umask。
The server then uses mode_umask as follows:
然后，服务器使用模式_umask，如下所示：
o On a server that supports ACL attributes, if an object inherits any ACEs from its parent directory, mu_mode SHOULD be used and mu_umask ignored.
o 在支持ACL属性的服务器上，如果对象从其父目录继承任何ACE，则应使用mu_模式并忽略mu_umask。
o Otherwise, mu_umask MUST be used to limit the mode: all bits in the mode that are set in the unmask MUST be turned off; the mode assigned to the new object becomes (mu_mode & ~mu_umask) instead.
o 否则，必须使用mu_umask来限制模式：必须关闭在解掩码中设置的模式中的所有位；指定给新对象的模式改为（mu_mode&~mu_umask）。
The mode_umask attribute shifts to the server the decision about when to apply the umask. Because the server MUST apply the umask if there are no inheritable permissions, the traditional semantics are preserved in the absence of a permission inheritance mechanism. The only relaxation of permissions comes in the case in which servers follow the recommendation that they ignore the umask in the presence of inheritable permissions.
mode_umask属性将有关何时应用umask的决定转移到服务器。因为如果没有可继承的权限，服务器必须应用umask，所以在没有权限继承机制的情况下，传统的语义得以保留。唯一放宽权限的情况是，服务器遵循在存在可继承权限的情况下忽略umask的建议。
The practice of ignoring the umask when there are inheritable permissions in the form of a "POSIX" default ACL is of long standing and has not given rise to security issues. The "POSIX" default ACL mechanism and the mechanism for permission inheritance in NFSv4 are equivalent from a security perspective.
当存在“POSIX”默认ACL形式的可继承权限时忽略umask的做法由来已久，并且没有引起安全问题。从安全角度来看，“POSIX”默认ACL机制和NFSv4中的权限继承机制是等效的。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 2006, <https://www.rfc-editor.org/info/rfc4506>.
[RFC4506]艾斯勒，M.，编辑，“XDR：外部数据表示标准”，STD 67，RFC 4506，DOI 10.17487/RFC4506，2006年5月<https://www.rfc-editor.org/info/rfc4506>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <https://www.rfc-editor.org/info/rfc7530>.
[RFC7530]Haynes，T.，Ed.和D.Noveck，Ed.，“网络文件系统（NFS）第4版协议”，RFC 7530，DOI 10.17487/RFC7530，2015年3月<https://www.rfc-editor.org/info/rfc7530>.
[RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, November 2016, <https://www.rfc-editor.org/info/rfc7862>.
[RFC7862]Haynes，T.，“网络文件系统（NFS）版本4次要版本2协议”，RFC 7862，DOI 10.17487/RFC7862，2016年11月<https://www.rfc-editor.org/info/rfc7862>.
[RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description", RFC 7863, DOI 10.17487/RFC7863, November 2016, <https://www.rfc-editor.org/info/rfc7863>.
[RFC7863]Haynes，T.，“网络文件系统（NFS）版本4次要版本2外部数据表示标准（XDR）说明”，RFC 7863，DOI 10.17487/RFC7863，2016年11月<https://www.rfc-editor.org/info/rfc7863>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8178] Noveck, D., "Rules for NFSv4 Extensions and Minor Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017, <https://www.rfc-editor.org/info/rfc8178>.
[RFC8178]Noveck，D.，“NFSv4扩展和次要版本的规则”，RFC 8178，DOI 10.17487/RFC8178，2017年7月<https://www.rfc-editor.org/info/rfc8178>.
[LinuxACL] Gruenbacher, A., "ACL(5) - Access Control Lists", Linux man pages online, ACL(5), March 2002, <http://kernel.org/doc/man-pages/online/pages/man5/ acl.5.html>.
[LinuxACL]Grunbacher，A.，“ACL（5）-访问控制列表”，Linux联机手册页，ACL（5），2002年3月<http://kernel.org/doc/man-pages/online/pages/man5/ acl.5.html>。
[SUSv4] The Open Group, "Single UNIX Specification, Version 4", 2013.
[SUSv4]开放组，“单一UNIX规范，版本4”，2013年。
Acknowledgments
致谢
Thanks to Trond Myklebust and Dave Noveck for their review and the suggestion to define this as a (mode, umask) pair rather than just umask. Thanks to Warren Kumari, Adam Roach, Spencer Dawkins, Mike Kupfer, and Thomas Haynes for their review and to Thomas Haynes for help with XDR.
感谢Trond Myklebust和Dave Noveck的审查，并建议将其定义为（模式，umask）对，而不仅仅是umask。感谢Warren Kumari、Adam Roach、Spencer Dawkins、Mike Kupfer和Thomas Haynes的评论，以及Thomas Haynes对XDR的帮助。
Authors' Addresses
作者地址
J. Bruce Fields Red Hat, Inc.
J.布鲁斯·菲尔兹红帽公司。
Email: bfields@redhat.com
Email: bfields@redhat.com
Andreas Gruenbacher Red Hat, Inc.
安德烈亚斯·格鲁恩巴赫红帽公司。
Email: agruenba@redhat.com
Email: agruenba@redhat.com