idnits 2.17.1 draft-falkner-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 1278. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1262. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1268. ** 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 (October 14, 2005) is 6768 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: April 17, 2006 Sun Microsystems, Inc. 5 October 14, 2005 7 NFS Version 4 ACLs 8 draft-falkner-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 April 17, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 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 . . . . . . . . . . . . . 18 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 has is traditionally associated with the UNIX 158 mode bits, "setuid"/"setgid"/"sticky" (MODE4_SUID/MODE4_SGID/ 159 MODE4_SVTX), are not defined to be part of the ACL. Other 160 information that can also affect file permissions, such as the file's 161 owner and owning group are also not defined to be part of the ACL. 162 In other words, from looking at an ACL, a user will be unable to tell 163 who the owner and owning group of a file is. This is because of the 164 special 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 } 338 } 339 } 340 } 341 } 342 } 343 return mode | (old_mode & (SUID | SGID | SVTX)) 345 5.2. How should a mode given in the arguments to CREATE or OPEN affect 346 an inherited ACL? 348 The goal of implementing ACL inheritance is for newly created objects 349 to inherit the ACLs they were intended to inherit, but without 350 disregarding the mode that is given with the arguments to the CREATE 351 or OPEN operations. The general algorithm is as follows: 353 1. Form an ACL on the newly created object that is the concatenation 354 of all inheritable ACEs from its parent directory. Note that 355 there may be zero inheritable ACEs; thus, an object may start 356 with an empty ACL. 358 This is self explanatory. If, for example, a new non-directory 359 file is being created, ACEs with the flag of 360 ACE4_FILE_INHERIT_ACE will be considered inheritable. 362 2. For each ACE in the new ACL, adjust its flags if necessary, and 363 possibly create two ACEs in place of one. 365 This will be discussed in detail below. 367 3. Apply the algorithm for applying a mode to a file/directory with 368 and existing ACL on the new object as described in Section 5.3, 369 using the mode that is to be used for file creation. 371 This ensures that the mode is honored. 373 Step 2 above is necessary to honor the intent of the inheritance- 374 related flags. It also is intended to preserve information about the 375 original inheritable ACEs in the case that they will be modified by 376 other steps. Paragraph 2 is detailed in the following algorithm: 378 1. If the ACE4_NO_PROPAGATE_INHERIT_ACE is set, or the type of the 379 file is something other than "directory", then clear the 380 following flags: 382 ACE4_NO_PROPAGATE_INHERIT_ACE 384 ACE4_FILE_INHERIT_ACE 385 ACE4_DIRECTORY_INHERIT_ACE 387 ACE4_INHERIT_ONLY_ACE 389 Continue on to the next ACE. 391 2. If the type of file is "directory" and ACE4_FILE_INHERIT_ACE is 392 set and ACE4_DIRECTORY_INHERIT_ACE is NOT set, then we ensure 393 that ACE4_INHERIT_ONLY_ACE is set. Continue on to the next ACE. 394 Otherwise: 396 3. If the type of the ACE is neither ALLOW nor DENY, then continue 397 on to the next ACE. 399 4. Copy the original ACE into a second, adjacent ACE. 401 5. On the first ACE, ensure that ACE4_INHERIT_ONLY_ACE is set. 403 6. On the second ACE, clear the following flags: 405 ACE4_NO_PROPAGATE_INHERIT_ACE 407 ACE4_FILE_INHERIT_ACE 409 ACE4_DIRECTORY_INHERIT_ACE 411 ACE4_INHERIT_ONLY_ACE 413 7. On the second ACE, if the type field is ALLOW, an implementation 414 MAY clear the following mask bits: 416 ACE4_WRITE_ACL 418 ACE4_WRITE_OWNER 420 5.3. What should happen to an existing ACL if a mode is applied to the 421 file/directory? 423 An existing ACL can mean two things in this context. One, that a 424 file/directory already exists and it has an ACL. Two, that a 425 directory has inheritable ACEs that will make up the ACL for any new 426 files or directories created therein. 428 The high-level goal of the behavior when a mode is set on a file with 429 an existing ACL is to take the new mode into account, without needing 430 to disregard a pre-existing ACL. 432 When a mode is applied to an object, e.g. via SETATTR or CREATE/OPEN, 433 the ACL must be modified to accommodate the mode. 435 1. The ACL is traversed, one ACE at a time. For each ACE: 437 1. If the type of the ACE is neither ALLOW nor DENY, the ACE is 438 left unchanged. Continue to the next ACE. 440 2. If the ACE4_INHERIT_ONLY_ACE flag is set on the ACE, it is 441 left unchanged. Continue to the next ACE. 443 3. If either or both of ACE4_FILE_INHERIT_ACE or 444 ACE4_DIRECTORY_INHERIT_ACE are set: 446 1. A copy of the ACE is made, and placed in the ACL 447 immediately following the current ACE. 449 2. In the first ACE, the flag ACE4_INHERIT_ONLY_ACE is set. 451 3. In the second ACE, the following flags are cleared: 453 ACE4_FILE_INHERIT_ACE 455 ACE4_DIRECTORY_INHERIT_ACE 457 ACE4_NO_PROPAGATE_INHERIT_ACE 459 The algorithm continues on with the second ACE. 461 4. If the "who" field is one of the following: 463 OWNER@ 465 GROUP@ 467 EVERYONE@ 469 then the following mask bits are cleared: 471 ACE4_READ_DATA 473 ACE4_LIST_DIRECTORY 475 ACE4_WRITE_DATA 477 ACE4_ADD_FILE 479 ACE4_APPEND_DATA 480 ACE4_ADD_SUBDIRECTORY 482 ACE4_EXECUTE 484 At this point, we proceed to the next ACE. 486 5. Otherwise, if the "who" field did not match one of OWNER@, 487 GROUP@, or EVERYONE@, the following two steps SHOULD be 488 performed. 490 1. If the type of the ACE is ALLOW, we check the preceding 491 ACE (if any). If it does not meet all of the following 492 criteria: 494 1. The type field is DENY. 496 2. The who field is the same as the current ACE. 498 3. The flag bit ACE4_IDENTIFIER_GROUP is the same as it 499 is in the current ACE, and no other flag bits are 500 set. 502 4. The mask bits are a subset of the mask bits of the 503 current ACE, and are also a subset of the following: 505 ACE4_READ_DATA 507 ACE4_LIST_DIRECTORY 509 ACE4_WRITE_DATA 511 ACE4_ADD_FILE 513 ACE4_APPEND_DATA 515 ACE4_ADD_SUBDIRECTORY 517 ACE4_EXECUTE 519 then an ACE of type DENY, with a who equal to the current 520 ACE, flag bits equal to ( & 521 ACE4_IDENTIFIER_GROUP), and no mask bits, is prepended. 523 2. The following modifications are made to the prepended 524 ACE. The intent is to mask the following ACE to disallow 525 ACE4_READ_DATA, ACE4_WRITE_DATA, ACE4_APPEND_DATA, or 526 ACE4_EXECUTE, based upon the group permissions of the new 527 mode. As a special case, if the ACE matches the current 528 owner of the file, the owner bits are used, rather than 529 the group bits. This is reflected in the algorithm 530 below. 532 Let there be three bits defined: 534 #define READ 04 535 #define WRITE 02 536 #define EXEC 01 538 Let "amode" be the new mode, left-shifted three 539 bits, in order to have the group permission bits 540 placed in the three low order bits of amode, 541 i.e. amode = mode >> 3 543 If ACE4_IDENTIFIER_GROUP is not set in the flags, 544 and the "who" field of the ACE matches the owner 545 of the file, we shift amode three more bits, in 546 order to have the owner permission bits placed in 547 the three low order bits of amode: 549 amode = amode >> 3 551 amode is now used as follows: 553 If ACE4_READ_DATA is set on the current ACE: 554 If READ is set on amode: 555 ACE4_READ_DATA is cleared on the prepended ACE 556 else: 557 ACE4_READ_DATA is set on the prepended ACE 559 If ACE4_WRITE_DATA is set on the current ACE: 560 If WRITE is set on amode: 561 ACE4_WRITE_DATA is cleared on the prepended ACE 562 else: 563 ACE4_WRITE_DATA is set on the prepended ACE 565 If ACE4_APPEND_DATA is set on the current ACE: 566 If WRITE is set on amode: 567 ACE4_APPEND_DATA is cleared on the prepended ACE 568 else: 569 ACE4_APPEND_DATA is set on the prepended ACE 571 If ACE4_EXECUTE is set on the current ACE: 572 If EXEC is set on amode: 573 ACE4_EXECUTE is cleared on the prepended ACE 574 else: 576 ACE4_EXECUTE is set on the prepended ACE 578 2. If there are at least six ACEs, the final six ACEs are examined. 579 If they are not equal to the following ACEs: 581 A1) OWNER@:::DENY 582 A2) OWNER@:ACE4_WRITE_ACL/ACE4_WRITE_OWNER/ 583 ACE4_WRITE_ATTRIBUTES/ 584 ACE4_WRITE_NAMED_ATTRIBUTES::ALLOW 585 A3) GROUP@::ACE4_IDENTIFIER_GROUP:DENY 586 A4) GROUP@::ACE4_IDENTIFIER_GROUP:ALLOW 587 A5) EVERYONE@:ACE4_WRITE_ACL/ACE4_WRITE_OWNER/ 588 ACE4_WRITE_ATTRIBUTES/ 589 ACE4_WRITE_NAMED_ATTRIBUTES::DENY 590 A6) EVERYONE@:ACE4_READ_ACL/ACE4_READ_ATTRIBUTES/ 591 ACE4_READ_NAMED_ATTRIBUTES/ 592 ACE4_SYNCHRONIZE::ALLOW 594 Then six ACEs matching the above are appended. 596 3. The final six ACEs are adjusted according to the incoming mode. 598 /* octal constants for the mode bits */ 600 RUSR = 0400 601 WUSR = 0200 602 XUSR = 0100 603 RGRP = 0040 604 WGRP = 0020 605 XGRP = 0010 606 ROTH = 0004 607 WOTH = 0002 608 XOTH = 0001 610 If RUSR is set: set ACE4_READ_DATA in A2 611 else: set ACE4_READ_DATA in A1 612 If WUSR is set: set ACE4_WRITE_DATA and 613 ACE4_APPEND_DATA in A2 614 else: set ACE4_WRITE_DATA and 615 ACE4_APPEND_DATA in A1 616 If XUSR is set: set ACE4_EXECUTE in A2 617 else: set ACE4_EXECUTE in A1 618 If RGRP is set: set ACE4_READ_DATA in A4 619 else: set ACE4_READ_DATA in A3 620 If WGRP is set: set ACE4_WRITE_DATA and 621 ACE4_APPEND_DATA in A4 622 else: set ACE4_WRITE_DATA and 623 ACE4_APPEND_DATA in A3 624 If XGRP is set: set ACE4_EXECUTE in A4 625 else: set ACE4_EXECUTE in A3 626 If ROTH is set: set ACE4_READ_DATA in A6 627 else: set ACE4_READ_DATA in A5 628 If WOTH is set: set ACE4_WRITE_DATA and 629 ACE4_APPEND_DATA in A6 630 else: set ACE4_WRITE_DATA and 631 ACE4_APPEND_DATA in A5 632 If XOTH is set: set ACE4_EXECUTE in A6 633 else: set ACE4_EXECUTE in A5 635 5.4. What should happen if both mode and ACL are given to SETATTR? 637 The only reason that a mode and ACL should be set in the same SETATTR 638 is if the user wants to set the SUID, SGID and SVTX bits along with 639 setting the permissions by means of an ACL. There is still no way to 640 enforce which order the attributes will be set in, and it is likely 641 that different orders of operations will produce different results. 643 In the long run, the best solution would be the ability to set SUID, 644 SGID and SVTX bits independent of the mode, but since we don't have 645 this ability in NFS version 4.0, this is what we recommend. 647 5.4.1. Client Side Recommendations 649 If an application needs to enforce a certain behavior, it is 650 recommended that the client implementations set mode and ACL in 651 separate SETATTR requests. This will produce consistent and expected 652 results. 654 If an application wants to set SUID, SGID and SVTX bits and an ACL, 655 we recommend: 657 In the first SETATTR, set the mode with SUID, SGID and SVTX bits 658 as desired and all other bits with a value of 0. 660 In a following SETATTR (preferably in the same COMPOUND) set the 661 ACL. 663 5.4.2. Server Side Recommendations 665 If both mode and ACL are given to SETATTR, server implementations 666 should verify that the mode and ACL don't conflict, i.e. the mode 667 computed from the given ACL must be the same as the given mode, 668 excluding the SUID, SGID and SVTX bits. The algorithm for assigning 669 a new mode based on the ACL can be used. This is described in 670 Section 5.1. If a server receives a request to set both mode and 671 ACL, but the two conflict, the server should return NFS4ERR_INVAL. 673 6. Deficiencies in a Mode Representation of an ACL 675 As mentioned in Section 5.1, the representation of the mode is 676 deterministic, but not guaranteed to be accurate. The mode bits 677 potentially convey a more restrictive permission than what will 678 actually be granted via the ACL. 680 Given the following ACL of two ACEs: 682 GROUP@:ACE4_READ_DATA/ACE4_WRITE_DATA/ACE4_EXECUTE: 683 ACE4_IDENTIFIER_GROUP:ALLOW 684 EVERYONE@:ACE4_READ_DATA/ACE4_WRITE_DATA/ACE4_EXECUTE::DENY 686 we would compute a mode of 0070. However, it is possible, even 687 likely, that the owner might be a member of the object's owning 688 group, and thus, the owner would be granted read, write, and execute 689 access to the object. This would conflict with the mode of 0070, 690 where an owner would be denied this access. 692 The only way to overcome this deficiency would be to determine 693 whether the object's owner is a member of the object's owning group. 694 This is difficult, but worse, on a POSIX or any UNIX-like system, it 695 is a process' membership in a group that is important, not a user's. 696 Thus, any fixed mode intended to represent the above ACL can be 697 incorrect. 699 Example: administrative databases (possibly /etc/passwd and /etc/ 700 group) indicate that the user "bob" is a member of the group "staff". 701 An object has the ACL given above, is owned by "bob", and has an 702 owning group of "staff". User "bob" has logged in to the system, and 703 thus processes have been created owned by "bob" and having membership 704 in group "staff". 706 A mode representation of the above ACL could thus be 0770, due to 707 user "bob" having membership in group "staff". Now, the 708 administrative databases are changed, such that user "bob" is no 709 longer in group "staff". User "bob" logs in to the system again, and 710 thus more processes are created, this time owned by "bob" but NOT in 711 group "staff". 713 A mode of 0770 is inaccurate for processes not belonging to group 714 "staff". But even if the mode of the file were proactively changed 715 to 0070 at the time the group database was edited, mode 0070 would be 716 inaccurate for the pre-existing processes owned by user "bob" and 717 having membership in group "staff". 719 7. Access Control Semantics 721 The NFS version 4 specification [RFC3530] defines how an ACL is 722 interpreted, and it states that the access is undefined if you get 723 through the entire ACL and haven't encountered an ALLOW or DENY ACE 724 for the requester. 726 We now recommend that if you fall through the ACL, access is denied. 727 This allows the behavior to be clearly defined, and consistent across 728 implementations. In fact, there is precedence for this behavior in 729 current implementations. 731 It is convenient that [RFC3530] gave implementations flexibility by 732 leaving the access undefined, but the flexibility is still present 733 given that there have always been security policies independent of 734 file permissions. Servers can have other security policies in place, 735 and in those cases, access will be decided outside of what is defined 736 in the ACL. 738 Examples of security policies that can be in place outside of what is 739 defined (or not defined) in the ACL are: 741 1. The owner of the file will always be granted ACE4_WRITE_ACL and 742 ACE4_READ_ACL permissions. 744 2. The ACL may say that an entity is to be granted ACE4_WRITE_DATA 745 permission, but the file system is mounted read only. 747 For multiple reasons, including the one listed above, client 748 implementations are recommended not to do their own access checking. 749 All access checking should be done on the server. 751 8. Inheritance and turning it off 753 The inheritance of access permissions may be problematic if a user 754 cannot prevent their file from inheriting unwanted permissions. For 755 example, a user, "samf", sets up a shared project directory to be 756 used by everyone working on Project Foo. "lisagab" is a part of 757 Project Foo, but is working on something that should not be seen by 758 anyone else. How can "lisagab" make sure that any new files that she 759 creates in this shared project directory do not inherit anything that 760 could compromise the security of her work? 762 More relevant to the implementors of NFS version 4 clients and 763 servers is the question of how to communicate the fact that user, 764 "lisagab", doesn't want any permissions to be inherited to her newly 765 created file or directory. 767 To do this, implementors should standardize on what the behavior of 768 CREATE and OPEN must be if: 770 1. just mode is given 772 In this case, inheritance will take place, but the mode will be 773 applied to the inherited ACL as described in Section 5.1, thereby 774 modifying the ACL. 776 2. just ACL is given 778 In this case, inheritance will not take place, and the ACL as 779 defined in the CREATE or OPEN will be set without modification. 781 3. both mode and ACL are given 783 In this case, implementors should verify that the mode and ACL 784 don't conflict, i.e. the mode computed from the given ACL must be 785 the same as the given mode. The algorithm for assigning a new 786 mode based on the ACL can be used. This is described in 787 Section 5.1) If a server receives a request to set both mode and 788 ACL, but the two conflict, the server should return 789 NFS4ERR_INVAL. If the mode and ACL don't conflict, inheritance 790 will not take place and both, the mode and ACL, will be set 791 without modification. 793 4. neither mode nor ACL are given 795 In this case, inheritance will take place and no modifications to 796 the ACL will happen. It is worth noting that if no inheritable 797 ACEs exist on the parent directory, the file will be created with 798 an empty ACL, thus granting no accesses. 800 9. EVERYONE@: What does it mean? 802 The NFS version 4 specification [RFC3530] refers to the "EVERYONE@" 803 special identifier as meaning "The world". This is confusing because 804 there are a couple of different ways to interpret the wording. These 805 different interpretations are problematic and it would be 806 advantageous for implementors to standardize on a single meaning. 808 The different interpretations are as follows: 810 1. "EVERYONE@" is equivalent to the UNIX "other" entity, which by 811 definition does not include the owner or owning group of the 812 file. 814 2. "EVERYONE@" literally means everyone, including the file's owner 815 and owning group. 817 The goal of standardizing on what "EVERYONE@" means may be best 818 expressed from a user's point of view. A user of NFS version 4 ACLs 819 should expect that setting an ACL such as the following will have the 820 same affect regardless of what vendor's implementation they are 821 using. 823 EVERYONE@:ACE4_READ_DATA::ALLOW 825 Examples of how the different interpretations could cause different 826 behaviors are as follows: 828 If we take interpretation #1 where "EVERYONE@" is equivalent to the 829 UNIX "other" entity and the owner or a user in the owning group 830 attempt to access the file for reading, they would be denied. This 831 is because we fell through the ACL and didn't find any entries 832 specifying the permissions for OWNER@ and GROUP@ (see Section 7). 834 If we take interpretation #2 where "EVERYONE@" is literally everyone, 835 including the owner and owning group, and the owner or a user in the 836 owning group attempt to access the file for reading, they would be 837 allowed. 839 The first interpretation is understandable, but does not follow the 840 intent of the special identifier. Therefore, it is recommended that 841 implementors use "EVERYONE@" to mean literally everyone. 843 10. Access Mask Bit Discussion 845 The purpose of this section is to clarify the meaning of the 846 different access mask bits. This will state the operations and a 847 description of what the access mask bit controls. A major portion of 848 the descriptions were taken from [RFC3530]. The following is a list 849 of access mask bits that can be set on an ACE: 851 ACE4_READ_DATA 852 Operation(s) affected: 853 READ 854 OPEN 855 Discussion: 856 Permission to read the data of the file. 858 ACE4_LIST_DIRECTORY 859 Operation(s) affected: 860 READDIR 861 Discussion: 862 Permission to list the contents of a directory. 864 ACE4_WRITE_DATA 865 Operation(s) affected: 866 WRITE 867 OPEN 868 Discussion: 869 Permission to modify a file's data anywhere in 870 the file's offset range. This includes the 871 ability to write to any arbitrary offset and as 872 a result to grow the file. 874 ACE4_ADD_FILE 875 Operation(s) affected: 876 CREATE 877 OPEN 878 Discussion: 879 Permission to add a new file in a directory. 880 The CREATE operation is affected when 881 nfs_ftype4 is NF4LNK, NF4BLK, NF4CHR, NF4SOCK, 882 or NF4FIFO. (NF4DIR is not listed because it is 883 covered by ACE4_ADD_SUBDIRECTORY.) OPEN is 884 affected when used to create a regular file. 886 ACE4_APPEND_DATA 887 Operation(s) affected: 888 WRITE 889 OPEN 891 Discussion: 892 The ability to modify a file's data, but only 893 starting at EOF. See Section 11 for further 894 discussion on the relationship between 895 ACE4_APPEND_DATA and ACE4_WRITE_DATA. 897 ACE4_ADD_SUBDIRECTORY 898 Operation(s) affected: 899 CREATE 900 Discussion: 901 Permission to create a subdirectory in a 902 directory. The CREATE operation is affected 903 when nfs_ftype4 is NF4DIR. 905 ACE4_READ_NAMED_ATTRS 906 Operation(s) affected: 907 OPENATTR 908 Discussion: 909 Permission to lookup the named attributes directory. 910 OPENATTR is affected when it is not used to 911 create a named attribute directory. This is 912 when 1.) createdir is TRUE, but a named 913 attribute directory already exists, or 2.) 914 createdir is FALSE. 916 ACE4_WRITE_NAMED_ATTRS 917 Operation(s) affected: 918 OPENATTR 919 Discussion: 920 Permission to create a named attribute directory. 921 OPENATTR is affected when it is used to create 922 a named attribute directory. This is when 923 createdir is TRUE and no named attribute 924 directory exists. The ability to check whether 925 or not a named attribute directory exists 926 depends on the ability to look it up, 927 therefore, users also need the 928 ACE4_READ_NAMED_ATTRS permission in order to 929 create a named attribute directory. 931 ACE4_EXECUTE 932 Operation(s) affected: 933 LOOKUP 934 Discussion: 935 Permission to execute a file or traverse/search 936 a directory. 938 ACE4_DELETE_CHILD 939 Operation(s) affected: 940 REMOVE 941 Discussion: 942 Permission to delete a file or directory within 943 a directory. 945 ACE4_READ_ATTRIBUTES 946 Operation(s) affected: 947 GETATTR of file system object attributes 948 Discussion: 949 The ability to read basic attributes (non-ACLs) 950 of a file. 952 ACE4_WRITE_ATTRIBUTES 953 Operation(s) affected: 954 SETATTR of time_access_set, time_backup, 955 time_create, time_modify_set 956 Discussion: 957 Permission to change the times associated with 958 a file or directory to an arbitrary value. 960 ACE4_DELETE 961 Operation(s) affected: 962 REMOVE 963 Discussion: 964 Permission to delete the file or directory. 966 ACE4_READ_ACL 967 Operation(s) affected: 968 GETATTR of acl 969 Discussion: 970 Permission to read the ACL. 972 ACE4_WRITE_ACL 973 Operation(s) affected: 974 SETATTR of acl and mode 975 Discussion: 976 Permission to write the acl and mode attributes. 978 ACE4_WRITE_OWNER 979 Operation(s) affected: 980 SETATTR of owner and owner_group 981 Discussions: 982 Permission to write the owner and owner_group 983 attributes. On UNIX systems, this is the 984 ability to execute chown or chgrp. 986 ACE4_SYNCHRONIZE 987 Operation(s) affected: 988 NONE 989 Discussion: 990 Permission to access file locally at the server with 991 synchronized reads and writes. 993 11. Append Only Behavior 995 The NFS version 4 ACL model allows for the notion of append-only 996 files, by allowing ACE4_APPEND_DATA and denying ACE4_WRITE_DATA to 997 the same user or group. 999 If a file has an ACL such as the one described above and a WRITE 1000 request is made for somewhere other than EOF, the server SHOULD 1001 return NFS4ERR_ACCESS. 1003 12. ACE4_DELETE/ACE4_DELETE_CHILD Behavior 1005 There are two separate access mask bits that govern the ability to 1006 delete a file: ACE4_DELETE and ACE4_DELETE_CHILD. ACE4_DELETE is 1007 intended to be specified by the ACL for the object to be deleted, and 1008 ACE4_DELETE_CHILD is intended to be specified by the ACL of the 1009 parent directory. 1011 Server implementations SHOULD grant or deny permission to delete 1012 based on the following algorithm. 1014 if ACE4_EXECUTE is denied by the parent directory ACL: 1015 deny delete 1016 else if ACE4_EXECUTE is unspecified by the parent directory ACL: 1017 deny delete 1018 else if ACE4_DELETE is allowed by the target object ACL: 1019 allow delete 1020 else if ACE4_DELETE_CHILD is allowed by the parent directory ACL: 1021 allow delete 1022 else if ACE4_DELETE_CHILD is denied by the parent directory ACL: 1023 deny delete 1024 else if ACE4_ADD_FILE is allowed by the parent directory ACL: 1025 allow delete 1026 else 1027 deny delete 1029 13. ACE4_ADD_FILE and ACE4_ADD_SUBDIRECTORY 1031 As specified in Section 10, the permission granted by ACE4_WRITE_DATA 1032 is a superset of the permission granted by ACE4_APPEND_DATA. With 1033 directories, ACE4_WRITE_DATA is analogous to ACE4_ADD_FILE, and 1034 ACE4_APPEND_DATA is analogous to ACE4_ADD_SUBDIRECTORY. 1036 A question this raises is whether ACE4_ADD_FILE is a superset of 1037 ACE4_ADD_SUBDIRECTORY. In other words, does the granting of 1038 ACE4_ADD_FILE imply the permission to create a subdirectory? 1040 It is proposed that ACE4_ADD_FILE does not imply 1041 ACE4_ADD_SUBDIRECTORY. 1043 14. POSIX Considerations 1045 Disclaimer: This section is relevant to platforms with requirements 1046 to be POSIX compliant. These platforms are typically UNIX based, and 1047 the following discussion will be heavily biased toward those 1048 platforms. 1050 14.1. Background Information 1052 The standard POSIX (See [POSIX]) file access control mechanism uses 1053 the file permission bits contained in the file mode. The file 1054 permission bits are used to determine whether a process has read, 1055 write or execute/search permission to a file based on which class the 1056 process is in; file owner, file group or file other class. 1058 A process is in the file owner class if the effective user ID of the 1059 process matches the user ID of the file. A process is in the file 1060 group class if the process is not in the file owner class and if the 1061 effective group ID or one of the supplementary group IDs of the 1062 process matches the group ID associated with the file. A process is 1063 in the file other class if the effective user ID of the process is 1064 not in the file owner class or the file group class. 1066 The POSIX spec says that a process is in one and only one class, 1067 therefore, the access permissions that exist for that class are the 1068 only ones that will be considered when doing access checks. 1070 14.2. Additional and Alternate File Access Control Mechanisms 1072 In addition to the standard file access control mechanism, the POSIX 1073 spec allows for additional and alternate file access control 1074 mechanisms. According to Section 4.4 of the POSIX spec, a file can 1075 have one or both mechanisms in place. 1077 The additional file access control mechanism is defined to be layered 1078 upon the file permission bits, but they can only further restrict the 1079 standard file access control mechanism. The alternate file access 1080 control mechanism is defined to be independent of the file permission 1081 bits and which if enabled on a file may either restrict or extend the 1082 permissions of a given user. Another major distinction between the 1083 additional and alternate file access control mechanisms is that any 1084 alternate mechanism must be disabled after the file permission bits 1085 are changed with a chmod. Additional mechanisms do not need to be 1086 disabled when a chmod is done. 1088 14.3. NFSv4 ACLs vs. POSIX-draft ACLs 1090 The goal of both ACL models is similar in that we want to be able to 1091 give the owner of the file more fine grained access control than is 1092 available with the file permission bits. Much like POSIX draft ACLs, 1093 NFSv4 ACLs are made up of multiple Access Control Entries (ACEs), but 1094 the similarities don't go much further. 1096 One major difference between POSIX draft and NFSv4 is that NFSv4 ACLs 1097 have two types of ACEs that play a role in access checking. Those 1098 two types are ALLOW and DENY. One important thing to note about this 1099 distinction is that in POSIX draft ACLs, a single entry defines what 1100 is allowed and also what is denied for the user or group that the 1101 entry applies to. NFSv4 ACLs separate what is allowed and what is 1102 denied by having the distinct ALLOW and DENY types of ACEs. The 1103 importance of this is that a user shouldn't infer from any single 1104 NFSv4 ACE that defines some set of permissions whether or not the 1105 permissions that weren't defined in that ACE are allowed or denied. 1106 This leads us to have to look at the ACL as a whole in order to 1107 determine a user's access. 1109 For instance, in the following example, the first "bob@sun.com" entry 1110 defines the capability for user "bob@sun.com" regarding 1111 ACE4_READ_DATA, but you cannot infer from that entry whether 1112 "bob@sun.com" is granted ACE4_WRITE_DATA or not. One must continue 1113 through the ACL to see what the other capabilities are. 1115 bob@sun.com:ACE4_READ_DATA::ALLOW 1117 bob@sun.com:ACE4_WRITE_DATA::ALLOW 1119 GROUP@:ACE4_EXECUTE:ACE4_IDENTIFIER_GROUP:DENY 1121 bob@sun.com:ACE4_EXECUTE::ALLOW 1123 This example also illustrates a couple of other differences between 1124 the two models. The first difference to be noted is that the 1125 ordering of the ACEs is different from what is typical with POSIX- 1126 draft ACLs. POSIX-draft ACLs have a defined ordering of the ACEs 1127 which is as follows: owner, supplemental users, owning group, 1128 supplemental groups, and other. This ordering is maintained by the 1129 kernel and cannot be changed by the user. With NFSv4 ACLs, there is 1130 no rigid order of the ACEs and the order is user defined. The second 1131 difference that this example illustrates is that there is no MASK_OBJ 1132 or mask entry in this ACL. This is because NFSv4 ACLs have no notion 1133 of a mask. 1135 NFSv4 ACLs go beyond the ability to define access with regard to the 1136 standard read, write and execute/search permissions and allows the 1137 user to set ACLs to define file control permissions (i.e. - the 1138 ability to allow or deny a user the ability to write the ACL or 1139 change the owner). The model also allows inheriting both standard 1140 and file control permissions to newly created files. 1142 14.4. NFSv4 ACLs vs. POSIX 1144 In various other vendors' implementations of NFSv4 ACLs, they have 1145 taken a chmod to mean the setting of a six member ACL, therefore 1146 throwing away the ACL and replacing it with six ACEs which reflect 1147 the mode. The user feedback on this behavior has been unfavorable. 1148 Some have gone as far as to say that it is unacceptable. We presume 1149 the dissatisfaction comes from a user spending time crafting an ACL 1150 only to get it stomped by a later chmod. Considering how many 1151 applications use chmod, we should not follow this behavior. In 1152 addition, security problems can arise if any explicit DENY ACEs are 1153 automatically removed as the result of a chmod (as shown in the 1154 example below). 1156 We believe it is a requirement to preserve an object's ACL upon 1157 chmod. 1159 A DENY type of ACE is considered to be an additional file access 1160 control mechanism, since it can only further restrict permissions. 1161 By categorizing DENY ACEs as additional, we have the ability to be 1162 able to keep the DENY ACEs without modification, except for on the 1163 abstract entities "OWNER@", "GROUP@" and "EVERYONE@" (see section 1164 Section 5.3 for further explanation). 1166 The importance of classifying DENY ACEs as a additional file access 1167 control mechanism is best shown in the following example: 1169 Suppose we have a file with the following ACL: 1171 www@sun.com:ACE4_READ_DATA::DENY 1173 OWNER@:::DENY 1175 OWNER@:::ALLOW 1177 GROUP@::ACE4_IDENTIFIER_GROUP:DENY 1179 GROUP@::ACE4_IDENTIFIER_GROUP:ALLOW 1181 EVERYONE@:::DENY 1183 EVERYONE@:::ALLOW 1185 We require the ability to keep the "www@sun.com:ACE4_READ_DATA::DENY" 1186 ACE in the event of a chmod so that "www@sun.com"'s permissions do 1187 not get elevated by the deletion of the ACE upon execution of chmod. 1189 The ALLOW type of ACE is considered to be an alternate file access 1190 control mechanism because it can further extend the permissions of a 1191 user. As previously mentioned, POSIX states that alternate 1192 mechanisms must be disabled at the time of chmod. This is different 1193 from requiring the deletion of any alternate mechanisms, and allows 1194 us to preserve the ACL. See Paragraph 1.5 in Section 5.3. 1196 14.5. umask Considerations 1198 The umask is used by UNIX operating system users to affect or mask 1199 down the file permission bits of newly created files. umask is not 1200 part of the NFS version 4 protocol. Instead, it is an entirely 1201 client-side concept. 1203 umask can be briefly described as an attribute of a process which is 1204 a set of bits that are not to be set in the mode bits of a newly 1205 created file. If a process creates a new file via the open() system 1206 call, with an octal mode of 0777, and the process has a umask of 1207 0022, the resulting file would have an octal mode attribute of 0755. 1209 On client implementations that implement the concept of a umask, 1210 NFSv4 client implementations SHOULD apply the umask on newly created 1211 files, whether or not a newly created file will be affected by 1212 inheritable ACEs in the parent directory. 1214 15. Normative References 1216 [POSIX] "The Open Group Base Specifications Issue 6, IEEE Std 1217 1003.1, 2004 Edition", IEEE STD. 1003.1, January 2004. 1219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1220 Requirement Levels", BCP 14, RFC 2119, March 1997. 1222 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 1223 Beame, C., Eisler, M., and D. Noveck, "Network File System 1224 (NFS) version 4 Protocol", RFC 3530, STD 1, April 2003. 1226 Authors' Addresses 1228 Sam Falkner 1229 Sun Microsystems, Inc. 1230 500 Eldorado Blvd. 1231 MS: UBRM05-171 1232 Broomfield, CO 80021 1233 USA 1235 Email: sam.falkner@sun.com 1237 Lisa Week 1238 Sun Microsystems, Inc. 1239 500 Eldorado Blvd. 1240 MS: UBRM05-171 1241 Broomfield, CO 80021 1242 USA 1244 Email: lisa.week@sun.com 1246 Intellectual Property Statement 1248 The IETF takes no position regarding the validity or scope of any 1249 Intellectual Property Rights or other rights that might be claimed to 1250 pertain to the implementation or use of the technology described in 1251 this document or the extent to which any license under such rights 1252 might or might not be available; nor does it represent that it has 1253 made any independent effort to identify any such rights. Information 1254 on the procedures with respect to rights in RFC documents can be 1255 found in BCP 78 and BCP 79. 1257 Copies of IPR disclosures made to the IETF Secretariat and any 1258 assurances of licenses to be made available, or the result of an 1259 attempt made to obtain a general license or permission for the use of 1260 such proprietary rights by implementers or users of this 1261 specification can be obtained from the IETF on-line IPR repository at 1262 http://www.ietf.org/ipr. 1264 The IETF invites any interested party to bring to its attention any 1265 copyrights, patents or patent applications, or other proprietary 1266 rights that may cover technology that may be required to implement 1267 this standard. Please address the information to the IETF at 1268 ietf-ipr@ietf.org. 1270 Disclaimer of Validity 1272 This document and the information contained herein are provided on an 1273 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1274 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1275 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1276 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1277 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1278 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1280 Copyright Statement 1282 Copyright (C) The Internet Society (2005). This document is subject 1283 to the rights, licenses and restrictions contained in BCP 78, and 1284 except as set forth therein, the authors retain all their rights. 1286 Acknowledgment 1288 Funding for the RFC Editor function is currently provided by the 1289 Internet Society.