idnits 2.17.1 draft-ietf-nfsv4-acl-mapping-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2004) is 7126 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: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Marius Aamodt Eriksen 3 Internet Draft J. Bruce Fields 4 Document: draft-ietf-nfsv4-acl-mapping-02.txt October 2004 6 Mapping Between NFSv4 and Posix Draft ACLs 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be dis- 13 closed, in accordance with RFC 3668. 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference mate- 26 rial or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 "Copyright (C) The Internet Society (2002-2004). All Rights 35 Reserved." 37 Abstract 39 NFS version 4 [rfc3530] (NFSv4) specifies a flavor of Access Control 40 Lists (ACLs) resembling Windows NT ACLs. A number of operating sys- 41 tems use a different flavor of ACL based on a withdrawn POSIX draft. 42 NFSv4 clients and servers on such operating systems may wish to map 44 Mapping NFSv4 ACLs October 2004 46 between NFSv4 ACLs and their native ACLs. To this end, we describe a 47 mapping from POSIX draft ACLs to a subset of NFSv4 ACLs. 49 Mapping NFSv4 ACLs October 2004 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. NFSv4 ACLs . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. POSIX ACLs . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Mapping Posix ACLs to NFSv4 ACLs . . . . . . . . . . . . . . 6 57 5. Using the Mapping in NFSv4 Implementations . . . . . . . . . 8 58 6. Security Considerations . . . . . . . . . . . . . . . . . 10 59 7. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 11 60 8. Author's Address . . . . . . . . . . . . . . . . . . . . . 12 61 9. Copyright . . . . . . . . . . . . . . . . . . . . . . . . 12 63 Mapping NFSv4 ACLs October 2004 65 1. Introduction 67 Access Control Lists (ACLs) are used to specify fine-grained access 68 rights to file system objects. An ACL consists of a number of Access 69 Control Entries (ACEs), each specifying some level of access for an 70 entity. The entity may be a user, a group, or a special entity (such 71 as "everyone"). The level of access is described using an access 72 mask, which is a bitmask with each bit corresponding to a type of 73 access (such as "read" or "append"). 75 In the following sections we describe two ACL models: NFSv4 ACLs, and 76 ACLs based on a withdrawn POSIX draft, which we will refer to as 77 "POSIX ACLs". Since NFSv4 ACLs are much finer-grained than POSIX 78 ACLs, it is not possible in general to map an arbitrary NFSv4 ACL to 79 a POSIX ACL with the same semantics. It does, however, turn out to 80 be possible to map any POSIX ACL to a NFSv4 ACL that has nearly iden- 81 tical semantics. We will describe such a mapping, and discuss how it 82 might be used in NFSv4 client and server implementations. 84 2. NFSv4 ACLs 86 An NFSv4 ACL is an ordered sequence of ACEs, each having an entity, a 87 type, and an access mask. The entity may be the name of a user or 88 group, or may also be one of a small set of special entities. Among 89 the special entities are "OWNER" (the current owner of the file), 90 "GROUP" (the group associated with the file), and "EVERYONE". 92 The access mask includes bits for access types that are more fine- 93 grained than the traditional "read", "write", and "execute" permis- 94 sions used in UNIX mode bits. 96 The type may be ALLOW or DENY. (AUDIT or ALARM are also allowed, but 97 they are not relevant to our discussion). 99 The NFSv4 ACL permission-checking algorithm is straightforward. 100 Given an ACL and a requestor asking for a set of permissions speci- 101 fied by an access mask: 103 1) Walk through the list of ACEs from the ACL in order. 105 2) Ignore any ACE for with an entity not matching requestor. 107 Mapping NFSv4 ACLs October 2004 109 3) Process all ACEs until all the bits in the requested access mask 110 have been ALLOWed by an ALLOW ace with that bit set. Once a par- 111 ticular bit has been ALLOWed by an ACE, it is no longer considered 112 in further processing. 114 4) If a bit in the requested access mask is DENYed (while that bit is 115 still under consideration), the request is denied. 117 5) If all bits have been ALLOWed, the access is granted. Otherwise 118 behavior is undefined. 120 There are also a number of flags that can be applied to an NFSv4 ACE. 121 Three flags that we will need to use in the following discussion 122 apply to ACEs in a directory ACL. They are: ACE4_DIREC- 123 TORY_INHERIT_ACE, which indicates that the ACE should be added to new 124 subdirectories of the directory; ACE4_FILE_INHERIT_ACE, which does 125 the same for new files; and ACE4_INHERIT_ONLY, which indicates that 126 the ACE should be ignored when determining access to the directory 127 itself. 129 We refer the reader to [rfc3530] for further details. 131 3. POSIX ACLs 133 A number of operating systems, including Linux and FreeBSD, implement 134 ACLs based on the withdrawn POSIX 1003.1e/1003.2c Draft Standard 17 135 [posixacl]. We will refer to such ACLs as "POSIX ACLs". 137 POSIX ACLs use access masks with only the traditional "read", 138 "write", and "execute" bits. Each ACE in a POSIX ACL is one of five 139 types: ACL_USER_OBJ, ACL_USER, ACL_GROUP_OBJ, ACL_GROUP, ACL_MASK, 140 and ACL_OTHER. Each ACL_USER ACE has a uid associated with it, and 141 each ACL_GROUP ACE has a gid associated with it. Every POSIX ACL 142 must have exactly one ACL_USER_OBJ, ACL_GROUP, and ACL_OTHER ACE, and 143 at most one ACL_MASK ace. The ACL_MASK ace is required if the ACL 144 has any ACL_USER or ACL_GROUP aces. There may not be two ACL_USER 145 aces with the same uid, and there may not be two ACL_GROUP aces with 146 the same gid. 148 Given a POSIX ACL and a requestor asking for access, permission is 149 determined as follows: 151 1) If the requestor is the file owner, then allow or deny access 152 depending on whether the ACL_USER_OBJ ACE allows or denies it. 154 Mapping NFSv4 ACLs October 2004 156 Otherwise, 158 2) if the requestor's uid matches the uid of one of the ACL_USER 159 ACE's, then allow or deny access depending on whether the 160 ACL_USER_OBJ ACE allows or denies it. Otherwise, 162 3) Consider the set of all ACL_GROUP ACE's whose gid the requestor is 163 a member of. Add to that set the ACL_GROUP_OBJ ACE, if the 164 requestor is also a member of that group. Allow access if one of 165 the ACE's in the resulting set allows access. If the set of 166 matching ACEs is nonempty, and none allow access, then deny 167 access. Otherwise, if none of these ACEs match, 169 4) if the requester's access mask is allowed by the ACL_OTHER ACE, 170 then grant access. Otherwise, deny access. 172 Steps (2) and (3) have an additional criteria; in addition to check- 173 ing whether the requested access mask is allowed by the access mask 174 in the ACE, the requested bits also have to be in the access mask of 175 the special ACE with the ACL_MASK entity. This allows file owners to 176 specify a maximum level of access allowed by any other user or group 177 that has any access to the file system object. 179 In addition to a regular POSIX ACL, a directory in the file system 180 may also have associated with it a default ACL. This default ACL 181 does not affect permissions to the directory itself. Instead, it 182 governs the ACL a file system object will be assigned initially when 183 it is created as a child of the particular directory. 185 4. Mapping Posix ACLs to NFSv4 ACLs 187 Given the differences between POSIX and NFSv4 ACLs, any conversion 188 between the two is difficult. However, POSIX ACLs are a subset of 189 NFSv4 ACLs, and any POSIX ACL can be emulated with an NFSv4 ACL using 190 the following mapping. 192 First, the uid's and gid's on the ACL_USER and ACL_GROUP ACEs must be 193 translated into NFSv4 names--a system-dependent process, which, on 194 UNIX for example, may be done by lookups to /etc/passwd. Also, the 195 special ACL_USER_OBJ, ACL_GROUP_OBJ, and ACL_OTHER ACEs must be 196 translated to NFSv4 ACEs with the special entities "OWNER", "GROUP", 197 and "EVERYONE", respectively. 199 The ACE access mask is translated as follows. The read bit of the 200 POSIX access mask is translated to the logical OR of the 202 Mapping NFSv4 ACLs October 2004 204 ACE4_READ_DATA and ACE4_READ_NAMED_ATTRS NFSv4 access mask fields. 205 The write bit of the POSIX access mask is translated to the logical 206 OR of the ACE4_WRITE_DATA, ACE4_WRITE_NAMED_ATTRS and 207 ACE4_APPEND_DATA NFSv4 access mask fields. The execute bit of the 208 POSIX access mask is translated into the ACE4_EXECUTE and 209 ACE4_READ_DATA NFSv4 acess mask fields. Note that NFSv4 defines 210 ACE4_READ_DATA, ACE4_WRITE_DATA, and ACE4_APPEND_DATA to be equal to 211 ACE4_LIST_DIRECTORY, ACE4_ADD_FILE, and ACE4_ADD_SUBDIRECTORY, 212 respectively, so this translation makes sense for directories as 213 well. However, on directories the ACE4_DELETE_CHILD field must be 214 included in the translation of the POSIX write bit. 216 In addition to the above, the OWNER entity must always be given 217 ACE4_WRITE_ACL and ACE4_WRITE_ATTRIBUTES, and all entities must be 218 given ACE4_READ_ACL, ACE4_READ_ATTRIBUTES, and ACE4_SYNCHRONIZE. The 219 ACE4_DELETE bit should be neither allowed nor denied by any ACE. 221 The ACE flag field also has a simple translation. If the file system 222 object is a directory, and the POSIX ACE belongs to a default ACL, 223 the ACE4_INHERIT_ONLY_ACE, ACE4_DIRECTORY_INHERIT, and 224 ACE4_FILE_INHERIT flags are set in the NFSv4 ACE. If the entity in 225 the POSIX ACE refers to a group, the "ACE4_IDENTIFIER_GROUP" flag is 226 set in the NFSv4 ACE. 228 The POSIX ACL_USER_OBJ ACE is also always given the permission bits 229 "ACE4_READ_ACL" and "ACE4_WRITE_ACL." 231 Completing the mapping reduces to being able to emulate an ACL_MASK 232 and compensate for some differences in the permission-checking algo- 233 rithms of the two ACL implementations. 235 The difference in permission-checking algorithms is handled as fol- 236 lows: 238 Every user ACE in the POSIX ACL maps into 2 NFSv4 ACEs; one ALLOW ACE 239 which is translated as specified by the above scheme, then a comple- 240 menting DENY ACE which is also translated as specified by the above 241 scheme, with the exception that the access mask is inverted. Note 242 that the ACL_USER_OBJ ACE is placed first in this list. 244 Every group ACE in the POSIX ACL produces a similar pair, but instead 245 of being in sequence, all of the ALLOW ACEs are all in sequence, fol- 246 lowed by all the DENY ACEs. The ACL_GROUP_OBJ ACE is placed first in 247 both lists. 249 Lastly, the POSIX ACL_OTHER ACE is translated into a pair of ACEs as 250 in the user ACE case. 252 Mapping NFSv4 ACLs October 2004 254 With this done, the NFSv4 permission-checking algorithm applied to 255 the resulting NFSv4 ACL will produce the same result as the POSIX 256 permission-checking algorithm did on the original POSIX ACL. 258 To handle the special POSIX entity ACL_MASK, we slightly modify the 259 above translation: 261 With the exception of the "OWNER" and "EVERYONE" ACEs, another ACE is 262 prepended to the ACE. The prepended ACE is a DENY ACE with the same 263 entity as the following ALLOW ACE, but with a permission mask set to 264 the complement of the POSIX ACL_MASK. 266 This method allows us to preserve the real permission bits of each 267 ACE should the ACL_MASK be changed. 269 5. Using the Mapping in NFSv4 Implementations 271 Note that the algorithm described in the previous section not only 272 provides a way to map any POSIX ACL to be mapped to an NFSv4 ACL with 273 similar semantics, but also provides the reverse mapping in the case 274 where the NFSv4 ACL is precisely in the format of an ACL produced by 275 the algorithm above. 277 The algorithm can therefore be used to implement a subset of the 278 NFSv4 ACL model. This may be useful to NFSv4 clients and servers 279 with preexisting system interfaces that support POSIX ACLs and that 280 cannot be modified to support NFSv4 ACLs. 282 A server, for example, that wishes to export via NFSv4 a filesystem 283 that supports only POSIX ACLs, may use this mapping to answer client 284 requests for existing ACLs by translating POSIX ACLs on its filesys- 285 tem to NFSv4 ACLs to send to the client. However, when a client 286 attempts to set an ACL, the server faces a problem. If the given ACL 287 happens to be in precisely the format of an ACL produced by this map- 288 ping (as would happen if, for example, the client was performing the 289 same translation), then the server can map it to a POSIX ACL to store 290 on the filesystem. But for any other NFSv4 ACL, the server should 291 return an error to avoid any chance of inaccurately representing the 292 client's intention. 294 The language of [rfc3530] allows a server some flexibility in han- 295 dling ACLs that it cannot enforce completely accurately, as long as 296 it adheres to "the guiding principle... that the server must not 297 accept ACLs that appear to make [a file] more secure than it really 298 is." 300 Mapping NFSv4 ACLs October 2004 302 It may therefore be possible for a server to accept a wider range of 303 NFSv4 ACLs, as long as it can ensure that in every case the resulting 304 POSIX ACL denies at least all access that the original NFSv4 ACL 305 denied. The results of such a mapping may, however, be somewhat 306 unexpected, and it is preferable simply to refuse all NFSv4 ACLs that 307 do not map accurately, and provide clients with software to help gen- 308 erate POSIX-mappable NFSv4 ACLs if necessary. 310 Similarly, a client that uses NFSv4 ACLS to implement user interfaces 311 that only deal in POSIX ACLs may handle user requests to set ACLs 312 easily enough, but should return errors when the user requests ACLs 313 that, on consulting the server, turn out to not be mappable to POSIX 314 ACLs. 316 Mapping NFSv4 ACLs October 2004 318 6. Security Considerations 320 Any automatic mapping from one ACL model to another must provide 321 guarantees that the mapping preserves semantics, or risk misleading 322 users about the permissions set on filesystem objects. For this rea- 323 son, we recommend performing such mapping only when it can be done 324 accurately, and returning errors in all other cases. 326 Mapping NFSv4 ACLs October 2004 328 7. Bibliography 330 [rfc3530] 331 Shepler, S. et. al., "NFS version 4 Protocol", April 2003. 333 http://www.ietf.org/rfc/rfc3530.txt 335 [posixacl] 336 IEEE, "IEEE Draft P1003.1e", October 1997 (last draft). 338 http://wt.xpilot.org/publications/posix.1e/download.html 340 Mapping NFSv4 ACLs October 2004 342 8. Author's Address 344 Address comments related to this memorandum to: 346 marius@umich.edu bfields@umich.edu 348 Marius Aamodt Eriksen 349 J. Bruce Fields 350 University of Michigan / CITI 351 535 West William 352 Ann Arbor, Michigan 354 E-mail: marius@umich.edu 355 E-mail: bfields@umich.edu 357 9. Copyright 359 Copyright (C) The Internet Society (2004). This document is subject 360 to the rights, licenses and restrictions contained in BCP 78, and 361 except as set forth therein, the authors retain all their rights. 363 This document and the information contained herein are provided on an 364 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 365 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 366 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 367 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 368 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 369 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.