idnits 2.17.1 draft-ietf-nfsv4-acl-mapping-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 542. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (May 15, 2006) is 6557 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) ** Obsolete normative reference: RFC 3530 (ref. '1') (Obsoleted by RFC 7530) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Eriksen 3 Internet-Draft J. Fields 4 Expires: November 16, 2006 CITI 5 May 15, 2006 7 Mapping Between NFSv4 and Posix Draft ACLs 8 draft-ietf-nfsv4-acl-mapping-04 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 25 material 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 This Internet-Draft will expire on November 16, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 A number of filesystems and applications support ACLs based on a 42 withdrawn POSIX draft [2]. Those ACLs differ significantly from NFS 43 version 4 (NFSv4) ACLs [1]. We describe how to translate between the 44 two types of ACLs. 46 1. Introduction 48 Access Control Lists (ACLs) are used to specify fine-grained access 49 rights to file system objects. An ACL is a list of Access Control 50 Entries (ACEs), each specifying an entity (such as a user) and some 51 level of access for that entity. 53 In the following sections we describe two ACL models: NFSv4 ACLs, and 54 ACLs based on a withdrawn POSIX draft. We will refer to the latter 55 as "POSIX ACLs". Since NFSv4 ACLs are more fine-grained than POSIX 56 ACLs, it is not possible in general to map an arbitrary NFSv4 ACL to 57 a POSIX ACL with the same semantics. However, it is possible to map 58 any POSIX ACL to a NFSv4 ACL with nearly identical semantics, and it 59 is possible to map any NFSv4 ACL to a POSIX ACL in a way that 60 preserves certain guarantees. We will explain how to do this, and 61 give guidelines for clients and servers performing such translation. 63 2. NFSv4 ACLs 65 An NFSv4 ACL is an ordered sequence of ACEs, each having an entity, a 66 type, some flags, and an access mask. 68 The entity may be the name of a user or group, or may be one of a 69 small set of special entities. Among the special entities are 70 "OWNER@" (the current owner of the file), "GROUP@" (the group 71 associated with the file), and "EVERYONE@". 73 The type may be ALLOW or DENY. (AUDIT or ALARM are also allowed, but 74 they are not relevant to our discussion). 76 The access mask has 14 separate bits, including bits to control read, 77 write, execute, append, ACL modification, file owner modification, 78 etc.; consult [1] for the full list. 80 Of the flags, four are relevant here. The ACE4_IDENTIFIER_GROUP flag 81 is used to indicate that the entity name is the name of a group. The 82 other three concern inheritance: ACE4_DIRECTORY_INHERIT_ACE indicates 83 that the ACE should be added to new subdirectories of the directory; 84 ACE4_FILE_INHERIT_ACE does the same for new files; and 85 ACE4_INHERIT_ONLY indicates that the ACE should be ignored when 86 determining access to the directory itself. 88 The NFSv4 ACL permission-checking algorithm is straightforward. 89 Assume a a requester asks for access, as specified by a single bit in 90 the access bitmask. We allow the access if the first ACE in the ACL 91 that matches the requester and that has that bit set is an ALLOW ACE, 92 and we deny the access if the first such ACE is a DENY ACE. If no 93 matching ACE has the bit in question set, behaviour is undefined. If 94 an access mask consisting of more than one bit is requested, it 95 succeeds if and only if each bit in the mask is allowed. 97 We refer the reader to [1] for further details. 99 3. POSIX ACLs 101 A number of operating systems implement ACLs based on the withdrawn 102 POSIX 1003.1e/1003.2c Draft Standard 17 [2]. We will refer to such 103 ACLs as "POSIX ACLs". 105 POSIX ACLs use access masks with only the traditional "read", 106 "write", and "execute" bits. Each ACE in a POSIX ACL is one of five 107 types: ACL_USER_OBJ, ACL_USER, ACL_GROUP_OBJ, ACL_GROUP, ACL_MASK, 108 and ACL_OTHER. Each ACL_USER ACE has a uid associated with it, and 109 each ACL_GROUP ACE has a gid associated with it. Every POSIX ACL 110 must have exactly one ACL_USER_OBJ, ACL_GROUP_OBJ, and ACL_OTHER ACE, 111 and at most one ACL_MASK ACE. The ACL_MASK ACE is required if the 112 ACL has any ACL_USER or ACL_GROUP ACEs. There may not be two 113 ACL_USER ACEs with the same uid, and there may not be two ACL_GROUP 114 ACEs with the same gid. 116 Given a POSIX ACL and a requester asking for access, permission is 117 determined as follows: 119 1. If the requester is the file owner, then allow or deny access 120 depending on whether the ACL_USER_OBJ ACE allows or denies it. 121 Otherwise, 123 2. if the requester's uid matches the uid of one of the ACL_USER 124 ACEs, then allow or deny access depending on whether the 125 ACL_USER_OBJ ACE allows or denies it. Otherwise, 127 3. Consider the set of all ACL_GROUP ACEs whose gid the requester is 128 a member of. Add to that set the ACL_GROUP_OBJ ACE, if the 129 requester is also a member of the file's group. Allow access if 130 any ACE in the resulting set allows access. If the set of 131 matching ACEs is nonempty, and none allow access, then deny 132 access. Otherwise, if the set of matching ACEs is empty, 134 4. if the requester's access mask is allowed by the ACL_OTHER ACE, 135 then grant access. Otherwise, deny access. 137 The above description omits one detail: in steps (2) and (3), the 138 requested bits must be granted both by the matching ACE and by the 139 ACL_MASK ACE. The ACL_MASK ACE thus limits the maximum permissions 140 which may be granted by any ACL_USER or ACL_GROUP ACE, or by the 141 ACL_GROUP_OBJ ACE. 143 Each file may have a single POSIX ACL associated with it, used to 144 determine access to that file. Directories, however, may have two 145 ACLs: one, the "access ACL", used to determine access to the 146 directory, and one, the "default ACL", used only as the ACL to be 147 inherited by newly created objects in the directory. 149 4. Ordering of NFSv4 and POSIX ACLs 151 POSIX ACLs are unordered--the order in which the POSIX access- 152 checking algorithm considers the entries is determined entirely by 153 the type of the entries, so the entries don't need to be kept in any 154 particular order. 156 By contrast, the meaning of an NFSv4 ACL can be dramatically changed 157 by modifying the order that the entries are listed in. 159 In the following, we will say that an NFSv4 ACL is in the "canonical 160 order" if its entries are ordered in the order that the POSIX 161 algorithm would consider them. That is, with all OWNER@ entries 162 first, followed by user entries, followed by GROUP@ entries, followed 163 by group entries, with all EVERYONE@ entries at the end. 165 5. A Minor Eccentrity of POSIX ACLs 167 We will see below that it is possible to find an NFSv4 ACL with 168 precisely the same effect as any given POSIX ACL, with one extremely 169 minor exception: if a requester that is a member of more than one 170 group listed in the ACL requests multiple bits simultaneously, the 171 POSIX algorithm requires all of the bits to be granted simultaneously 172 by one of the group ACEs. Thus a POSIX ACL such as 174 ACL_USER_OBJ: --- 175 ACL_GROUP_OBJ: --- 176 g1: r-- 177 g2: -w- 178 ACL_MASK: rw- 179 ACL_OTHER: --- 181 will prevent a user that is a member of groups g1 and g2 from opening 182 a file for both read and write, even though read and write would be 183 individually permitted. 185 The NFSv4 ACL permission-checking algorithm has the property that it 186 permits a group of bits whenever it would permit each bit 187 individually, so it is impossible to mimic this behaviour with an 188 NFSv4 ACL. 190 6. Mapping POSIX ACLs to NFSv4 ACLs 192 6.1. Requirements 194 In the next section we give an example of a mapping of POSIX ACLs 195 into NFSv4 ACLs. We permit a server or client to use a different 196 mapping, provided the mapping meets the following requirements: 198 It must map the POSIX ACL to an NFSv4 ACL with identical access 199 semantics, ignoring the minor exception described in the previous 200 section. 202 It must map the read mode bit to ACE4_READ_DATA, the write bit to 203 ACE4_WRITE_DATA and ACE4_APPEND_DATA (and ACE4_DELETE_CHILD for 204 directories), and the EXECUTE bit to ACE4_EXECUTE. It should also 205 allow ACE4_READ_ACL, ACE4_READ_ATTRIBUTES, and ACE4_SYNCHRONIZE 206 unconditionally, and allow ACE4_WRITE_ACL and ACE4_WRITE_ATTRIBUTES 207 to the owner. The handling of other NFSv4 mode bits may depend on 208 the implementation, but it is preferable to leave them unused. 210 It should avoid using DENY ACEs. If DENY ACEs are required, it 211 should attempt to place them at the beginning. (This is not always 212 possible.) 214 For simplicity's sake, the translator may choose to handle the mask 215 by first applying it to the USER, GROUP, and GROUP_OBJ ACEs, and then 216 mapping the resulting ACL. However, that will result in an ACL from 217 which it is impossible to determine the original value of the mask or 218 of the masked USER, GROUP, and GROUP_OBJ bitmasks. If the resulting 219 ACL is later translated back to a POSIX ACL, the translator will 220 assume that the value of the mask is the union of the bitmasks 221 permitted to any USER, GROUP, or GROUP_OBJ. If that would be 222 incorrect, the original translation should not modify the bitmasks of 223 the USER, GROUP, and GROUP_OBJ bitmasks, and should instead use 224 additional DENY ACEs as necessary to give the effect of the mask. It 225 should also arrange for the first GROUP@ ACE to be a DENY ACE whose 226 bitmask is determined by the mask, allowing that ACE to be used to 227 determine the original mask value. 229 6.2. Example POSIX->NFSv4 Mapping 231 We now describe an algorithm which maps any POSIX ACL to an NFSv4 ACL 232 with the same semantics, meeting the above requirements. 234 First, translate the uid's and gid's on the ACL_USER and ACL_GROUP 235 ACEs into NFSv4 names, using directory services, etc., as 236 appropriate, and translate ACL_USER_OBJ, ACL_GROUP_OBJ, and ACL_OTHER 237 to the special NFSv4 names "OWNER@", "GROUP@", and "EVERYONE@", 238 respectively. 240 Next, map each POSIX ACE (excepting any mask ACE) in the given POSIX 241 ACL to an NFSv4 ALLOW ACE with an entity determined as above, and 242 with a bitmask determined from the permission bits on the POSIX ACE 243 as follows: 245 1. If the read bit is set in the POSIX ACE, then set ACE4_READ_DATA. 247 2. If the write bit is set in the POSIX ACE, then set 248 ACE4_WRITE_DATA and ACE4_APPEND_DATA. If the object carrying the 249 ACL is a directory, set ACE4_DELETE_CHILD as well. 251 3. If the execute bit is set in the POSIX ACE, then set 252 ACE4_EXECUTE. 254 4. Set ACE4_READ_ACL, ACE4_READ_ATTRIBUTES, and ACE4_SYNCHRONIZE 255 unconditionally. 257 5. If the ACE is for the special "OWNER@" entity, set ACE4_WRITE_ACL 258 and ACE4_WRITE_ATTRIBUTES. 260 6. Clear all other bits in the NFSv4 bitmask. 262 In addition, we set the GROUP flag in each ACE which corresponds to a 263 named group (but not in the GROUP@ ACE, or any of the other special 264 entity ACEs). 266 At this point, we've replaced the POSIX ACL by an NFSv4 ACL with the 267 same number of ACEs (ignoring any mask ACE), all of them ALLOW ACEs. 269 Order this NFSv4 ACL in the canonical order: OWNER@, users, GROUP@, 270 groups, then EVERYONE@. 272 If the bitmasks in the resulting ACEs are non-increasing (so no ACE 273 allows a bit not allowed by a previous ACE), then we can skip the 274 next step. 276 Otherwise, we need to insert additional DENY ACE's to emulate the 277 first-match semantics of the POSIX ACL permission-checking algorithm: 279 1. If an ACL_USER_OBJ, ACL_OTHER, or ACL_USER ACE fails to grant 280 some permissions that are granted later in the ACL, then that ACE 281 must be prepended by a single DENY ACE. The DENY ACE should have 282 the same entity and flags as the corresponding ALLOW ACE, but the 283 bitmask on the DENY ACE should be the bitwise NOT of the bitmask 284 on the ALLOW ACE, except that the ACE4_WRITE_OWNER, ACE4_DELETE, 285 ACE4_READ_NAMED_ATTRIBUTES, ACE4_WRITE_NAMED_ATTRIBUTES bits 286 should be cleared, and the ACE4_DELETE_CHILD bit should be 287 cleared on non-directories. (Also, in the xdr-encoded ACL that 288 is transmitted, all bits not defined in the protocol should be 289 cleared.) 291 2. All of the ACL_GROUP_OBJ and ACL_GROUP ACEs are consulted by the 292 POSIX algorithm before determining permissions. To emulate this 293 behaviour, instead of adding a single DENY before corresponding 294 GROUP@ or named group ACEs, we insert a list of DENY ACEs after 295 the list of GROUP@ and named group ACEs. Each DENY ACE is 296 determined from its corresponding ALLOW ACE exactly as in the 297 previous step. As before, these DENY aces should only be added 298 when they are necessitated by an ACE that is less permissive than 299 the final EVERYONE@ ace. 301 Finally, we enforce the POSIX mask ACE by prepending each ALLOW ACE 302 for a named user, GROUP@, or named group, with a single DENY ACE 303 whose entity and flags are the same as those for the corresponding 304 ALLOW ACE, but whose bitmask is the inverse of the bitmask determined 305 from the mask ACE, with the inverse calculated as described above. 306 In the case of named users, these DENY aces may be coalesced with any 307 existing prepended DENY aces. The DENY aces are omitted entirely if 308 they would have no affect, or if the mask ACE has the same bitmask as 309 the maximum of the affected ACEs. (With the one exception that if 310 the POSIX ACL posesses exactly 4 ACEs, then a mask-derived DENY ace 311 should be inserted before the GROUP@ ace, even if it would not 312 otherwise be.) 314 Regardless of what scheme is used to represent the mask, the receiver 315 will use the first GROUP@ DENY ace to determine the value of the mask 316 (if it is different from the union of the bitmasks on the affected 317 ACEs), and use the relevant ALLOWs to determine the pre-mask values 318 of user and group ACEs. 320 The implementation may also choose to just mask out the bitmasks on 321 the relevant ALLOW ACEs. This will produce a simpler ACL (in 322 particular, an ACL that usually requires no DENY ACE's), at the 323 expense of losing some ACL information after a chmod. 325 On directories with default ACLs, we translate the default ACL as 326 above, but set the ACE4_INHERIT_ONLY_ACE, ACE4_DIRECTORY_INHERIT_ACE, 327 and ACE4_FILE_INHERIT_ACE flags on every ACE in the resulting ACL. 328 On directories with both default and access ACLs, we translate the 329 two ACLs and then concatenate them. The order of the concatenation 330 is unimportant. 332 7. Mapping NFSv4 ACLs to POSIX ACLs 334 7.1. Requirements 336 Any mapping of NFSv4 ACLs to POSIX ACLs must map any NFSv4 ACL that 337 is semantically equivalent to a POSIX ACL (with the exception of the 338 "minor inaccuracy" mentioned above) to the equivalent POSIX ACL. It 339 should also extract the mask correctly; as the mask doesn't affect 340 the semantics of the NFSv4 ACL, and as there is more than one way the 341 mask might be encoded, we require a convention for this. 342 Specifically: we require that the mask be computed as the bitmask 343 used on the first GROUP@ DENY ACE which precedes any GROUP@ allow 344 ACE, unless no such DENY ACE exists, in which case the mask must be 345 computed as the union of the bitmasks allowed to all named users, 346 groups, and GROUP@ (where by the "bitmask allowed to" an entity we 347 mean the maximum bitmask that the ACL would permit to any user 348 matching the entity). 350 Implementations may vary in how they deal with NFSv4 ACLs that are 351 not precisely semantically equivalent to any POSIX ACL. In 352 particular they may return errors for such ACLs instead of attempting 353 to map them. However, when possible without compromising security, 354 they should attempt to be forgiving. 356 The language of [1] allows a server some flexibility in handling ACLs 357 that it cannot enforce completely accurately, as long as it adheres 358 to "the guiding principle... that the server must not accept ACLs 359 that appear to make [a file] more secure than it really is." 361 Note that an NFSv4 ACL consisting entirely of ALLOW ACLs can always 362 be transformed into a POSIX-equivalent ACL by first sorting it into 363 the canonical order, and then inserting DENY ACEs as necessary to 364 ensure POSIX first-match semantics. Since inserting DENY ACEs can 365 only restrict access, it is safe for a server to do this. 367 We require any server to accept, at least, any NFSv4 ACL that 368 consists entirely of ALLOW ACLs. 370 Clients should also be at least as forgiving, to promote 371 interoperability when heterogeneous clients share files. 373 7.2. Example NFSv4->POSIX Mapping 375 We now give an example of an algorithm that meets the above 376 requirements. We assume it is to be used by a server mapping client- 377 provided NFSv4 ACLs to POSIX ACLs it can store in its filesystem, so 378 the translation errs on the side of making the ACL less permissive. 380 Given an NFSv4 ACL, first calculate the mask by taking the bitmask 381 from the first GROUP@ DENY ACE from the original NFSv4 ACL, if it 382 exists. After doing so, remove that DENY ACE, and clear the bits in 383 its bitmask from any DENY ACE for a named user, group, or GROUP@ 384 which precedes an ALLOW ACE for the same entity. 386 In the case where there is no such GROUP@ DENY ACE, continue through 387 the rest of the algorithm and then calculate the mask as the union of 388 the calculated permissions of all named users, group, and the 389 GROUP_OBJ ACE. 391 Given an NFSv4 ACL, sort it into canonical order (OWNER@ ACEs first, 392 then user ACEs, then GROUP@ ACEs, then group ACEs, then EVERYONE@ 393 ACEs.) Also, sort the GROUP@ and group ACEs that all ALLOW ACEs 394 precede all DENY ACEs. To do so, take advantage of the following 395 observations: 397 1. If two consecutive ACEs are either both ALLOW ACEs, or both DENY 398 ACEs, then we can swap their order without changing the effect of 399 the ACL. 401 2. If it would be impossible for a single user to match both of the 402 entities on two consecutive ACEs, then we can swap their order 403 without changing the effect of the ACL. 405 3. If an ALLOW ACE is immediately followed by a DENY ACE, then 406 swapping the order of the two ACEs will not make the ACL any more 407 permissive. 409 4. If a DENY ACE is immediately followed by an ALLOW ACE, then 410 swapping the order of the two ACEs will not make the ACL any more 411 permissive, *if* we modify the bitmask on the ALLOW ACE by 412 clearing any bits that are set in the DENY ACE. 414 The second observation is the trickiest: it may usually be safe to 415 assume that two distinct user names cannot match the same user. An 416 implementation with knowledge about group memberships or about the 417 current value of the file owner might also use that information, but 418 if it does so it will produce a translation that is no longer 419 accurate after owners or group memberships change. 421 Fortunately, observations 1, 3, and 4 are sufficient to sort any ACL 422 into canonical order, so a paranoid implementation can simply ignore 423 number 2 completely, while an implementation willing to sacrifice 424 some accuracy may choose to do something more complex. 426 Ensure that the resulting ACL posesses at least one each of OWNER@, 427 GROUP@, and EVERYONE@ ACEs, by inserting an ALLOW ACE with a zero 428 bitmask if necessary in the correct position. 430 Next, for each entity, calculate a bitmask for that entity as 431 follows: Starting with the first ACE for that entity (ignoring all 432 previous ACEs), perform the NFSv4 ACL-checking algorithm for a user 433 that is assumed to match the entity on every DENY ACE that a user 434 matching the given entity might match, but is assumed to match only 435 those entities on ALLOW ACEs that *any* user matching the current 436 entity must match. 438 Finally, construct the POSIX ACL by translating NFSv4 entity names to 439 uid's and gid's (and handling special entities in the obvious way), 440 then assign a POSIX bitmask determined by the NFSv4 bitmask 441 calculated in the previous step; the bitmask calculation should use 442 the inverse of the mapping described previously in the POSIX-to-NFSv4 443 mapping, erring on the side of denying bits if it cannot determine a 444 sensible mapping. However, if certain bits simply cannot be mapped 445 in a reasonable way to mode bits, the server may simply ignore them 446 rather than returning an error. (For example, the server should deny 447 write if either ACE4_WRITE_DATA or ACE4_APPEND_DATA are denied. But 448 it may choose to ignore ACE4_READ_ATTRIBUTES entirely.) 450 The resulting mapping errs on the side of creating a more restrictive 451 ACE. However it can be modified to produce a mapping that errs on 452 the side of permissiveness, for the purposes of translating a server- 453 provided NFSv4 ACL to a POSIX ACL to present to a user or 454 application, as follows: 456 1. When sorting ACEs, ALLOW ACEs can always be moved towards the 457 start of the ACL, but a DENY ACE can be moved towards the start 458 of the ACL only as long as we clear any of the DENY ACE's bitmask 459 bits that are set in the intervening ALLOW ACEs. 461 2. When calculating the NFSv4 bitmask for each entity, err on the 462 side of assuming that ALLOW ACEs apply and that DENY ACEs don't, 463 with the one exception that when calculating the GROUP@ and named 464 group bitmasks, ALLOW ACEs for groups other than the one under 465 consideration should be ignored. 467 3. When mapping the NFSv4 bitmask to POSIX mode bits, err on the 468 side of allowing access. 470 8. Security Considerations 472 Any automatic mapping from one ACL model to another must provide 473 guarantees as to how the mapping affects the meaning of ACLs, or risk 474 misleading users about the permissions set on filesystem objects. 475 For this reason, caution is recommended when implementing this 476 mapping. It is better to return errors than to break any such 477 guarantees. 479 That said, there may be cases where small losses in accuracy can 480 avoid dramatic interoperability and usability problems; as long as 481 the losses in accuracy are clearly documented, these tradeoffs may be 482 found acceptable. 484 For example, a server unable to support all of the NFSv4 mode bits 485 does not have a way to communicate its exact limitations to clients, 486 so clients (and users) may be unable to recover from such errors. 487 For this reason we recommend ignoring bitmask bits that the server is 488 completely unable to map to mode bits, and advertising this fact 489 loudly in the server documentation. If this is considered 490 insufficient, we should add to the NFSv4 protocol additional 491 attributes necessary to advertise the server's limitations. 493 Note also that this ACL mapping requires mapping between NFSv4 494 usernames and local id's. When the mapping of id's depends on remote 495 services, the method used for the mapping must be at least as secure 496 as the method used to set or get ACLs. 498 9. References 500 [1] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, 501 C., Eisler, M., and D. Noveck, "Network File System (NFS) 502 version 4 Protocol", RFC 3530, April 2003. 504 [2] Institute of Electrical and Electronics Engineers, Inc., "IEEE 505 Draft P1003.1e", October 1997, 506 . 508 Authors' Addresses 510 Marius Aamodt Eriksen 511 U. of Michigan Center for Information Technology Integration 513 Email: marius@citi.umich.edu 515 J. Bruce Fields 516 U. of Michigan Center for Information Technology Integration 518 Email: marius@citi.umich.edu 520 Intellectual Property Statement 522 The IETF takes no position regarding the validity or scope of any 523 Intellectual Property Rights or other rights that might be claimed to 524 pertain to the implementation or use of the technology described in 525 this document or the extent to which any license under such rights 526 might or might not be available; nor does it represent that it has 527 made any independent effort to identify any such rights. Information 528 on the procedures with respect to rights in RFC documents can be 529 found in BCP 78 and BCP 79. 531 Copies of IPR disclosures made to the IETF Secretariat and any 532 assurances of licenses to be made available, or the result of an 533 attempt made to obtain a general license or permission for the use of 534 such proprietary rights by implementers or users of this 535 specification can be obtained from the IETF on-line IPR repository at 536 http://www.ietf.org/ipr. 538 The IETF invites any interested party to bring to its attention any 539 copyrights, patents or patent applications, or other proprietary 540 rights that may cover technology that may be required to implement 541 this standard. Please address the information to the IETF at 542 ietf-ipr@ietf.org. 544 Disclaimer of Validity 546 This document and the information contained herein are provided on an 547 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 548 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 549 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 550 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 551 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 552 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 554 Copyright Statement 556 Copyright (C) The Internet Society (2006). This document is subject 557 to the rights, licenses and restrictions contained in BCP 78, and 558 except as set forth therein, the authors retain all their rights. 560 Acknowledgment 562 Funding for the RFC Editor function is currently provided by the 563 Internet Society.