idnits 2.17.1 draft-ietf-nfsv4-umask-03.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 (March 03, 2017) is 2583 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) == Unused Reference: 'LEGAL' is defined on line 195, but no explicit reference was found in the text == Unused Reference: 'RFC4506' is defined on line 207, but no explicit reference was found in the text == Unused Reference: 'RFC5661' is defined on line 210, but no explicit reference was found in the text == Unused Reference: 'RFC5662' is defined on line 214, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'LEGAL' ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) -- Possible downref: Non-RFC (?) normative reference: ref. 'SUSv4' Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). 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: September 4, 2017 March 03, 2017 7 Allowing Inheritable NFSv4 ACLs to Override the Umask 8 draft-ietf-nfsv4-umask-03 10 Abstract 12 In many important environments, inheritable NFSv4 ACLs can be 13 rendered ineffective by the application of the per-process umask. 14 This can be addressed by transmitting the umask and create mode as 15 separate pieces of data, allowing the server to make more intelligent 16 decisions about the permissions to set on new files. This document 17 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 September 4, 2017. 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. mode_umask Attribute . . . . . . . . . . . . . . . . . . . . 3 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 61 7.2. Informative References . . . . . . . . . . . . . . . . . 6 62 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Conventions Used in This Document 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in [RFC2119]. 71 2. Problem Statement 73 On Unix-like systems, each process is associated with a file mode 74 creation mask (umask), which specifies which permissions must be 75 turned off when creating new file system objects. 77 When applying the mode, section 6.4.1.1 of [RFC7530] recommends that 78 servers SHOULD restrict permissions granted to any user or group 79 named in the ACL to be no more than the permissions granted by the 80 MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP bits. Servers aiming to 81 provide clients with Unix-like chmod behavior may also be motivated 82 by the same requirements in [SUSv4]. (See the discussion of 83 additional and alternate access control mechanisms in section "4.4 84 File Permissions" of that document.) 86 On many existing installations, all ordinary users by default use the 87 same effective group ID. To prevent granting all users full access 88 to each other's files, such installations usually default to a umask 89 with very restrictive permissions. As a result, inherited ACEs 90 describing the permissions to be granted to named users and groups 91 are often ignored. This makes inheritable ACLs useless in some 92 common cases. 94 Linux solves this problem on local filesystems by ignoring the umask 95 in the case the parent of the newly-created file has inheritable 96 ACEs; see [LinuxACL]. 98 The same solution should work for NFS. However, the NFSv4 protocol 99 does not currently give the client a way to transmit the umask of the 100 process opening a file. And clients have no way of atomically 101 checking for inheritable permissions and applying the umask only when 102 necessary. As a result, the server receives an OPEN with a mode 103 attribute that already has the umask applied. 105 This document solves the problem by defining a new attribute which 106 allows the client to transmit umask and the mode specified at file 107 creation separately, allowing the client to ignore the umask in the 108 presence of inheritable ACLs. At least in the Linux case, this 109 allows NFSv4 to provide the same semantics available using local 110 access. 112 3. Protocol Extension Considerations 114 This document presents an extension to minor version 2 of the NFSv4 115 protocol as described in [nfsv4-versioning]. It describes a new 116 OPTIONAL feature. NFSv4.2 servers and clients implemented without 117 knowledge of this extension will continue to interoperate with 118 clients and servers that are aware of the extension (whether they 119 support it or not). 121 Note that [RFC7862] does not define NFSv4.2 as non-extensible, so 122 that it is considered by [nfsv4-versioning] to be an extensible minor 123 version. As a result, upon publication of this document as a 124 Proposed Standard, the extension described herein will effectively be 125 part of NFSv4.2, even though this document does not update [RFC7862] 126 or [RFC7863]. 128 4. mode_umask Attribute 130 struct mode_umask4 { 131 mode4 mu_mode; 132 mode4 mu_umask; 133 }; 135 +------------+----+-------------+-----+------------+ 136 | Name | Id | Data Type | Acc | Defined in | 137 +------------+----+-------------+-----+------------+ 138 | mode_umask | 81 | mode_umask4 | W | Section 4 | 139 +------------+----+-------------+-----+------------+ 141 Table 1 143 The NFSv4.2 mode_umask attribute is based on the umask and on the 144 mode bits specified at open time, which together determine the mode 145 of a newly created UNIX file. Only the nine low-order mode4 bits of 146 mu_umask are defined. A server MUST return NFS4ERR_INVAL if bits 147 other than those nine are set. 149 The mode_umask attribute is only meaningful for operations that 150 create objects (CREATE and OPEN); in other operations that take 151 fattr4 arguments, the server MUST reject it with NFS4ERR_INVAL. 153 The server MUST return NFS4ERR_INVAL if the client attempts to set 154 both mode and mode_umask in the same operation. 156 When the server supports the mode_umask attribute, a client creating 157 a file should use mode_umask in place of mode, with mu_mode set to 158 the unmodified mode provided by the user, and mu_umask set to the 159 umask of the requesting process. 161 The server then uses mode_umask as follows: 163 o On a server that supports ACL attributes, if an object inherits 164 any ACEs from its parent directory, mu_mode SHOULD be used, and 165 mu_umask ignored. 167 o Otherwise, mu_umask MUST be used to limit the mode: all bits in 168 the mode MUST be turned off which are set in the umask; the mode 169 assigned to the new object becomes (mu_mode & ~mu_umask) instead. 171 5. Security Considerations 173 The mode_umask attribute shifts to the server the decision about when 174 to apply the umask. Because the server MUST apply the umask if there 175 are no inheritable permissions, the traditional semantics are 176 preserved in the absence of a permission inheritance mechanism. The 177 only relaxation of permissions comes in the case servers follow the 178 RECOMMENDATION that they ignore the umask in the presence of 179 inheritable permissions. 181 The practice of ignoring the umask when there are inheritable 182 permissions in the form of a "POSIX" default ACL is of long standing 183 and has not given rise to security issues. The "POSIX" default ACL 184 mechanism and the mechanism for permission inheritance in NFSv4 are 185 equivalent from a security perspective. 187 6. IANA Considerations 189 This document does not require any actions by IANA. 191 7. References 193 7.1. Normative References 195 [LEGAL] IETF Trust, "Legal Provisions Relating to IETF Documents", 196 November 2008, . 199 [nfsv4-versioning] 200 Noveck, D., "Rules for NFSv4 Extensions and Minor 201 Versions", draft-ietf-nfsv4-versioning-08 (work in 202 progress), December 2016. 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels", March 1997. 207 [RFC4506] Eisler, M., "XDR: External Data Representation Standard", 208 STD 67, RFC 4506, May 2006. 210 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 211 "Network File System (NFS) Version 4 Minor Version 1 212 Protocol", RFC 5661, January 2010. 214 [RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 215 "Network File System (NFS) Version 4 Minor Version 1 216 External Data Representation Standard (XDR) Description", 217 RFC 5662, January 2010. 219 [RFC7530] Haynes, T. and D. Noveck, "Network File System (NFS) 220 version 4 Protocol", RFC 7530, March 2015. 222 [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor 223 Version 2 Protocol", RFC 7862, November 2016. 225 [RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor 226 Version 2 External Data Representation Standard (XDR) 227 Description", RFC 7863, November 2016. 229 [SUSv4] The Open Group, "Single UNIX Specification Version 4", 230 2013. 232 7.2. Informative References 234 [LinuxACL] 235 Gruenbacher, A., "ACL(5) - Access Control Lists", Linux 236 man pages ACL(5), March 2002, . 239 Appendix A. Acknowledgments 241 Thanks to Dave Noveck and Trond Myklebust for review. 243 Authors' Addresses 245 J. Bruce Fields 246 Red Hat, Inc. 248 Email: bfields@redhat.com 250 Andreas Gruenbacher 251 Red Hat, Inc. 253 Email: agruenba@redhat.com