idnits 2.17.1 draft-ietf-nfsv4-umask-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 30, 2017) is 2429 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 J. Fields 3 Internet-Draft A. Gruenbacher 4 Intended status: Standards Track Red Hat 5 Expires: March 3, 2018 August 30, 2017 7 Allowing Inheritable NFSv4 Access Control Entries to Override the Umask 8 draft-ietf-nfsv4-umask-05 10 Abstract 12 In many environments, inheritable NFSv4 Access Control Entries (ACEs) 13 can be rendered ineffective by the application of the per-process 14 umask. This can be addressed by transmitting the umask and create 15 mode as separate pieces of data, allowing the server to make more 16 intelligent decisions about the permissions to set on new files. 17 This document proposes a protocol extension which accomplishes that. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 3, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Conventions Used in This Document . . . . . . . . . . . . . . 2 54 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Protocol Extension Considerations . . . . . . . . . . . . . . 3 56 4. XDR Extraction . . . . . . . . . . . . . . . . . . . . . . . 3 57 5. mode_umask Attribute . . . . . . . . . . . . . . . . . . . . 4 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 8.2. Informative References . . . . . . . . . . . . . . . . . 6 63 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Conventions Used in This Document 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [RFC2119]. 72 2. Problem Statement 74 On Unix-like systems, each process is associated with a file mode 75 creation mask (umask), which specifies which permissions must be 76 turned off when creating new file system objects. 78 When applying the mode, section 6.4.1.1 of [RFC7530] recommends that 79 servers SHOULD restrict permissions granted to any user or group 80 named in the Access Control List (ACL) to be no more than the 81 permissions granted by the MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP 82 bits. Servers aiming to provide clients with Unix-like chmod 83 behavior may also be motivated by the same requirements in [SUSv4]. 84 (See the discussion of additional and alternate access control 85 mechanisms in section "4.4 File Permissions" of that document.) 87 On many existing installations, all ordinary users by default use the 88 same effective group ID. To prevent granting all users full access 89 to each other's files, such installations usually default to a umask 90 with very restrictive permissions. As a result, inherited ACL 91 entries (inheritable ACEs) describing the permissions to be granted 92 to named users and groups are often ignored. This makes inheritable 93 ACEs useless in some common cases. 95 Linux solves this problem on local filesystems by ignoring the umask 96 in the case the parent of the newly-created file has inheritable 97 ACEs; see [LinuxACL]. 99 The same solution should work for NFS. However, the NFSv4 protocol 100 does not currently give the client a way to transmit the umask of the 101 process opening a file. And clients have no way of atomically 102 checking for inheritable permissions and applying the umask only when 103 necessary. As a result, the server receives an OPEN with a mode 104 attribute that already has the umask applied. 106 This document solves the problem by defining a new attribute which 107 allows the client to transmit umask and the mode specified at file 108 creation separately, allowing the client to ignore the umask in the 109 presence of inheritable ACEs. At least in the Linux case, this 110 allows NFSv4 to provide the same semantics available using local 111 access. 113 3. Protocol Extension Considerations 115 This document presents an extension to minor version 2 of the NFSv4 116 protocol as described in [nfsv4-versioning]. It describes a new 117 OPTIONAL feature. NFSv4.2 servers and clients implemented without 118 knowledge of this extension will continue to interoperate with 119 clients and servers that are aware of the extension (whether they 120 support it or not). 122 Note that [RFC7862] does not define NFSv4.2 as non-extensible, so 123 that it is considered by [nfsv4-versioning] to be an extensible minor 124 version. As a result, upon publication of this document as a 125 Proposed Standard, the extension described herein will effectively be 126 part of NFSv4.2, even though this document does not update [RFC7862] 127 or [RFC7863]. 129 4. XDR Extraction 131 The additional lines of external data representation (XDR) [RFC4506] 132 description embedded in this document can be extracted by feeding 133 this document into the following shell script: 135 137 #!/bin/sh 138 grep '^ *///' $* | sed 's?^ */// ??' | sed 's?^ *///$??' 140 141 That is, if the above script is stored in a file called "extract.sh", 142 and this document is in a file called "umask.txt", then the reader 143 can do: 145 sh extract.sh < umask.txt > umask.x 147 The effect of the script is to remove leading white space from each 148 line, plus a sentinel sequence of "///". 150 Once that extraction is done, these added lines need to be inserted 151 into an appropiate base XDR of the generated XDR from [RFC7863], 152 together with XDR from any additional extensions to be recognized by 153 the implementation. This will result in a ready-to-compile XDR file. 155 5. mode_umask Attribute 157 159 /// struct mode_umask4 { 160 /// mode4 mu_mode; 161 /// mode4 mu_umask; 162 /// }; 163 /// 164 /// %/* 165 /// % * New For UMASK 166 /// % */ 167 /// const FATTR4_MODE_UMASK = 81; 169 171 +------------+----+-------------+-----+------------+ 172 | Name | Id | Data Type | Acc | Defined in | 173 +------------+----+-------------+-----+------------+ 174 | mode_umask | 81 | mode_umask4 | W | Section 5 | 175 +------------+----+-------------+-----+------------+ 177 Table 1 179 The NFSv4.2 mode_umask attribute is based on the umask and on the 180 mode bits specified at open time, which together determine the mode 181 of a newly created UNIX file. Only the nine low-order mode4 bits of 182 mu_umask are defined. A server MUST return NFS4ERR_INVAL if bits 183 other than those nine are set. 185 The mode_umask attribute is only meaningful for operations that 186 create objects (CREATE and OPEN); in other operations that take 187 fattr4 arguments, the server MUST reject it with NFS4ERR_INVAL. 189 The server MUST return NFS4ERR_INVAL if the client attempts to set 190 both mode and mode_umask in the same operation. 192 When the server supports the mode_umask attribute, a client creating 193 a file should use mode_umask in place of mode, with mu_mode set to 194 the unmodified mode provided by the user, and mu_umask set to the 195 umask of the requesting process. 197 The server then uses mode_umask as follows: 199 o On a server that supports ACL attributes, if an object inherits 200 any ACEs from its parent directory, mu_mode SHOULD be used, and 201 mu_umask ignored. 203 o Otherwise, mu_umask MUST be used to limit the mode: all bits in 204 the mode MUST be turned off which are set in the umask; the mode 205 assigned to the new object becomes (mu_mode & ~mu_umask) instead. 207 6. Security Considerations 209 The mode_umask attribute shifts to the server the decision about when 210 to apply the umask. Because the server MUST apply the umask if there 211 are no inheritable permissions, the traditional semantics are 212 preserved in the absence of a permission inheritance mechanism. The 213 only relaxation of permissions comes in the case servers follow the 214 recommendation that they ignore the umask in the presence of 215 inheritable permissions. 217 The practice of ignoring the umask when there are inheritable 218 permissions in the form of a "POSIX" default ACL is of long standing 219 and has not given rise to security issues. The "POSIX" default ACL 220 mechanism and the mechanism for permission inheritance in NFSv4 are 221 equivalent from a security perspective. 223 7. IANA Considerations 225 This document does not require any actions by IANA. 227 8. References 229 8.1. Normative References 231 [nfsv4-versioning] 232 Noveck, D., "Rules for NFSv4 Extensions and Minor 233 Versions", draft-ietf-nfsv4-versioning-08 (work in 234 progress), December 2016. 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", March 1997. 239 [RFC4506] Eisler, M., "XDR: External Data Representation Standard", 240 STD 67, RFC 4506, May 2006. 242 [RFC7530] Haynes, T. and D. Noveck, "Network File System (NFS) 243 version 4 Protocol", RFC 7530, March 2015. 245 [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor 246 Version 2 Protocol", RFC 7862, November 2016. 248 [RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor 249 Version 2 External Data Representation Standard (XDR) 250 Description", RFC 7863, November 2016. 252 8.2. Informative References 254 [LinuxACL] 255 Gruenbacher, A., "ACL(5) - Access Control Lists", Linux 256 man pages ACL(5), March 2002, . 259 [SUSv4] The Open Group, "Single UNIX Specification Version 4", 260 2013. 262 Appendix A. Acknowledgments 264 Thanks to Trond Myklebust and Dave Noveck for the suggestion to 265 define this as a (mode, umask) pair rather than just umask. Thanks 266 for review to them and to Warren Kumari, Adam Roach, Spencer Dawkins, 267 Mike Kupfer, and Thomas Haynes for review, and to Thomas Haynes for 268 XDR help. 270 Authors' Addresses 272 J. Bruce Fields 273 Red Hat, Inc. 275 Email: bfields@redhat.com 277 Andreas Gruenbacher 278 Red Hat, Inc. 280 Email: agruenba@redhat.com