idnits 2.17.1 draft-ietf-nfsv4-acls-00.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 1314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1304. ** 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.) 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 15, 2006) is 6638 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'POSIX' ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Falkner 3 Internet-Draft L. Week 4 Expires: August 19, 2006 Sun Microsystems, Inc. 5 February 15, 2006 7 NFS Version 4 ACLs 8 draft-ietf-nfsv4-acls-00.txt 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 August 19, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 NFS version 4 (specified in RFC 3530) Access Control Lists (ACLs) 42 provide more fine grained control than previous file permission 43 models, but before the full benefit of the model can be exploited, 44 some changes and clarifications must be made. This document will 45 describe the details that implementors should consider in order to 46 allow implementations to function and interoperate better. 48 Table of Contents 50 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 51 2. Security Considerations . . . . . . . . . . . . . . . . . . . 4 52 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 4. Syntax for the Representation of ACLs . . . . . . . . . . . . 6 54 5. Interaction Between Mode and ACL . . . . . . . . . . . . . . . 7 55 5.1. What should happen to the mode if a SETATTR of ACL is 56 done? . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 5.2. How should a mode given in the arguments to CREATE or 58 OPEN affect an inherited ACL? . . . . . . . . . . . . . . 11 59 5.3. What should happen to an existing ACL if a mode is 60 applied to the file/directory? . . . . . . . . . . . . . . 12 61 5.4. What should happen if both mode and ACL are given to 62 SETATTR? . . . . . . . . . . . . . . . . . . . . . . . . . 17 63 5.4.1. Client Side Recommendations . . . . . . . . . . . . . 17 64 5.4.2. Server Side Recommendations . . . . . . . . . . . . . 18 65 6. Deficiencies in a Mode Representation of an ACL . . . . . . . 19 66 7. Access Control Semantics . . . . . . . . . . . . . . . . . . . 20 67 8. Inheritance and turning it off . . . . . . . . . . . . . . . . 21 68 9. EVERYONE@: What does it mean? . . . . . . . . . . . . . . . . 22 69 10. Access Mask Bit Discussion . . . . . . . . . . . . . . . . . . 23 70 11. Append Only Behavior . . . . . . . . . . . . . . . . . . . . . 27 71 12. ACE4_DELETE/ACE4_DELETE_CHILD Behavior . . . . . . . . . . . . 28 72 13. ACE4_ADD_FILE and ACE4_ADD_SUBDIRECTORY . . . . . . . . . . . 29 73 14. POSIX Considerations . . . . . . . . . . . . . . . . . . . . . 30 74 14.1. Background Information . . . . . . . . . . . . . . . . . . 30 75 14.2. Additional and Alternate File Access Control Mechanisms . 30 76 14.3. NFSv4 ACLs vs. POSIX-draft ACLs . . . . . . . . . . . . . 30 77 14.4. NFSv4 ACLs vs. POSIX . . . . . . . . . . . . . . . . . . . 32 78 14.5. umask Considerations . . . . . . . . . . . . . . . . . . . 33 79 15. Normative References . . . . . . . . . . . . . . . . . . . . . 33 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 81 Intellectual Property and Copyright Statements . . . . . . . . . . 35 83 1. Requirements notation 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 2. Security Considerations 91 None. 93 3. Introduction 95 Readers of this document are expected to have basic knowledge of the 96 Network File System (NFS) version 4 protocol [RFC3530]. Familiarity 97 with the NFS version 4 protocol will provide the correct context for 98 the issues discussed in this document. 100 The NFS version 4 protocol defines a standard Access Control List 101 (ACL) model, which to our knowledge, is the first approved standard 102 for ACLs. Prior attempts have been made to standardize ACL models, 103 but none have succeeded. Therefore, there has been a proliferation 104 of ACL models in the computer industry. These multiple models make 105 it close to impossible to interoperate between the wide array of 106 vendors. 108 NFS version 4 ACLs attempt to bridge the gap between the different 109 vendors, allowing them to interoperate. Implementations have been 110 suffering from differing interpretations of the standard. This 111 document attempts to clarify some of the pieces of the NFS version 4 112 ACL model with the hope that vendors will be able to agree on 113 semantics which will lead to increased ability to interoperate. 115 4. Syntax for the Representation of ACLs 117 Throughout the document the following abbreviations will be used for 118 the ACE type: 120 ALLOW (short for ACE4_ACCESS_ALLOWED_ACE_TYPE) 122 DENY (short for ACE4_ACCESS_DENIED_ACE_TYPE) 124 AUDIT (short for ACE4_SYSTEM_AUDIT_ACE_TYPE) 126 ALARM (short for ACE4_SYSTEM_ALARM_ACE_TYPE) 128 Representation of ACLs in this document will be of the form: 130 ::: 132 Field #1 is the "ACE who" and example values are: 133 OWNER@, GROUP@, lisagab@sun.com, samf@sun.com 135 Field #2 are the "access mask bits" separated with 136 "/" characters and example values are: 137 ACE4_READ_DATA/ACE4_WRITE_DATA 139 Field #3 are the "ACE flags" and example values are: 140 ACE4_FILE_INHERIT_ACE, ACE4_IDENTIFIER_GROUP 142 Field #4 is the "ACE type" and example values are: 143 ALLOW, DENY 145 5. Interaction Between Mode and ACL 147 For client and server implementors alike, a misunderstanding of the 148 interactions between the mode and ACL file attributes is likely to be 149 a cause of problems. 151 The relationship between NFS version 4 modes and ACLs is difficult, 152 but not impossible to specify. Contributing to this is the fact that 153 while there are portions of the mode that ACLs don't specify, it is 154 impossible for a mode to represent all of the information in an ACL. 156 The NFS version 4 mode attribute is based on the UNIX mode bits. 157 Some information that is traditionally associated with the UNIX mode 158 bits, "setuid"/"setgid"/"sticky" (MODE4_SUID/MODE4_SGID/MODE4_SVTX), 159 are not defined to be part of the ACL. Other information that can 160 also affect file permissions, such as the file's owner and owning 161 group are also not defined to be part of the ACL. In other words, 162 from looking at an ACL, a user will be unable to tell who the owner 163 and owning group of a file is. This is because of the special 164 identifiers, OWNER@ and GROUP@. 166 This section will attempt to answer the following questions: 168 1. What should happen to the mode if a SETATTR of ACL is done? 170 2. How should a mode given to CREATE or OPEN affect an inherited 171 ACL? 173 3. What should happen to an existing ACL if a mode is applied to the 174 file/directory? 176 4. What should happen if both mode and ACL are given to SETATTR? 178 5.1. What should happen to the mode if a SETATTR of ACL is done? 180 Keeping the mode and ACL attributes synchronized is important, but as 181 mentioned previously, the mode cannot possibly represent all of the 182 information in the ACL. 184 Still, the mode should be modified to represent the access as 185 accurately as possible. The mode is not guaranteed to be accurate 186 and could potentially be more restrictive than the access that would 187 actually be given by the ACL (for more discussion on this topic, see 188 Section 6). Because of this, client implementations are not 189 recommended to not do their own access checks based on the mode of a 190 file. For further information on access checking, see Section 7. 192 The general algorithm to assign a new mode attribute to an object 193 based on a new ACL being set is: 195 1. Walk through the ACEs in order, looking for ACEs with a "who" 196 value of OWNER@, GROUP@, or EVERYONE@. 198 2. It is understood that ACEs with a "who" value of OWNER@ affect 199 the *USR bits of the mode, GROUP@ affect *GRP bits, and EVERYONE@ 200 affect *USR, *GRP, and *OTH bits (For more discussion on the 201 EVERYONE@ special identifier see Section 9). 203 3. If such an ACE specifies ALLOW or DENY for ACE4_READ_DATA, 204 ACE4_WRITE_DATA, or ACE4_EXECUTE, and the mode bits affected have 205 not been determined yet, set them to one (if ALLOW) or zero (if 206 DENY). 208 4. Upon completion, any mode bits as yet undetermined have a value 209 of zero. 211 This pseudocode more precisely describes the algorithm: 213 /* octal constants for the mode bits */ 215 RUSR = 0400 216 WUSR = 0200 217 XUSR = 0100 218 RGRP = 0040 219 WGRP = 0020 220 XGRP = 0010 221 ROTH = 0004 222 WOTH = 0002 223 XOTH = 0001 225 /* 226 * old_mode represents the previous value 227 * of the mode of the object. 228 */ 230 mode_t mode = 0, seen = 0; 231 for each ACE a { 232 if a.type is ALLOW or DENY and 233 ACE4_INHERIT_ONLY_ACE is not set in a.flags { 234 if a.who is OWNER@ { 235 if ((a.mask & ACE4_READ_DATA) && 236 (! (seen & RUSR))) { 237 seen |= RUSR; 238 if a.type is ALLOW { 239 mode |= RUSR; 240 } 242 } 243 if ((a.mask & ACE4_WRITE_DATA) && 244 (! (seen & WUSR))) { 245 seen |= WUSR; 246 if a.type is ALLOW { 247 mode |= WUSR; 248 } 249 } 250 if ((a.mask & ACE4_EXECUTE) && 251 (! (seen & XUSR))) { 252 seen |= XUSR; 253 if a.type is ALLOW { 254 mode |= XUSR; 255 } 256 } 257 } else if a.who is GROUP@ { 258 if ((a.mask & ACE4_READ_DATA) && 259 (! (seen & RGRP))) { 260 seen |= RGRP; 261 if a.type is ALLOW { 262 mode |= RGRP; 263 } 264 } 265 if ((a.mask & ACE4_WRITE_DATA) && 266 (! (seen & WGRP))) { 267 seen |= WGRP; 268 if a.type is ALLOW { 269 mode |= WGRP; 270 } 271 } 272 if ((a.mask & ACE4_EXECUTE) && 273 (! (seen & XGRP))) { 274 seen |= XGRP; 275 if a.type is ALLOW { 276 mode |= XGRP; 277 } 278 } 279 } else if a.who is EVERYONE@ { 280 if (a.mask & ACE4_READ_DATA) { 281 if ! (seen & RUSR) { 282 seen |= RUSR; 283 if a.type is ALLOW { 284 mode |= RUSR; 285 } 286 } 287 if ! (seen & RGRP) { 288 seen |= RGRP; 289 if a.type is ALLOW { 290 mode |= RGRP; 291 } 292 } 293 if ! (seen & ROTH) { 294 seen |= ROTH; 295 if a.type is ALLOW { 296 mode |= ROTH; 297 } 298 } 299 } 300 if (a.mask & ACE4_WRITE_DATA) { 301 if ! (seen & WUSR) { 302 seen |= WUSR; 303 if a.type is ALLOW { 304 mode |= WUSR; 305 } 306 } 307 if ! (seen & WGRP) { 308 seen |= WGRP; 309 if a.type is ALLOW { 310 mode |= WGRP; 311 } 312 } 313 if ! (seen & WOTH) { 314 seen |= WOTH; 315 if a.type is ALLOW { 316 mode |= WOTH; 317 } 318 } 319 } 320 if (a.mask & ACE4_EXECUTE) { 321 if ! (seen & XUSR) { 322 seen |= XUSR; 323 if a.type is ALLOW { 324 mode |= XUSR; 325 } 326 } 327 if ! (seen & XGRP) { 328 seen |= XGRP; 329 if a.type is ALLOW { 330 mode |= XGRP; 331 } 332 } 333 if ! (seen & XOTH) { 334 seen |= XOTH; 335 if a.type is ALLOW { 336 mode |= XOTH; 337 } 339 } 340 } 341 } 342 } 343 } 344 return mode | (old_mode & (SUID | SGID | SVTX)) 346 5.2. How should a mode given in the arguments to CREATE or OPEN affect 347 an inherited ACL? 349 The goal of implementing ACL inheritance is for newly created objects 350 to inherit the ACLs they were intended to inherit, but without 351 disregarding the mode that is given with the arguments to the CREATE 352 or OPEN operations. The general algorithm is as follows: 354 1. Form an ACL on the newly created object that is the concatenation 355 of all inheritable ACEs from its parent directory. Note that 356 there may be zero inheritable ACEs; thus, an object may start 357 with an empty ACL. 359 This is self explanatory. If, for example, a new non-directory 360 file is being created, ACEs with the flag of 361 ACE4_FILE_INHERIT_ACE will be considered inheritable. 363 2. For each ACE in the new ACL, adjust its flags if necessary, and 364 possibly create two ACEs in place of one. 366 This will be discussed in detail below. 368 3. Apply the algorithm for applying a mode to a file/directory with 369 an existing ACL on the new object as described in Section 5.3, 370 using the mode that is to be used for file creation. 372 This ensures that the mode is honored. 374 Step 2 above is necessary to honor the intent of the inheritance- 375 related flags. It also is intended to preserve information about the 376 original inheritable ACEs in the case that they will be modified by 377 other steps. Paragraph 2 is detailed in the following algorithm: 379 1. If the ACE4_NO_PROPAGATE_INHERIT_ACE is set, or the type of the 380 file is something other than "directory", then clear the 381 following flags: 383 ACE4_NO_PROPAGATE_INHERIT_ACE 385 ACE4_FILE_INHERIT_ACE 386 ACE4_DIRECTORY_INHERIT_ACE 388 ACE4_INHERIT_ONLY_ACE 390 Continue on to the next ACE. 392 2. If the type of file is "directory" and ACE4_FILE_INHERIT_ACE is 393 set and ACE4_DIRECTORY_INHERIT_ACE is NOT set, then we ensure 394 that ACE4_INHERIT_ONLY_ACE is set. Continue on to the next ACE. 395 Otherwise: 397 3. If the type of the ACE is neither ALLOW nor DENY, then continue 398 on to the next ACE. 400 4. Copy the original ACE into a second, adjacent ACE. 402 5. On the first ACE, ensure that ACE4_INHERIT_ONLY_ACE is set. 404 6. On the second ACE, clear the following flags: 406 ACE4_NO_PROPAGATE_INHERIT_ACE 408 ACE4_FILE_INHERIT_ACE 410 ACE4_DIRECTORY_INHERIT_ACE 412 ACE4_INHERIT_ONLY_ACE 414 7. On the second ACE, if the type field is ALLOW, an implementation 415 MAY clear the following mask bits: 417 ACE4_WRITE_ACL 419 ACE4_WRITE_OWNER 421 5.3. What should happen to an existing ACL if a mode is applied to the 422 file/directory? 424 An existing ACL can mean two things in this context. One, that a 425 file/directory already exists and it has an ACL. Two, that a 426 directory has inheritable ACEs that will make up the ACL for any new 427 files or directories created therein. 429 The high-level goal of the behavior when a mode is set on a file with 430 an existing ACL is to take the new mode into account, without needing 431 to disregard a pre-existing ACL. 433 When a mode is applied to an object, e.g. via SETATTR or CREATE/OPEN, 434 the ACL must be modified to accommodate the mode. 436 1. The ACL is traversed, one ACE at a time. For each ACE: 438 1. If the type of the ACE is neither ALLOW nor DENY, the ACE is 439 left unchanged. Continue to the next ACE. 441 2. If the ACE4_INHERIT_ONLY_ACE flag is set on the ACE, it is 442 left unchanged. Continue to the next ACE. 444 3. If either or both of ACE4_FILE_INHERIT_ACE or 445 ACE4_DIRECTORY_INHERIT_ACE are set: 447 1. A copy of the ACE is made, and placed in the ACL 448 immediately following the current ACE. 450 2. In the first ACE, the flag ACE4_INHERIT_ONLY_ACE is set. 452 3. In the second ACE, the following flags are cleared: 454 ACE4_FILE_INHERIT_ACE 456 ACE4_DIRECTORY_INHERIT_ACE 458 ACE4_NO_PROPAGATE_INHERIT_ACE 460 The algorithm continues on with the second ACE. 462 4. If the "who" field is one of the following: 464 OWNER@ 466 GROUP@ 468 EVERYONE@ 470 then the following mask bits are cleared: 472 ACE4_READ_DATA 474 ACE4_LIST_DIRECTORY 476 ACE4_WRITE_DATA 478 ACE4_ADD_FILE 480 ACE4_APPEND_DATA 481 ACE4_ADD_SUBDIRECTORY 483 ACE4_EXECUTE 485 At this point, we proceed to the next ACE. 487 5. Otherwise, if the "who" field did not match one of OWNER@, 488 GROUP@, or EVERYONE@, the following steps SHOULD be 489 performed. 491 1. If the type of the ACE is ALLOW, we check the preceding 492 ACE (if any). If it does not meet all of the following 493 criteria: 495 1. The type field is DENY. 497 2. The who field is the same as the current ACE. 499 3. The flag bit ACE4_IDENTIFIER_GROUP is the same as it 500 is in the current ACE, and no other flag bits are 501 set. 503 4. The mask bits are a subset of the mask bits of the 504 current ACE, and are also a subset of the following: 506 ACE4_READ_DATA 508 ACE4_LIST_DIRECTORY 510 ACE4_WRITE_DATA 512 ACE4_ADD_FILE 514 ACE4_APPEND_DATA 516 ACE4_ADD_SUBDIRECTORY 518 ACE4_EXECUTE 520 then an ACE of type DENY, with a who equal to the current 521 ACE, flag bits equal to ( & 522 ACE4_IDENTIFIER_GROUP), and no mask bits, is prepended. 524 2. The following modifications are made to the prepended 525 ACE. The intent is to mask the following ACE to disallow 526 ACE4_READ_DATA, ACE4_WRITE_DATA, ACE4_APPEND_DATA, or 527 ACE4_EXECUTE, based upon the group permissions of the new 528 mode. As a special case, if the ACE matches the current 529 owner of the file, the owner bits are used, rather than 530 the group bits. This is reflected in the algorithm 531 below. 533 Let there be three bits defined: 535 #define READ 04 536 #define WRITE 02 537 #define EXEC 01 539 Let "amode" be the new mode, right-shifted three 540 bits, in order to have the group permission bits 541 placed in the three low order bits of amode, 542 i.e. amode = mode >> 3 544 If ACE4_IDENTIFIER_GROUP is not set in the flags, 545 and the "who" field of the ACE matches the owner 546 of the file, we shift amode three more bits, in 547 order to have the owner permission bits placed in 548 the three low order bits of amode: 550 amode = amode >> 3 552 amode is now used as follows: 554 If ACE4_READ_DATA is set on the current ACE: 555 If READ is set on amode: 556 ACE4_READ_DATA is cleared on the prepended ACE 557 else: 558 ACE4_READ_DATA is set on the prepended ACE 560 If ACE4_WRITE_DATA is set on the current ACE: 561 If WRITE is set on amode: 562 ACE4_WRITE_DATA is cleared on the prepended ACE 563 else: 564 ACE4_WRITE_DATA is set on the prepended ACE 566 If ACE4_APPEND_DATA is set on the current ACE: 567 If WRITE is set on amode: 568 ACE4_APPEND_DATA is cleared on the prepended ACE 569 else: 570 ACE4_APPEND_DATA is set on the prepended ACE 572 If ACE4_EXECUTE is set on the current ACE: 573 If EXEC is set on amode: 574 ACE4_EXECUTE is cleared on the prepended ACE 575 else: 577 ACE4_EXECUTE is set on the prepended ACE 579 3. To conform with POSIX, and prevent cases where the owner 580 of the file is given permissions via an explicit group 581 (i.e. alternate permissions are not disabled following a 582 chmod), we implement the following step. 584 If ACE4_IDENTIFIER_GROUP is set in the flags field of 585 the ALLOW ACE: 586 Let "mode" be the mode that we are chmoding to: 587 extramode = (mode >> 3) & 07 588 ownermode = mode >> 6 589 extramode &= ~ownermode 590 If extramode is not zero: 591 If extramode & READ: 592 Clear ACE4_READ_DATA in both the 593 prepended DENY ACE and the ALLOW ACE 594 If extramode & WRITE: 595 Clear ACE4_WRITE_DATA and ACE_APPEND_DATA in both 596 the prepended DENY ACE and the ALLOW ACE 597 If extramode & EXEC: 598 Clear ACE4_EXECUTE in both the prepended DENY 599 ACE and the ALLOW ACE 601 2. If there are at least six ACEs, the final six ACEs are examined. 602 If they are not equal to the following ACEs: 604 A1) OWNER@:::DENY 605 A2) OWNER@:ACE4_WRITE_ACL/ACE4_WRITE_OWNER/ 606 ACE4_WRITE_ATTRIBUTES/ACE4_WRITE_NAMED_ATTRIBUTES::ALLOW 607 A3) GROUP@::ACE4_IDENTIFIER_GROUP:DENY 608 A4) GROUP@::ACE4_IDENTIFIER_GROUP:ALLOW 609 A5) EVERYONE@:ACE4_WRITE_ACL/ACE4_WRITE_OWNER/ 610 ACE4_WRITE_ATTRIBUTES/ACE4_WRITE_NAMED_ATTRIBUTES::DENY 611 A6) EVERYONE@:ACE4_READ_ACL/ACE4_READ_ATTRIBUTES/ 612 ACE4_READ_NAMED_ATTRIBUTES/ACE4_SYNCHRONIZE::ALLOW 614 Then six ACEs matching the above are appended. 616 3. The final six ACEs are adjusted according to the incoming mode. 618 /* octal constants for the mode bits */ 620 RUSR = 0400 621 WUSR = 0200 622 XUSR = 0100 623 RGRP = 0040 624 WGRP = 0020 625 XGRP = 0010 626 ROTH = 0004 627 WOTH = 0002 628 XOTH = 0001 630 If RUSR is set: set ACE4_READ_DATA in A2 631 else: set ACE4_READ_DATA in A1 632 If WUSR is set: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A2 633 else: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A1 634 If XUSR is set: set ACE4_EXECUTE in A2 635 else: set ACE4_EXECUTE in A1 636 If RGRP is set: set ACE4_READ_DATA in A4 637 else: set ACE4_READ_DATA in A3 638 If WGRP is set: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A4 639 else: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A3 640 If XGRP is set: set ACE4_EXECUTE in A4 641 else: set ACE4_EXECUTE in A3 642 If ROTH is set: set ACE4_READ_DATA in A6 643 else: set ACE4_READ_DATA in A5 644 If WOTH is set: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A6 645 else: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A5 646 If XOTH is set: set ACE4_EXECUTE in A6 647 else: set ACE4_EXECUTE in A5 649 5.4. What should happen if both mode and ACL are given to SETATTR? 651 The only reason that a mode and ACL should be set in the same SETATTR 652 is if the user wants to set the SUID, SGID and SVTX bits along with 653 setting the permissions by means of an ACL. There is still no way to 654 enforce which order the attributes will be set in, and it is likely 655 that different orders of operations will produce different results. 657 In the long run, the best solution would be the ability to set SUID, 658 SGID and SVTX bits independent of the mode, but since we don't have 659 this ability in NFS version 4.0, this is what we recommend. 661 5.4.1. Client Side Recommendations 663 If an application needs to enforce a certain behavior, it is 664 recommended that the client implementations set mode and ACL in 665 separate SETATTR requests. This will produce consistent and expected 666 results. 668 If an application wants to set SUID, SGID and SVTX bits and an ACL, 669 we recommend: 671 In the first SETATTR, set the mode with SUID, SGID and SVTX bits 672 as desired and all other bits with a value of 0. 674 In a following SETATTR (preferably in the same COMPOUND) set the 675 ACL. 677 5.4.2. Server Side Recommendations 679 If both mode and ACL are given to SETATTR, server implementations 680 should verify that the mode and ACL don't conflict, i.e. the mode 681 computed from the given ACL must be the same as the given mode, 682 excluding the SUID, SGID and SVTX bits. The algorithm for assigning 683 a new mode based on the ACL can be used. This is described in 684 Section 5.1. If a server receives a request to set both mode and 685 ACL, but the two conflict, the server should return NFS4ERR_INVAL. 687 6. Deficiencies in a Mode Representation of an ACL 689 As mentioned in Section 5.1, the representation of the mode is 690 deterministic, but not guaranteed to be accurate. The mode bits 691 potentially convey a more restrictive permission than what will 692 actually be granted via the ACL. 694 Given the following ACL of two ACEs: 696 GROUP@:ACE4_READ_DATA/ACE4_WRITE_DATA/ACE4_EXECUTE: 697 ACE4_IDENTIFIER_GROUP:ALLOW 698 EVERYONE@:ACE4_READ_DATA/ACE4_WRITE_DATA/ACE4_EXECUTE::DENY 700 we would compute a mode of 0070. However, it is possible, even 701 likely, that the owner might be a member of the object's owning 702 group, and thus, the owner would be granted read, write, and execute 703 access to the object. This would conflict with the mode of 0070, 704 where an owner would be denied this access. 706 The only way to overcome this deficiency would be to determine 707 whether the object's owner is a member of the object's owning group. 708 This is difficult, but worse, on a POSIX or any UNIX-like system, it 709 is a process' membership in a group that is important, not a user's. 710 Thus, any fixed mode intended to represent the above ACL can be 711 incorrect. 713 Example: administrative databases (possibly /etc/passwd and /etc/ 714 group) indicate that the user "bob" is a member of the group "staff". 715 An object has the ACL given above, is owned by "bob", and has an 716 owning group of "staff". User "bob" has logged in to the system, and 717 thus processes have been created owned by "bob" and having membership 718 in group "staff". 720 A mode representation of the above ACL could thus be 0770, due to 721 user "bob" having membership in group "staff". Now, the 722 administrative databases are changed, such that user "bob" is no 723 longer in group "staff". User "bob" logs in to the system again, and 724 thus more processes are created, this time owned by "bob" but NOT in 725 group "staff". 727 A mode of 0770 is inaccurate for processes not belonging to group 728 "staff". But even if the mode of the file were proactively changed 729 to 0070 at the time the group database was edited, mode 0070 would be 730 inaccurate for the pre-existing processes owned by user "bob" and 731 having membership in group "staff". 733 7. Access Control Semantics 735 The NFS version 4 specification [RFC3530] defines how an ACL is 736 interpreted, and it states that the access is undefined if you get 737 through the entire ACL and haven't encountered an ALLOW or DENY ACE 738 for the requester. 740 We now recommend that if you fall through the ACL, access is denied. 741 This allows the behavior to be clearly defined, and consistent across 742 implementations. In fact, there is precedence for this behavior in 743 current implementations. 745 It is convenient that [RFC3530] gave implementations flexibility by 746 leaving the access undefined, but the flexibility is still present 747 given that there have always been security policies independent of 748 file permissions. Servers can have other security policies in place, 749 and in those cases, access will be decided outside of what is defined 750 in the ACL. 752 Examples of security policies that can be in place outside of what is 753 defined (or not defined) in the ACL are: 755 1. The owner of the file will always be granted ACE4_WRITE_ACL and 756 ACE4_READ_ACL permissions. 758 2. The ACL may say that an entity is to be granted ACE4_WRITE_DATA 759 permission, but the file system is mounted read only. 761 For multiple reasons, including the one listed above, client 762 implementations are recommended not to do their own access checking. 763 All access checking should be done on the server. 765 8. Inheritance and turning it off 767 The inheritance of access permissions may be problematic if a user 768 cannot prevent their file from inheriting unwanted permissions. For 769 example, a user, "samf", sets up a shared project directory to be 770 used by everyone working on Project Foo. "lisagab" is a part of 771 Project Foo, but is working on something that should not be seen by 772 anyone else. How can "lisagab" make sure that any new files that she 773 creates in this shared project directory do not inherit anything that 774 could compromise the security of her work? 776 More relevant to the implementors of NFS version 4 clients and 777 servers is the question of how to communicate the fact that user, 778 "lisagab", doesn't want any permissions to be inherited to her newly 779 created file or directory. 781 To do this, implementors should standardize on what the behavior of 782 CREATE and OPEN must be if: 784 1. just mode is given 786 In this case, inheritance will take place, but the mode will be 787 applied to the inherited ACL as described in Section 5.1, thereby 788 modifying the ACL. 790 2. just ACL is given 792 In this case, inheritance will not take place, and the ACL as 793 defined in the CREATE or OPEN will be set without modification. 795 3. both mode and ACL are given 797 In this case, implementors should verify that the mode and ACL 798 don't conflict, i.e. the mode computed from the given ACL must be 799 the same as the given mode. The algorithm for assigning a new 800 mode based on the ACL can be used. This is described in 801 Section 5.1) If a server receives a request to set both mode and 802 ACL, but the two conflict, the server should return 803 NFS4ERR_INVAL. If the mode and ACL don't conflict, inheritance 804 will not take place and both, the mode and ACL, will be set 805 without modification. 807 4. neither mode nor ACL are given 809 In this case, inheritance will take place and no modifications to 810 the ACL will happen. It is worth noting that if no inheritable 811 ACEs exist on the parent directory, the file will be created with 812 an empty ACL, thus granting no accesses. 814 9. EVERYONE@: What does it mean? 816 The NFS version 4 specification [RFC3530] refers to the "EVERYONE@" 817 special identifier as meaning "The world". This is confusing because 818 there are a couple of different ways to interpret the wording. These 819 different interpretations are problematic and it would be 820 advantageous for implementors to standardize on a single meaning. 822 The different interpretations are as follows: 824 1. "EVERYONE@" is equivalent to the UNIX "other" entity, which by 825 definition does not include the owner or owning group of the 826 file. 828 2. "EVERYONE@" literally means everyone, including the file's owner 829 and owning group. 831 The goal of standardizing on what "EVERYONE@" means may be best 832 expressed from a user's point of view. A user of NFS version 4 ACLs 833 should expect that setting an ACL such as the following will have the 834 same affect regardless of what vendor's implementation they are 835 using. 837 EVERYONE@:ACE4_READ_DATA::ALLOW 839 Examples of how the different interpretations could cause different 840 behaviors are as follows: 842 If we take interpretation #1 where "EVERYONE@" is equivalent to the 843 UNIX "other" entity and the owner or a user in the owning group 844 attempt to access the file for reading, they would be denied. This 845 is because we fell through the ACL and didn't find any entries 846 specifying the permissions for OWNER@ and GROUP@ (see Section 7). 848 If we take interpretation #2 where "EVERYONE@" is literally everyone, 849 including the owner and owning group, and the owner or a user in the 850 owning group attempt to access the file for reading, they would be 851 allowed. 853 The first interpretation is understandable, but does not follow the 854 intent of the special identifier. Therefore, it is recommended that 855 implementors use "EVERYONE@" to mean literally everyone. 857 10. Access Mask Bit Discussion 859 The purpose of this section is to clarify the meaning of the 860 different access mask bits. This will state the operations and a 861 description of what the access mask bit controls. A major portion of 862 the descriptions were taken from [RFC3530]. The following is a list 863 of access mask bits that can be set on an ACE: 865 ACE4_READ_DATA 866 Operation(s) affected: 867 READ 868 OPEN 869 Discussion: 870 Permission to read the data of the file. 872 ACE4_LIST_DIRECTORY 873 Operation(s) affected: 874 READDIR 875 Discussion: 876 Permission to list the contents of a directory. 878 ACE4_WRITE_DATA 879 Operation(s) affected: 880 WRITE 881 OPEN 882 Discussion: 883 Permission to modify a file's data anywhere in 884 the file's offset range. This includes the 885 ability to write to any arbitrary offset and as 886 a result to grow the file. 888 ACE4_ADD_FILE 889 Operation(s) affected: 890 CREATE 891 OPEN 892 Discussion: 893 Permission to add a new file in a directory. 894 The CREATE operation is affected when 895 nfs_ftype4 is NF4LNK, NF4BLK, NF4CHR, NF4SOCK, 896 or NF4FIFO. (NF4DIR is not listed because it is 897 covered by ACE4_ADD_SUBDIRECTORY.) OPEN is 898 affected when used to create a regular file. 900 ACE4_APPEND_DATA 901 Operation(s) affected: 902 WRITE 903 OPEN 904 Discussion: 906 The ability to modify a file's data, but only 907 starting at EOF. See Section 11 for further 908 discussion on the relationship between 909 ACE4_APPEND_DATA and ACE4_WRITE_DATA. 911 ACE4_ADD_SUBDIRECTORY 912 Operation(s) affected: 913 CREATE 914 Discussion: 915 Permission to create a subdirectory in a 916 directory. The CREATE operation is affected 917 when nfs_ftype4 is NF4DIR. 919 ACE4_READ_NAMED_ATTRS 920 Operation(s) affected: 921 OPENATTR 922 Discussion: 923 Permission to lookup the named attributes directory. 924 OPENATTR is affected when it is not used to 925 create a named attribute directory. This is 926 when 1.) createdir is TRUE, but a named 927 attribute directory already exists, or 2.) 928 createdir is FALSE. 930 ACE4_WRITE_NAMED_ATTRS 931 Operation(s) affected: 932 OPENATTR 933 Discussion: 934 Permission to create a named attribute directory. 935 OPENATTR is affected when it is used to create 936 a named attribute directory. This is when 937 createdir is TRUE and no named attribute 938 directory exists. The ability to check whether 939 or not a named attribute directory exists 940 depends on the ability to look it up, 941 therefore, users also need the 942 ACE4_READ_NAMED_ATTRS permission in order to 943 create a named attribute directory. 945 ACE4_EXECUTE 946 Operation(s) affected: 947 LOOKUP 948 Discussion: 949 Permission to execute a file or traverse/search 950 a directory. 952 ACE4_DELETE_CHILD 953 Operation(s) affected: 955 REMOVE 956 Discussion: 957 Permission to delete a file or directory within 958 a directory. 960 ACE4_READ_ATTRIBUTES 961 Operation(s) affected: 962 GETATTR of file system object attributes 963 Discussion: 964 The ability to read basic attributes (non-ACLs) 965 of a file. 967 ACE4_WRITE_ATTRIBUTES 968 Operation(s) affected: 969 SETATTR of time_access_set, time_backup, 970 time_create, time_modify_set 971 Discussion: 972 Permission to change the times associated with 973 a file or directory to an arbitrary value. 975 ACE4_DELETE 976 Operation(s) affected: 977 REMOVE 978 Discussion: 979 Permission to delete the file or directory. 981 ACE4_READ_ACL 982 Operation(s) affected: 983 GETATTR of acl 984 Discussion: 985 Permission to read the ACL. 987 ACE4_WRITE_ACL 988 Operation(s) affected: 989 SETATTR of acl and mode 990 Discussion: 991 Permission to write the acl and mode attributes. 993 ACE4_WRITE_OWNER 994 Operation(s) affected: 995 SETATTR of owner and owner_group 996 Discussions: 997 Permission to write the owner and owner_group 998 attributes. On UNIX systems, this is the 999 ability to execute chown or chgrp. 1001 ACE4_SYNCHRONIZE 1002 Operation(s) affected: 1004 NONE 1005 Discussion: 1006 Permission to access file locally at the server with 1007 synchronized reads and writes. 1009 11. Append Only Behavior 1011 The NFS version 4 ACL model allows for the notion of append-only 1012 files, by allowing ACE4_APPEND_DATA and denying ACE4_WRITE_DATA to 1013 the same user or group. 1015 If a file has an ACL such as the one described above and a WRITE 1016 request is made for somewhere other than EOF, the server SHOULD 1017 return NFS4ERR_ACCESS. 1019 12. ACE4_DELETE/ACE4_DELETE_CHILD Behavior 1021 There are two separate access mask bits that govern the ability to 1022 delete a file: ACE4_DELETE and ACE4_DELETE_CHILD. ACE4_DELETE is 1023 intended to be specified by the ACL for the object to be deleted, and 1024 ACE4_DELETE_CHILD is intended to be specified by the ACL of the 1025 parent directory. 1027 In addition to ACE4_DELETE and ACE4_DELETE_CHILD, many systems also 1028 consider the "sticky bit" (MODE4_SVTX) and the appropriate "write" 1029 mode bit when determining whether to allow a file to be deleted. The 1030 mode bit for write corresponds to ACE4_WRITE_DATA, which is the same 1031 physical bit as ACE4_ADD_FILE. Therefore, ACE4_ADD_FILE can come 1032 into play when determining permission to delete. 1034 In the algorithm below, the strategy is that ACE4_DELETE and 1035 ACE4_DELETE_CHILD take precedence over the sticky bit, and the sticky 1036 bit takes precedence over the "write" mode bits (reflected in 1037 ACE4_ADD_FILE). 1039 Server implementations SHOULD grant or deny permission to delete 1040 based on the following algorithm. 1042 if ACE4_EXECUTE is denied by the parent directory ACL: 1043 deny delete 1044 else if ACE4_EXECUTE is unspecified by the parent directory ACL: 1045 deny delete 1046 else if ACE4_DELETE is allowed by the target object ACL: 1047 allow delete 1048 else if ACE4_DELETE_CHILD is allowed by the parent directory ACL: 1049 allow delete 1050 else if ACE4_DELETE_CHILD is denied by the parent directory ACL: 1051 deny delete 1052 else if ACE4_ADD_FILE is allowed by the parent directory ACL: 1053 if MODE4_SVTX is set for the parent directory: 1054 if the principal owns the parent directory OR 1055 the principal owns the target object OR 1056 ACE4_WRITE_DATA is allowed by the target object ACL: 1057 allow delete 1058 else: 1059 deny delete 1060 else: 1061 allow delete 1062 else: 1063 deny delete 1065 13. ACE4_ADD_FILE and ACE4_ADD_SUBDIRECTORY 1067 As specified in Section 10, the permission granted by ACE4_WRITE_DATA 1068 is a superset of the permission granted by ACE4_APPEND_DATA. With 1069 directories, ACE4_WRITE_DATA is analogous to ACE4_ADD_FILE, and 1070 ACE4_APPEND_DATA is analogous to ACE4_ADD_SUBDIRECTORY. 1072 A question this raises is whether ACE4_ADD_FILE is a superset of 1073 ACE4_ADD_SUBDIRECTORY. In other words, does the granting of 1074 ACE4_ADD_FILE imply the permission to create a subdirectory? 1076 It is proposed that ACE4_ADD_FILE does not imply 1077 ACE4_ADD_SUBDIRECTORY. 1079 14. POSIX Considerations 1081 Disclaimer: This section is relevant to platforms with requirements 1082 to be POSIX compliant. These platforms are typically UNIX based, and 1083 the following discussion will be heavily biased toward those 1084 platforms. 1086 14.1. Background Information 1088 The standard POSIX (See [POSIX]) file access control mechanism uses 1089 the file permission bits contained in the file mode. The file 1090 permission bits are used to determine whether a process has read, 1091 write or execute/search permission to a file based on which class the 1092 process is in; file owner, file group or file other class. 1094 A process is in the file owner class if the effective user ID of the 1095 process matches the user ID of the file. A process is in the file 1096 group class if the process is not in the file owner class and if the 1097 effective group ID or one of the supplementary group IDs of the 1098 process matches the group ID associated with the file. A process is 1099 in the file other class if the effective user ID of the process is 1100 not in the file owner class or the file group class. 1102 The POSIX spec says that a process is in one and only one class, 1103 therefore, the access permissions that exist for that class are the 1104 only ones that will be considered when doing access checks. 1106 14.2. Additional and Alternate File Access Control Mechanisms 1108 In addition to the standard file access control mechanism, the POSIX 1109 spec allows for additional and alternate file access control 1110 mechanisms. According to Section 4.4 of the POSIX spec, a file can 1111 have one or both mechanisms in place. 1113 The additional file access control mechanism is defined to be layered 1114 upon the file permission bits, but they can only further restrict the 1115 standard file access control mechanism. The alternate file access 1116 control mechanism is defined to be independent of the file permission 1117 bits and which if enabled on a file may either restrict or extend the 1118 permissions of a given user. Another major distinction between the 1119 additional and alternate file access control mechanisms is that any 1120 alternate mechanism must be disabled after the file permission bits 1121 are changed with a chmod. Additional mechanisms do not need to be 1122 disabled when a chmod is done. 1124 14.3. NFSv4 ACLs vs. POSIX-draft ACLs 1126 The goal of both ACL models is similar in that we want to be able to 1127 give the owner of the file more fine grained access control than is 1128 available with the file permission bits. Much like POSIX draft ACLs, 1129 NFSv4 ACLs are made up of multiple Access Control Entries (ACEs), but 1130 the similarities don't go much further. 1132 One major difference between POSIX draft and NFSv4 is that NFSv4 ACLs 1133 have two types of ACEs that play a role in access checking. Those 1134 two types are ALLOW and DENY. One important thing to note about this 1135 distinction is that in POSIX draft ACLs, a single entry defines what 1136 is allowed and also what is denied for the user or group that the 1137 entry applies to. NFSv4 ACLs separate what is allowed and what is 1138 denied by having the distinct ALLOW and DENY types of ACEs. The 1139 importance of this is that a user shouldn't infer from any single 1140 NFSv4 ACE that defines some set of permissions whether or not the 1141 permissions that weren't defined in that ACE are allowed or denied. 1142 This leads us to have to look at the ACL as a whole in order to 1143 determine a user's access. 1145 For instance, in the following example, the first "bob@sun.com" entry 1146 defines the capability for user "bob@sun.com" regarding 1147 ACE4_READ_DATA, but you cannot infer from that entry whether 1148 "bob@sun.com" is granted ACE4_WRITE_DATA or not. One must continue 1149 through the ACL to see what the other capabilities are. 1151 bob@sun.com:ACE4_READ_DATA::ALLOW 1153 bob@sun.com:ACE4_WRITE_DATA::ALLOW 1155 GROUP@:ACE4_EXECUTE:ACE4_IDENTIFIER_GROUP:DENY 1157 bob@sun.com:ACE4_EXECUTE::ALLOW 1159 This example also illustrates a couple of other differences between 1160 the two models. The first difference to be noted is that the 1161 ordering of the ACEs is different from what is typical with POSIX- 1162 draft ACLs. POSIX-draft ACLs have a defined ordering of the ACEs 1163 which is as follows: owner, supplemental users, owning group, 1164 supplemental groups, and other. This ordering is maintained by the 1165 kernel and cannot be changed by the user. With NFSv4 ACLs, there is 1166 no rigid order of the ACEs and the order is user defined. The second 1167 difference that this example illustrates is that there is no MASK_OBJ 1168 or mask entry in this ACL. This is because NFSv4 ACLs have no notion 1169 of a mask. 1171 NFSv4 ACLs go beyond the ability to define access with regard to the 1172 standard read, write and execute/search permissions and allows the 1173 user to set ACLs to define file control permissions (i.e. - the 1174 ability to allow or deny a user the ability to write the ACL or 1175 change the owner). The model also allows inheriting both standard 1176 and file control permissions to newly created files. 1178 14.4. NFSv4 ACLs vs. POSIX 1180 In various other vendors' implementations of NFSv4 ACLs, they have 1181 taken a chmod to mean the setting of a six member ACL, therefore 1182 throwing away the ACL and replacing it with six ACEs which reflect 1183 the mode. The user feedback on this behavior has been unfavorable. 1184 Some have gone as far as to say that it is unacceptable. We presume 1185 the dissatisfaction comes from a user spending time crafting an ACL 1186 only to get it stomped by a later chmod. Considering how many 1187 applications use chmod, we should not follow this behavior. In 1188 addition, security problems can arise if any explicit DENY ACEs are 1189 automatically removed as the result of a chmod (as shown in the 1190 example below). 1192 We believe it is a requirement to preserve an object's ACL upon 1193 chmod. 1195 A DENY type of ACE is considered to be an additional file access 1196 control mechanism, since it can only further restrict permissions. 1197 By categorizing DENY ACEs as additional, we have the ability to be 1198 able to keep the DENY ACEs without modification, except for on the 1199 abstract entities "OWNER@", "GROUP@" and "EVERYONE@" (see section 1200 Section 5.3 for further explanation). 1202 The importance of classifying DENY ACEs as a additional file access 1203 control mechanism is best shown in the following example: 1205 Suppose we have a file with the following ACL: 1207 www@sun.com:ACE4_READ_DATA::DENY 1209 OWNER@:::DENY 1211 OWNER@:::ALLOW 1213 GROUP@::ACE4_IDENTIFIER_GROUP:DENY 1215 GROUP@::ACE4_IDENTIFIER_GROUP:ALLOW 1217 EVERYONE@:::DENY 1219 EVERYONE@:::ALLOW 1221 We require the ability to keep the "www@sun.com:ACE4_READ_DATA::DENY" 1222 ACE in the event of a chmod so that "www@sun.com"'s permissions do 1223 not get elevated by the deletion of the ACE upon execution of chmod. 1225 The ALLOW type of ACE is considered to be an alternate file access 1226 control mechanism because it can further extend the permissions of a 1227 user. As previously mentioned, POSIX states that alternate 1228 mechanisms must be disabled at the time of chmod. This is different 1229 from requiring the deletion of any alternate mechanisms, and allows 1230 us to preserve the ACL. See Paragraph 1.5 in Section 5.3. 1232 14.5. umask Considerations 1234 The umask is used by UNIX operating system users to affect or mask 1235 down the file permission bits of newly created files. umask is not 1236 part of the NFS version 4 protocol. Instead, it is an entirely 1237 client-side concept. 1239 umask can be briefly described as an attribute of a process which is 1240 a set of bits that are not to be set in the mode bits of a newly 1241 created file. If a process creates a new file via the open() system 1242 call, with an octal mode of 0777, and the process has a umask of 1243 0022, the resulting file would have an octal mode attribute of 0755. 1245 On client implementations that implement the concept of a umask, 1246 NFSv4 client implementations SHOULD apply the umask on newly created 1247 files, whether or not a newly created file will be affected by 1248 inheritable ACEs in the parent directory. 1250 15. Normative References 1252 [POSIX] "The Open Group Base Specifications Issue 6, IEEE Std 1253 1003.1, 2004 Edition", IEEE STD. 1003.1, January 2004. 1255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1256 Requirement Levels", BCP 14, RFC 2119, March 1997. 1258 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 1259 Beame, C., Eisler, M., and D. Noveck, "Network File System 1260 (NFS) version 4 Protocol", RFC 3530, STD 1, April 2003. 1262 Authors' Addresses 1264 Sam Falkner 1265 Sun Microsystems, Inc. 1266 500 Eldorado Blvd. 1267 MS: UBRM05-171 1268 Broomfield, CO 80021 1269 USA 1271 Email: sam.falkner@sun.com 1273 Lisa Week 1274 Sun Microsystems, Inc. 1275 500 Eldorado Blvd. 1276 MS: UBRM05-171 1277 Broomfield, CO 80021 1278 USA 1280 Email: lisa.week@sun.com 1282 Intellectual Property Statement 1284 The IETF takes no position regarding the validity or scope of any 1285 Intellectual Property Rights or other rights that might be claimed to 1286 pertain to the implementation or use of the technology described in 1287 this document or the extent to which any license under such rights 1288 might or might not be available; nor does it represent that it has 1289 made any independent effort to identify any such rights. Information 1290 on the procedures with respect to rights in RFC documents can be 1291 found in BCP 78 and BCP 79. 1293 Copies of IPR disclosures made to the IETF Secretariat and any 1294 assurances of licenses to be made available, or the result of an 1295 attempt made to obtain a general license or permission for the use of 1296 such proprietary rights by implementers or users of this 1297 specification can be obtained from the IETF on-line IPR repository at 1298 http://www.ietf.org/ipr. 1300 The IETF invites any interested party to bring to its attention any 1301 copyrights, patents or patent applications, or other proprietary 1302 rights that may cover technology that may be required to implement 1303 this standard. Please address the information to the IETF at 1304 ietf-ipr@ietf.org. 1306 Disclaimer of Validity 1308 This document and the information contained herein are provided on an 1309 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1310 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1311 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1312 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1313 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1314 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1316 Copyright Statement 1318 Copyright (C) The Internet Society (2006). This document is subject 1319 to the rights, licenses and restrictions contained in BCP 78, and 1320 except as set forth therein, the authors retain all their rights. 1322 Acknowledgment 1324 Funding for the RFC Editor function is currently provided by the 1325 Internet Society.