idnits 2.17.1 draft-ietf-nfsv4-umask-04.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 (July 20, 2017) is 2469 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: January 21, 2018 July 20, 2017 7 Allowing Inheritable NFSv4 Access Control Entries to Override the Umask 8 draft-ietf-nfsv4-umask-04 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 January 21, 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. 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 . . . . . . . . . . . . . . . . . 5 62 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 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 Access Control List (ACL) to be no more than the 80 permissions granted by the MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP 81 bits. Servers aiming to provide clients with Unix-like chmod 82 behavior may also be motivated by the same requirements in [SUSv4]. 83 (See the discussion of additional and alternate access control 84 mechanisms in section "4.4 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 ACL 90 entries (inheritable ACEs) describing the permissions to be granted 91 to named users and groups are often ignored. This makes inheritable 92 ACEs useless in some 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 ACEs. 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 [nfsv4-versioning] 196 Noveck, D., "Rules for NFSv4 Extensions and Minor 197 Versions", draft-ietf-nfsv4-versioning-08 (work in 198 progress), December 2016. 200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 201 Requirement Levels", March 1997. 203 [RFC7530] Haynes, T. and D. Noveck, "Network File System (NFS) 204 version 4 Protocol", RFC 7530, March 2015. 206 [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor 207 Version 2 Protocol", RFC 7862, November 2016. 209 [RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor 210 Version 2 External Data Representation Standard (XDR) 211 Description", RFC 7863, November 2016. 213 7.2. Informative References 215 [LinuxACL] 216 Gruenbacher, A., "ACL(5) - Access Control Lists", Linux 217 man pages ACL(5), March 2002, . 220 [SUSv4] The Open Group, "Single UNIX Specification Version 4", 221 2013. 223 Appendix A. Acknowledgments 225 Thanks to Dave Noveck and Trond Myklebust for review. 227 Authors' Addresses 229 J. Bruce Fields 230 Red Hat, Inc. 232 Email: bfields@redhat.com 233 Andreas Gruenbacher 234 Red Hat, Inc. 236 Email: agruenba@redhat.com