idnits 2.17.1 draft-ietf-nfsv4-acl-mapping-03.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 (February 2005) is 7004 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. -------------------------------------------------------------------------------- 1 Network Working Group Marius Aamodt Eriksen 2 Internet Draft J. Bruce Fields 3 Document: draft-ietf-nfsv4-acl-mapping-03.txt February 2005 5 Mapping Between NFSv4 and Posix Draft ACLs 7 Status of this Memo 9 By submitting this Internet-Draft, I certify that any applicable 10 patent or other IPR claims of which I am aware have been disclosed, 11 or will be disclosed, and any of which I become aware will be dis- 12 closed, in accordance with RFC 3668. 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference mate- 25 rial or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 "Copyright (C) The Internet Society (2002-2004). All Rights 34 Reserved." 36 Abstract 38 NFS version 4 [rfc3530] (NFSv4) specifies a flavor of Access Control 39 Lists (ACLs) resembling Windows NT ACLs. A number of operating sys- 40 tems use a different flavor of ACL based on a withdrawn POSIX draft. 41 NFSv4 clients and servers on such operating systems may wish to map 43 Mapping NFSv4 ACLs February 2005 45 between NFSv4 ACLs and their native ACLs. To this end, we describe a 46 mapping from POSIX draft ACLs to a subset of NFSv4 ACLs. 48 Mapping NFSv4 ACLs February 2005 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. NFSv4 ACLs . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. POSIX ACLs . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Mapping POSIX ACLs to NFSv4 ACLs . . . . . . . . . . . . . . 6 56 5. Using the Mapping in NFSv4 Implementations . . . . . . . . . 9 57 6. Security Considerations . . . . . . . . . . . . . . . . . 11 58 7. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 12 59 8. Author's Address . . . . . . . . . . . . . . . . . . . . . 13 60 9. Copyright . . . . . . . . . . . . . . . . . . . . . . . . 13 62 Mapping NFSv4 ACLs February 2005 64 1. Introduction 66 Access Control Lists (ACLs) are used to specify fine-grained access 67 rights to file system objects. An ACL is a list of Access Control 68 Entries (ACEs), each specifying an entity (such as a user) and some 69 level of access for that entity. 71 In the following sections we describe two ACL models: NFSv4 ACLs, and 72 ACLs based on a withdrawn POSIX draft. We will refer to the latter 73 as "POSIX ACLs". Since NFSv4 ACLs are more fine-grained than POSIX 74 ACLs, it is not possible in general to map an arbitrary NFSv4 ACL to 75 a POSIX ACL with the same semantics. However, it is possible to map 76 any POSIX ACL to a NFSv4 ACL with nearly identical semantics. We 77 will describe such a mapping, and discuss its use in NFSv4 clients 78 and servers. 80 2. NFSv4 ACLs 82 An NFSv4 ACL is an ordered sequence of ACEs, each having an entity, a 83 type, some flags, and an access mask. 85 The entity may be the name of a user or group, or may be one of a 86 small set of special entities. Among the special entities are 87 "OWNER@" (the current owner of the file), "GROUP@" (the group associ- 88 ated with the file), and "EVERYONE@". 90 The type may be ALLOW or DENY. (AUDIT or ALARM are also allowed, but 91 they are not relevant to our discussion). 93 The access mask has 14 separate bits, including bits to control read, 94 write, execute, append, ACL modification, file owner modification, 95 etc.; consult [rfc3530] for the full list. 97 Of the flags, four are relevant here. The ACE4_IDENTIFIER_GROUP flag 98 is used to indicate that the entity name is the name of a group. The 99 other three concern inheritance: ACE4_DIRECTORY_INHERIT_ACE indicates 100 that the ACE should be added to new subdirectories of the directory; 101 ACE4_FILE_INHERIT_ACE does the same for new files; and 102 ACE4_INHERIT_ONLY indicates that the ACE should be ignored when 103 determining access to the directory itself. 105 The NFSv4 ACL permission-checking algorithm is straightforward. 106 Assume a a requester asks for access, as specified by a single bit in 108 Mapping NFSv4 ACLs February 2005 110 the access bitmask. We allow the access if the first ACE in the ACL 111 that matches the requester and that has that bit set is an ALLOW ACE, 112 and we deny the access if the first such ACE is a DENY ACE. If no 113 matching ACE has the bit in question set, behaviour is undefined. If 114 an access mask consisting of more than one bit is requested, it suc- 115 ceeds if and only if each bit in the mask is allowed. 117 We refer the reader to [rfc3530] for further details. 119 3. POSIX ACLs 121 A number of operating systems implement ACLs based on the withdrawn 122 POSIX 1003.1e/1003.2c Draft Standard 17 [posixacl]. We will refer to 123 such ACLs as "POSIX ACLs". 125 POSIX ACLs use access masks with only the traditional "read", 126 "write", and "execute" bits. Each ACE in a POSIX ACL is one of five 127 types: ACL_USER_OBJ, ACL_USER, ACL_GROUP_OBJ, ACL_GROUP, ACL_MASK, 128 and ACL_OTHER. Each ACL_USER ACE has a uid associated with it, and 129 each ACL_GROUP ACE has a gid associated with it. Every POSIX ACL 130 must have exactly one ACL_USER_OBJ, ACL_GROUP, and ACL_OTHER ACE, and 131 at most one ACL_MASK ACE. The ACL_MASK ACE is required if the ACL 132 has any ACL_USER or ACL_GROUP ACEs. There may not be two ACL_USER 133 ACEs with the same uid, and there may not be two ACL_GROUP ACEs with 134 the same gid. 136 Given a POSIX ACL and a requester asking for access, permission is 137 determined as follows: 139 1) If the requester is the file owner, then allow or deny access 140 depending on whether the ACL_USER_OBJ ACE allows or denies it. 141 Otherwise, 143 2) if the requester's uid matches the uid of one of the ACL_USER 144 ACEs, then allow or deny access depending on whether the 145 ACL_USER_OBJ ACE allows or denies it. Otherwise, 147 3) Consider the set of all ACL_GROUP ACEs whose gid the requester is 148 a member of. Add to that set the ACL_GROUP_OBJ ACE, if the 149 requester is also a member of the file's group. Allow access if 150 any ACE in the resulting set allows access. If the set of match- 151 ing ACEs is nonempty, and none allow access, then deny access. 152 Otherwise, if the set of matching ACEs is empty, 154 Mapping NFSv4 ACLs February 2005 156 4) if the requester's access mask is allowed by the ACL_OTHER ACE, 157 then grant access. Otherwise, deny access. 159 The above description omits one detail: in steps (2) and (3), the 160 requested bits must be granted both by the matching ACE and by the 161 ACL_MASK ACE. The ACL_MASK ACE thus limits the maximum permissions 162 which may be granted by any ACL_USER or ACL_GROUP ACE, or by the 163 ACL_GROUP_OBJ ACE. 165 Each file may have a single POSIX ACL associated with it, used to 166 determine access to that file. Directories, however, may have two 167 ACLs: one, the "access ACL", used to determine access to the direc- 168 tory, and one, the "default ACL", used only as the ACL to be inher- 169 ited by newly created objects in the directory. 171 4. Mapping POSIX ACLs to NFSv4 ACLs 173 We now describe an algorithm which maps any POSIX ACL to an NFSv4 ACL 174 with the same semantics. 176 First, translate the uid's and gid's on the ACL_USER and ACL_GROUP 177 ACEs into NFSv4 names. This is an implementation-dependent process. 178 It might be done, for example, by consulting a directory service or a 179 password file. Also, the special ACL_USER_OBJ, ACL_GROUP_OBJ, and 180 ACL_OTHER ACEs must be translated to NFSv4 ACEs with the special 181 entities "OWNER@", "GROUP@", and "EVERYONE@", respectively. 183 Next, map each POSIX ACE (excepting any mask ACE) in the given POSIX 184 ACL to an NFSv4 ALLOW ACE with an entity determined as above, and 185 with a bitmask determined from the permission bits on the POSIX ACE 186 as follows: 188 1) If the read bit is set in the POSIX ACE, then set ACE4_READ_DATA. 190 2) If the write bit is set in the POSIX ACE, then set ACE4_WRITE_DATA 191 and ACE4_APPEND_DATA. If the object carrying the ACL is a direc- 192 tory, set ACE4_DELETE_CHILD as well. 194 3) If the execute bit is set in the POSIX ACE, then set ACE4_EXECUTE. 196 4) Set ACE4_READ_ACL, ACE4_READ_ATTRIBUTES, and ACE4_SYNCHRONIZE 197 unconditionally. 199 5) If the ACE is for the special "OWNER@" entity, set ACE4_WRITE_ACL 200 and ACE4_WRITE_ATTRIBUTES. 202 Mapping NFSv4 ACLs February 2005 204 6) Clear all other bits in the NFSv4 bitmask. 206 In addition, we set the GROUP flag in each ACE which corresponds to a 207 named group (but not in the GROUP@ ACE, or any of the other special 208 entity ACEs). At this point, we've replaced the POSIX ACL by an 209 NFSv4 ACL with the same number of ACEs (ignoring any mask ACE). To 210 emulate the POSIX ACL permission-checking algorithm, we need to mod- 211 ify the ACL further, as follows: 213 1) Order the ACL so that the OWNER@ ACE is the first ACE of the ACL, 214 followed by any user ACEs, followed by the GROUP@ ACE, followed by 215 any group ACEs, and ending finally with the EVERYONE@ ACE. 217 2) The POSIX algorithm stops as soon as the requester matches an 218 ACL_USER_OBJ, ACL_OTHER, or ACL_USER ACE. To emulate this 219 behaviour, add a single DENY ACE after each ALLOW ACE for OWNER@, 220 EVERYONE@, or any named user. The DENY ACE should have the same 221 entity and flags as the corresponding ALLOW ACE. The bitmask on 222 the DENY ACE should be the bitwise NOT of the bitmask on the ALLOW 223 ACE, except that the ACE4_WRITE_OWNER and ACE4_DELETE bits should 224 be cleared, and the ACE4_DELETE_CHILD bit should be cleared on 225 non-directories. (Also, in the xdr-encoded ACL that is transmit- 226 ted, all bits not defined in the protocol should be cleared.) 228 3) Unlike the other ACEs in step 2, all of the ACL_GROUP_OBJ and 229 ACL_GROUP ACEs are consulted by the POSIX algorithm before deter- 230 mining permissions. However, if the requester matches any one of 231 them, then it must deny any permissions they do not allow. To 232 emulate this behaviour, instead of adding a single DENY after each 233 corresponding GROUP@ or named group ACE, we insert a list of DENY 234 ACEs at the end of the list of GROUP@ and named group ACEs. Each 235 DENY ACE is determined from its corresponding ALLOW ACE exactly as 236 in step 2, and should occur in the inserted list in the same posi- 237 tion as the corresponding ALLOW ACE occurs in the list of ALLOW 238 ACEs. 240 4) Finally, we enforce the POSIX mask ACE by prepending each ALLOW 241 ACE for a named user, GROUP@, or named group, with a single DENY 242 ACE whose entity and flags are the same as those for the corre- 243 sponding ALLOW ACE, but whose bitmask is the inverse of the bit- 244 mask determined from the mask ACE, with the inverse calculated as 245 described in step 2. 247 As an example, take a POSIX ACL with two named users (u1 and u2) and 248 two named groups (g1 and g2), in addition to the required 249 ACL_USER_OBJ, ACL_GROUP_OBJ, ACL_OTHER, and ACL_MASK ACEs. 251 Such an ACL will map to an NFSv4 ACL of the form 253 Mapping NFSv4 ACLs February 2005 255 ALLOW OWNER@ 256 DENY OWNER@ 257 DENY u1 (mask) 258 ALLOW u1 259 DENY u1 260 DENY u2 (mask) 261 ALLOW u2 262 DENY u2 263 DENY GROUP@ (mask) 264 ALLOW GROUP@ 265 DENY g1 (mask) 266 ALLOW g1 267 DENY g2 (mask) 268 ALLOW g2 269 DENY GROUP@ 270 DENY g1 271 DENY g2 272 ALLOW EVERYONE@ 273 DENY EVERYONE@ 275 where the ACEs marked with (mask) are those whose bitmask are deter- 276 mined from the ACL_MASK ACE as described in step 4 above. 278 In general, a POSIX ACL with m named users and n named groups will 279 map to an NFSv4 ACL with (3*(m + n) + 7) ACLs, unless m and n are 280 both zero, in which case the result will have either 6 or 7 ACLs, 281 depending on whether the original ACL had an ACL_MASK ACE. 283 On directories with default ACLs, we translate the default ACL as 284 above, but set the ACE4_INHERIT_ONLY_ACE, ACE4_DIRECTORY_INHERIT_ACE, 285 and ACE4_FILE_INHERIT_ACE flags on every ACE in the resulting ACL. 286 On directories with both default and access ACLs, we translate the 287 two ACLs and then concatenate them. The order of the concatenation 288 is unimportant. 290 There is one extremely minor inaccuracy in this mapping: if a 291 requester that is a member of more than one group listed in the ACL 292 requests multiple bits simultaneously, the POSIX algorithm requires 293 all of the bits to be granted simultaneously by one of the group 294 ACEs. Thus a POSIX ACL such as 296 ACL_USER_OBJ: --- 297 ACL_GROUP_OBJ: --- 298 g1: r-- 299 g2: -w- 300 ACL_MASK: rw- 301 ACL_OTHER: --- 303 Mapping NFSv4 ACLs February 2005 305 will prevent a user that is a member of groups g1 and g2 from opening 306 a file for both read and write, even though read and write would be 307 individually permitted. 309 The NFSv4 ACL permission-checking algorithm has the property that it 310 permits a group of bits whenever it would permit each bit individu- 311 ally, so it is impossible to mimic this behaviour with an NFSv4 ACL. 313 5. Using the Mapping in NFSv4 Implementations 315 Examination of the algorithm described in the previous section shows 316 that no information is lost; the original POSIX ACL can be recon- 317 structed from the mapped NFSv4 ACL. Thus we also have a way to map 318 NFSv4 ACLs to POSIX ACLs in the case where the NFSv4 ACL is precisely 319 in the format of an ACL produced by the algorithm above. 321 The algorithm can therefore be used to implement a subset of the 322 NFSv4 ACL model. This may be useful to NFSv4 clients and servers 323 with preexisting system interfaces that support POSIX ACLs and that 324 cannot be modified to support NFSv4 ACLs. 326 A server, for example, that wishes to export via NFSv4 a filesystem 327 that supports only POSIX ACLs, may use this mapping to answer client 328 requests for existing ACLs by translating POSIX ACLs on its filesys- 329 tem to NFSv4 ACLs to send to the client. However, when a client 330 attempts to set an ACL, the server faces a problem. If the given ACL 331 is not in precisely the format of an ACL produced by this mapping, 332 then the server may be required to return an error to avoid inaccu- 333 rately representing the client's intention. The correct error to 334 return in this case is NFS4ERR_ATTRNOTSUPP. 336 In the case where a client sets an ACL that leaves certain bits nei- 337 ther allowed nor denied, the server may choose to allow or deny those 338 bits as necessary to make mapping possible. In some situations it 339 may also be possible for a server to map the ACL if it adds a DENY 340 ACE or denies a few additional bits. The language of [rfc3530] 341 allows a server some flexibility in handling ACLs that it cannot 342 enforce completely accurately, as long as it adheres to "the guiding 343 principle... that the server must not accept ACLs that appear to make 344 [a file] more secure than it really is." 346 Given the choice, as long as the "guiding principle" is not violated, 347 servers should opt to be forgiving. The complexity of the 348 POSIX<->NFSv4 mapping makes difficult the task of generating ACLs 350 Mapping NFSv4 ACLs February 2005 352 that will satisfy a server using the mapping. By making the mapping 353 more forgiving, the server can simplify that task, improving interop- 354 erability. 356 Servers that implement the full NFSv4 protocol should also handle 357 carefully ACLs that leave bits neither allowed nor denied. It is 358 better to fall back on some reasonable default rather than to always 359 allow or always deny. A client that, for example, sets 360 ACE4_WRITE_DATA but leaves unspecified ACE4_APPEND_DATA probably does 361 so because its system interfaces are incapable of independently rep- 362 resenting ACE4_APPEND_DATA, not because it intends to deny 363 ACE4_APPEND_DATA. By leaving the bit unspecified, the client leaves 364 the server the opportunity to provide the reasonable default of set- 365 ting it to match ACE4_WRITE_DATA. 367 Similar issues exist when a client uses NFSv4 ACLs to implement user 368 interfaces that only deal in POSIX ACLs. When the client translates 369 ACLs received from the server to POSIX ACLs, some flexibility may 370 help interopability, but the client must take care not to represent 371 any ACLs as stricter than they really are. Clients that provide 372 access to the full set of NFSv4 ACLs may also wish to provide users 373 with utilities to generate and interpret POSIX-mapped NFSv4 ACLs, to 374 aid users working with servers using the POSIX mapping. 376 Mapping NFSv4 ACLs February 2005 378 6. Security Considerations 380 Any automatic mapping from one ACL model to another must provide 381 guarantees as to how the mapping affects the meaning of ACLs, or risk 382 misleading users about the permissions set on filesystem objects. 383 For this reason, caution is recommended when implementing this map- 384 ping. It is better to return errors than to break any such guaran- 385 tees. 387 Note also that this ACL mapping requires mapping between NFSv4 user- 388 names and local id's. When the mapping of id's depends on remote 389 services, the method used for the mapping must be at least as secure 390 as the method used to set or get ACLs. 392 Mapping NFSv4 ACLs February 2005 394 7. Bibliography 396 [rfc3530] 397 Shepler, S. et. al., "NFS version 4 Protocol", April 2003. 399 http://www.ietf.org/rfc/rfc3530.txt 401 [posixacl] 402 IEEE, "IEEE Draft P1003.1e", October 1997 (last draft). 404 http://wt.xpilot.org/publications/posix.1e/download.html 406 Mapping NFSv4 ACLs February 2005 408 8. Author's Address 410 Address comments related to this memorandum to: 412 marius@umich.edu bfields@umich.edu 414 Marius Aamodt Eriksen 415 J. Bruce Fields 416 University of Michigan / CITI 417 535 West William 418 Ann Arbor, Michigan 420 E-mail: marius@umich.edu 421 E-mail: bfields@umich.edu 423 9. Copyright 425 Copyright (C) The Internet Society (2004). This document is subject 426 to the rights, licenses and restrictions contained in BCP 78, and 427 except as set forth therein, the authors retain all their rights. 429 This document and the information contained herein are provided on an 430 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 431 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 432 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 433 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 434 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 435 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.