idnits 2.17.1 draft-ietf-nfsv4-acl-mapping-01.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 Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** There are 2 instances of too long lines in the document, the longest one being 22 characters in excess of 72. ** There are 23 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 2004) is 7375 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: 9 errors (**), 0 flaws (~~), 1 warning (==), 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 February 2004 4 Document: draft-ietf-nfsv4-acl-mapping-01.txt 6 Mapping Between NFSv4 and Posix Draft ACLs 8 SSttaattuuss ooff tthhiiss MMeemmoo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference mate- 21 rial or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 "Copyright (C) The Internet Society (2002-2004). All Rights 30 Reserved." 32 AAbbssttrraacctt 34 The NFS (Network File System) version 4[rfc3010bis] (NFSv4) specifies 35 a flavor of Access Control Lists (ACLs) that resembles that of Win- 36 dows NT's. ACLs are used to specify fine grained control of access 37 to file system objects. An ACL consists of a number of Access Con- 38 trol Entries (ACEs), each specify some level of access for an entity; 39 an entity can be a a user, group or a special entity. The access 40 level is described using an access mask, which is a bitmask where 41 each bit describes a level of access, for example read, write and 42 execute permissions on the file system object. 44 Mapping NFSv4 ACLs February 2004 46 TTaabbllee ooff CCoonntteennttss 48 11.. IInnttrroodduuccttiioonn . . . . . . . . . . 3 49 22.. NNFFSSvv44 AACCLLss . . . . . . . . . . . . . . 3 50 33.. PPOOSSIIXX AACCLLss . . . . . . . . . . . . . . 4 51 44.. MMaappppiinngg PPoossiixx AACCLLss 52 ttoo NNFFSSvv44 AACCLLss . . . . . . . . . . 5 53 55.. SSeeccuurriittyy 54 CCoonnssiiddeerraattiioonnss . . . . . . . 7 55 66.. BBiibblliiooggrraapphhyy . . . . . . . . . . 8 56 77.. AAcckknnoowwlleeddggmmeennttss . . . . . 9 57 88.. AAuutthhoorr''ss AAddddrreessss . . . . 10 58 99.. CCooppyyrriigghhtt . . . . . . . . . . . . . 10 60 Mapping NFSv4 ACLs February 2004 62 11.. IInnttrroodduuccttiioonn 64 The NFS (Network File System) version 4 [rfc3010bis] (NFSv4) speci- 65 fies a flavor of Access Control Lists (ACLs) that resembles that of 66 Windows NT's. ACLs are used to specify fine grained control of 67 access to file system objects. An ACL consists of a number of Access 68 Control Entries (ACEs), each specifying some level of access for an 69 entity; an entity can be a a user, group or a special entity. The 70 access level is described using an access mask, which is a bitmask 71 where each bit describes a level of access, for example read, write 72 and execute permissions on the file system object. 74 22.. NNFFSSvv44 AACCLLss 76 NFSv4 ACLs are rich in nature and expand upon the traditional idea of 77 ACLs. An NFSv4 ACE can be of type ALLOW, DENY, LOG or ALARM; each 78 specifies a different action to take should the ACE match a current 79 request. NFSv4 ACLs also have a rich set of access types that com- 80 plements the traditional types. These include appending data to the 81 file object, deleting children of the file object, deleting the file 82 object, etc [rfc3010bis]. 84 NFSv4 ACLs are interpreted in a straightforward manner. 86 1) Walk through the list of ACEs from the ACL in order 88 2) If the "who" (entity) field in the ACE does not match that of the 89 requester, the particular ACE is not processed. 91 3) Process all ACEs until all the bits in the requested access mask 92 have been ALLOWed; once a particular bit has been ALLOWed by an 93 ACE, it is no longer considered in further processing. 95 4) If a particular access is DENYed (while that bit is still under 96 consideration), the request is denied. 98 5) If all bits have been ALLOWed, the access is granted, or else 99 behavior is undefined. 101 NFSv4 ACLs also specify a number of special entities such as OWNER, 102 GROUP, and EVERYONE. These refer to the traditional UNIX mode bits. 103 Others include DIALUP, BATCH, and AUTHENTICATED, which have special- 104 ized uses. 106 Mapping NFSv4 ACLs February 2004 108 Additionally the NFSv4 ACLs specify a number of flags that can be 109 applied to an ACL. These include a specification on how an ACL on a 110 directory may be propagated to newly created files or directories 111 inside of said directory. 113 It is clear that the granularity of access control that NFSv4 ACLs 114 specify is well beyond the standard UNIX capability of expressing 115 file system object permissions. 117 33.. PPOOSSIIXX AACCLLss 119 POSIX ACLs refer to POSIX 1003.1e/1003.2c Draft Standard 17 [posix- 120 acl], which was meant to specify a POSIX standard for ACLs, but 121 unfortunately never materialized. However, many systems still use 122 it, both in the form of it's latest draft as well as earlier drafts. 124 POSIX ACLs are simpler than their NFSv4 equivalents. Each ACE an has 125 an entity and the traditional UNIX mode bits that are assigned to the 126 particular entity. The entity may be an arbitrary UID or GID or one 127 of a few special entities, the most notable of which is the ACL_MASK 128 entity. POSIX ACLs are also interepreted differently than their 129 NFSv4 equivalents. 131 POSIX ACLs are interpreted as follows: 133 1) Process the ACL_USER_OBJ (equivalent to UNIX file owner) ACE 134 first; if the UID of the requester does not match that of the 135 ACL_USER_OBJ, then the ACE is ignored. Otherwise, if the 136 requester's access mask is allowed by the access mask of the ACE, 137 the request is granted, else the request is denied. 139 2) Process all of the ACL_USER ACEs; the entity of these ACEs specify 140 a user on the system. If the UID of the requester does not match 141 that of the ACE, then the ACE is ignored. Otherwise, if the 142 requester's access mask is allowed by the access mask of the ACE, 143 the request is granted, else the request is denied. 145 3) Process the ACL_GROUP_OBJ ACE and all of the ACL_GROUP ACEs; the 146 entity of these ACEs specify a group on the system. If none of 147 the GIDs of the requester match the current ACE, the particular 148 ACE is ignored. For any matching ACE, if the the requester's 149 access mask is allowed by the ACEs access mask, then access is 150 permitted. If there are matching ACEs, but none allow access, 151 then access is denied. 153 Mapping NFSv4 ACLs February 2004 155 4) If the requester's access mask is allowed by the ACL_OTHER ACE, 156 then grant access. 158 5) Deny access. 160 Steps (2) and (3) have an additional criteria; in addition to check- 161 ing whether the requested access mask is allowed by the access mask 162 in the ACE, the requested bits also have to be in the access mask of 163 the special ACE with the ACL_MASK entity. This allows file owners to 164 specify a maximum level of access allowed by any other user or group 165 that has any access to the file system object. 167 In addition to a regular POSIX ACL, a directory in the file system 168 may also have associated with it a default ACL. This default ACL 169 governs the ACL a file system object will be assigned initially when 170 it is created as a child of the particular directory. 172 44.. MMaappppiinngg PPoossiixx AACCLLss ttoo NNFFSSvv44 AACCLLss 174 Given the difference in both extensiveness and interpretation of 175 POSIX and NFSv4 ACLs, any conversion between the two is difficult. 176 However, POSIX ACLs are a subset of NFSv4 ACLs. Any POSIX ACL can be 177 emulated with an NFSv4 ACL using the following mapping. 179 The ACE entities are translated as follows. The non-special entities 180 in form of UIDs and GIDs is translated to equivalent strings (a sys- 181 tem dependent process, typically done by lookups to /etc/passwd in 182 UNIX). The POSIX ACL_USER_OBJ entity is translated to the "OWNER" 183 NFSv4 entity. Similary, the POSIX ACL_GROUP_OBJ is translated to the 184 "GROUP" NFSv4 entity. The ACL_OTHER entity is translated to the 185 "EVERYONE" NFSv4 entity. 187 The ACE access mask is translated as follows. The read bit of the 188 POSIX access mask is translated to the logical OR of the 189 ACE4_READ_DATA and ACE4_READ_NAMED_ATTRS NFSv4 access mask fields. 190 The write bit of the POSIX access mask is translated to the logical 191 OR of the ACE4_WRITE_DATA, ACE4_WRITE_NAMED_ATTRIBUTES and 192 ACE4_APPEND_DATA NFSv4 access mask fields. The execute bit of the 193 POSIX access mask is translated into the ACE4_EXECUTE and 194 ACE4_READ_DATA NFSv4 acess mask fields. Note that NFSv4 defines 195 ACE4_READ_DATA, ACE4_WRITE_DATA, and ACE4_APPEND_DATA to be equal to 196 ACE4_LIST_DIRECTORY, ACE4_ADD_FILE, and ACE4_ADD_SUBDIRECTORY, 197 respectively, so this translation makes sense for directories as 198 well. However, on directories the ACE4_DELETE_CHILD field must be 199 included in the translation of the POSIX write bit. 201 Mapping NFSv4 ACLs February 2004 203 In addition to the above, the OWNER entity must always be given 204 ACE4_WRITE_ACL and ACE4_WRITE_ATTRIBUTES, and all entities must be 205 given ACE4_READ_ACL and ACE4_READ_ATTRIBUTES. 207 The ACE flag field also has a simple translation. If the file system 208 object is a directory, and the POSIX ACE belongs to a default ACL, 209 the "ACE4_INHERIT_ONLY_ACE" flag is set in the NFSv4 ACE. If the 210 entity in the POSIX ACE refers to a group, the "ACE4_IDENTI- 211 FIER_GROUP" flag is set in the NFSv4 ACE. 213 The POSIX ACL_USER_OBJ ACE is also always given the permission bits 214 "ACE4_READ_ACL" and "ACE4_WRITE_ACL." 216 Completing the mapping reduces to being able to emulate an ACL_MASK 217 and compensate for the difference in interpretation between two ACL 218 implementations. 220 The difference in interpretation of the two ACL types call for a 221 translation scheme. The scheme follows: 223 Every user ACE in the POSIX ACL maps into 2 NFSv4 ACEs; one ALLOW ACE 224 which is translated as specified by the above scheme, then a comple- 225 menting DENY ACE which is also translated as specified by the above 226 scheme, with the exception that the access mask is inverted. Note 227 that the ACL_USER_OBJ ACE is placed first in this list. 229 Every group ACE in the POSIX ACL produces a similar pair, but instead 230 of being in sequence, all of the ALLOW ACEs are all in sequence, fol- 231 lowed by all the DENY ACEs. The ACL_GROUP_OBJ ACE is placed first in 232 both lists. 234 Lastly, the POSIX ACL_OTHER ACE is translated into a pair of ACEs as 235 in the user ACE case. 237 This translation strategy allows us to emulate POSIX ACL interpreta- 238 tion in an NFSv4 ACL. 240 To handle the special POSIX entity ACL_MASK, we slightly modify the 241 above translation: 243 With the exception of the "OWNER" and "EVERYONE" ACEs, another ACE is 244 prepended to the ACE. The prepended ACE is a DENY ACE with the same 245 entity as the following ALLOW ACE, but with a permission mask set to 246 the complement of the POSIX ACL_MASK. 248 This method allows us to preserve the real permission bits of each 249 ACE should the ACL_MASK be changed. 251 Mapping NFSv4 ACLs February 2004 253 55.. SSeeccuurriittyy CCoonnssiiddeerraattiioonnss 255 Since this draft deals with the mapping of Access Control Lists, it 256 is deeply involved with security. The body of this document needs to 257 address the issue of mapping ACLs in a way as to not disobey the 258 intent of or mislead the user. 260 Mapping NFSv4 ACLs February 2004 262 66.. BBiibblliiooggrraapphhyy 264 [rfc3010bis] 265 Shepler, S. et. al., "NFS version 4 Protocol", draft-ietf- 266 nfsv4-rfc3010bis-05.txt, April 2003. 268 http://www.ietf.org/internet-drafts/draft-ietf- 269 nfsv4-rfc3010bis-05.txt 271 [posixacl] 272 IEEE, "IEEE Draft P1003.1e", October 1997 (last draft). 274 http://wt.xpilot.org/publications/posix.1e/download.html 276 Mapping NFSv4 ACLs February 2004 278 77.. AAcckknnoowwlleeddggmmeennttss 280 The author would like to thank and acknowledge Bruce Fields for his 281 careful scrutiny and excellent comments and suggestions. 283 Mapping NFSv4 ACLs February 2004 285 88.. AAuutthhoorr''ss AAddddrreessss 287 Address comments related to this memorandum to: 289 marius@umich.edu 291 Marius Aamodt Eriksen 292 University of Michigan / CITI 293 535 West William 294 Ann Arbor, Michigan 296 E-mail: marius@umich.edu 298 99.. CCooppyyrriigghhtt 300 Copyright (C) The Internet Society (2002-2004). All Rights Reserved. 302 This document and translations of it may be copied and furnished to 303 others, and derivative works that comment on or otherwise explain it 304 or assist in its implmentation may be prepared, copied, published and 305 distributed, in whole or in part, without restriction of any kind, 306 provided that the above copyright notice and this paragraph are 307 included on all such copies and derivative works. However, this doc- 308 ument itself may not be modified in any way, such as by removing the 309 copyright notice or references to the Internet Society or other 310 Internet organizations, except as needed for the purpose of develop- 311 ing Internet standards in which case the procedures for copyrights 312 defined in the Internet Standards process must be followed, or as 313 required to translate it into languages other than English. 315 The limited permissions granted above are perpetual and will not be 316 revoked by the Internet Society or its successors or assigns. 318 This document and the information contained herein is provided on an 319 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 320 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 321 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 322 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 323 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.