Network Working Group S. Falkner Internet-Draft L. Week Expires: August 19, 2006 Sun Microsystems, Inc. February 15, 2006 NFS Version 4 ACLs draft-ietf-nfsv4-acls-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 19, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract NFS version 4 (specified in RFC 3530) Access Control Lists (ACLs) provide more fine grained control than previous file permission models, but before the full benefit of the model can be exploited, some changes and clarifications must be made. This document will describe the details that implementors should consider in order to allow implementations to function and interoperate better. Falkner & Week Expires August 19, 2006 [Page 1] Internet-Draft NFS Version 4 ACLs February 2006 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Security Considerations . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Syntax for the Representation of ACLs . . . . . . . . . . . . 6 5. Interaction Between Mode and ACL . . . . . . . . . . . . . . . 7 5.1. What should happen to the mode if a SETATTR of ACL is done? . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. How should a mode given in the arguments to CREATE or OPEN affect an inherited ACL? . . . . . . . . . . . . . . 11 5.3. What should happen to an existing ACL if a mode is applied to the file/directory? . . . . . . . . . . . . . . 12 5.4. What should happen if both mode and ACL are given to SETATTR? . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.4.1. Client Side Recommendations . . . . . . . . . . . . . 17 5.4.2. Server Side Recommendations . . . . . . . . . . . . . 18 6. Deficiencies in a Mode Representation of an ACL . . . . . . . 19 7. Access Control Semantics . . . . . . . . . . . . . . . . . . . 20 8. Inheritance and turning it off . . . . . . . . . . . . . . . . 21 9. EVERYONE@: What does it mean? . . . . . . . . . . . . . . . . 22 10. Access Mask Bit Discussion . . . . . . . . . . . . . . . . . . 23 11. Append Only Behavior . . . . . . . . . . . . . . . . . . . . . 27 12. ACE4_DELETE/ACE4_DELETE_CHILD Behavior . . . . . . . . . . . . 28 13. ACE4_ADD_FILE and ACE4_ADD_SUBDIRECTORY . . . . . . . . . . . 29 14. POSIX Considerations . . . . . . . . . . . . . . . . . . . . . 30 14.1. Background Information . . . . . . . . . . . . . . . . . . 30 14.2. Additional and Alternate File Access Control Mechanisms . 30 14.3. NFSv4 ACLs vs. POSIX-draft ACLs . . . . . . . . . . . . . 30 14.4. NFSv4 ACLs vs. POSIX . . . . . . . . . . . . . . . . . . . 32 14.5. umask Considerations . . . . . . . . . . . . . . . . . . . 33 15. Normative References . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . . . . 35 Falkner & Week Expires August 19, 2006 [Page 2] Internet-Draft NFS Version 4 ACLs February 2006 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Falkner & Week Expires August 19, 2006 [Page 3] Internet-Draft NFS Version 4 ACLs February 2006 2. Security Considerations None. Falkner & Week Expires August 19, 2006 [Page 4] Internet-Draft NFS Version 4 ACLs February 2006 3. Introduction Readers of this document are expected to have basic knowledge of the Network File System (NFS) version 4 protocol [RFC3530]. Familiarity with the NFS version 4 protocol will provide the correct context for the issues discussed in this document. The NFS version 4 protocol defines a standard Access Control List (ACL) model, which to our knowledge, is the first approved standard for ACLs. Prior attempts have been made to standardize ACL models, but none have succeeded. Therefore, there has been a proliferation of ACL models in the computer industry. These multiple models make it close to impossible to interoperate between the wide array of vendors. NFS version 4 ACLs attempt to bridge the gap between the different vendors, allowing them to interoperate. Implementations have been suffering from differing interpretations of the standard. This document attempts to clarify some of the pieces of the NFS version 4 ACL model with the hope that vendors will be able to agree on semantics which will lead to increased ability to interoperate. Falkner & Week Expires August 19, 2006 [Page 5] Internet-Draft NFS Version 4 ACLs February 2006 4. Syntax for the Representation of ACLs Throughout the document the following abbreviations will be used for the ACE type: ALLOW (short for ACE4_ACCESS_ALLOWED_ACE_TYPE) DENY (short for ACE4_ACCESS_DENIED_ACE_TYPE) AUDIT (short for ACE4_SYSTEM_AUDIT_ACE_TYPE) ALARM (short for ACE4_SYSTEM_ALARM_ACE_TYPE) Representation of ACLs in this document will be of the form: ::: Field #1 is the "ACE who" and example values are: OWNER@, GROUP@, lisagab@sun.com, samf@sun.com Field #2 are the "access mask bits" separated with "/" characters and example values are: ACE4_READ_DATA/ACE4_WRITE_DATA Field #3 are the "ACE flags" and example values are: ACE4_FILE_INHERIT_ACE, ACE4_IDENTIFIER_GROUP Field #4 is the "ACE type" and example values are: ALLOW, DENY Falkner & Week Expires August 19, 2006 [Page 6] Internet-Draft NFS Version 4 ACLs February 2006 5. Interaction Between Mode and ACL For client and server implementors alike, a misunderstanding of the interactions between the mode and ACL file attributes is likely to be a cause of problems. The relationship between NFS version 4 modes and ACLs is difficult, but not impossible to specify. Contributing to this is the fact that while there are portions of the mode that ACLs don't specify, it is impossible for a mode to represent all of the information in an ACL. The NFS version 4 mode attribute is based on the UNIX mode bits. Some information that is traditionally associated with the UNIX mode bits, "setuid"/"setgid"/"sticky" (MODE4_SUID/MODE4_SGID/MODE4_SVTX), are not defined to be part of the ACL. Other information that can also affect file permissions, such as the file's owner and owning group are also not defined to be part of the ACL. In other words, from looking at an ACL, a user will be unable to tell who the owner and owning group of a file is. This is because of the special identifiers, OWNER@ and GROUP@. This section will attempt to answer the following questions: 1. What should happen to the mode if a SETATTR of ACL is done? 2. How should a mode given to CREATE or OPEN affect an inherited ACL? 3. What should happen to an existing ACL if a mode is applied to the file/directory? 4. What should happen if both mode and ACL are given to SETATTR? 5.1. What should happen to the mode if a SETATTR of ACL is done? Keeping the mode and ACL attributes synchronized is important, but as mentioned previously, the mode cannot possibly represent all of the information in the ACL. Still, the mode should be modified to represent the access as accurately as possible. The mode is not guaranteed to be accurate and could potentially be more restrictive than the access that would actually be given by the ACL (for more discussion on this topic, see Section 6). Because of this, client implementations are not recommended to not do their own access checks based on the mode of a file. For further information on access checking, see Section 7. The general algorithm to assign a new mode attribute to an object Falkner & Week Expires August 19, 2006 [Page 7] Internet-Draft NFS Version 4 ACLs February 2006 based on a new ACL being set is: 1. Walk through the ACEs in order, looking for ACEs with a "who" value of OWNER@, GROUP@, or EVERYONE@. 2. It is understood that ACEs with a "who" value of OWNER@ affect the *USR bits of the mode, GROUP@ affect *GRP bits, and EVERYONE@ affect *USR, *GRP, and *OTH bits (For more discussion on the EVERYONE@ special identifier see Section 9). 3. If such an ACE specifies ALLOW or DENY for ACE4_READ_DATA, ACE4_WRITE_DATA, or ACE4_EXECUTE, and the mode bits affected have not been determined yet, set them to one (if ALLOW) or zero (if DENY). 4. Upon completion, any mode bits as yet undetermined have a value of zero. This pseudocode more precisely describes the algorithm: /* octal constants for the mode bits */ RUSR = 0400 WUSR = 0200 XUSR = 0100 RGRP = 0040 WGRP = 0020 XGRP = 0010 ROTH = 0004 WOTH = 0002 XOTH = 0001 /* * old_mode represents the previous value * of the mode of the object. */ mode_t mode = 0, seen = 0; for each ACE a { if a.type is ALLOW or DENY and ACE4_INHERIT_ONLY_ACE is not set in a.flags { if a.who is OWNER@ { if ((a.mask & ACE4_READ_DATA) && (! (seen & RUSR))) { seen |= RUSR; if a.type is ALLOW { mode |= RUSR; } Falkner & Week Expires August 19, 2006 [Page 8] Internet-Draft NFS Version 4 ACLs February 2006 } if ((a.mask & ACE4_WRITE_DATA) && (! (seen & WUSR))) { seen |= WUSR; if a.type is ALLOW { mode |= WUSR; } } if ((a.mask & ACE4_EXECUTE) && (! (seen & XUSR))) { seen |= XUSR; if a.type is ALLOW { mode |= XUSR; } } } else if a.who is GROUP@ { if ((a.mask & ACE4_READ_DATA) && (! (seen & RGRP))) { seen |= RGRP; if a.type is ALLOW { mode |= RGRP; } } if ((a.mask & ACE4_WRITE_DATA) && (! (seen & WGRP))) { seen |= WGRP; if a.type is ALLOW { mode |= WGRP; } } if ((a.mask & ACE4_EXECUTE) && (! (seen & XGRP))) { seen |= XGRP; if a.type is ALLOW { mode |= XGRP; } } } else if a.who is EVERYONE@ { if (a.mask & ACE4_READ_DATA) { if ! (seen & RUSR) { seen |= RUSR; if a.type is ALLOW { mode |= RUSR; } } if ! (seen & RGRP) { seen |= RGRP; if a.type is ALLOW { Falkner & Week Expires August 19, 2006 [Page 9] Internet-Draft NFS Version 4 ACLs February 2006 mode |= RGRP; } } if ! (seen & ROTH) { seen |= ROTH; if a.type is ALLOW { mode |= ROTH; } } } if (a.mask & ACE4_WRITE_DATA) { if ! (seen & WUSR) { seen |= WUSR; if a.type is ALLOW { mode |= WUSR; } } if ! (seen & WGRP) { seen |= WGRP; if a.type is ALLOW { mode |= WGRP; } } if ! (seen & WOTH) { seen |= WOTH; if a.type is ALLOW { mode |= WOTH; } } } if (a.mask & ACE4_EXECUTE) { if ! (seen & XUSR) { seen |= XUSR; if a.type is ALLOW { mode |= XUSR; } } if ! (seen & XGRP) { seen |= XGRP; if a.type is ALLOW { mode |= XGRP; } } if ! (seen & XOTH) { seen |= XOTH; if a.type is ALLOW { mode |= XOTH; } Falkner & Week Expires August 19, 2006 [Page 10] Internet-Draft NFS Version 4 ACLs February 2006 } } } } } return mode | (old_mode & (SUID | SGID | SVTX)) 5.2. How should a mode given in the arguments to CREATE or OPEN affect an inherited ACL? The goal of implementing ACL inheritance is for newly created objects to inherit the ACLs they were intended to inherit, but without disregarding the mode that is given with the arguments to the CREATE or OPEN operations. The general algorithm is as follows: 1. Form an ACL on the newly created object that is the concatenation of all inheritable ACEs from its parent directory. Note that there may be zero inheritable ACEs; thus, an object may start with an empty ACL. This is self explanatory. If, for example, a new non-directory file is being created, ACEs with the flag of ACE4_FILE_INHERIT_ACE will be considered inheritable. 2. For each ACE in the new ACL, adjust its flags if necessary, and possibly create two ACEs in place of one. This will be discussed in detail below. 3. Apply the algorithm for applying a mode to a file/directory with an existing ACL on the new object as described in Section 5.3, using the mode that is to be used for file creation. This ensures that the mode is honored. Step 2 above is necessary to honor the intent of the inheritance- related flags. It also is intended to preserve information about the original inheritable ACEs in the case that they will be modified by other steps. Paragraph 2 is detailed in the following algorithm: 1. If the ACE4_NO_PROPAGATE_INHERIT_ACE is set, or the type of the file is something other than "directory", then clear the following flags: ACE4_NO_PROPAGATE_INHERIT_ACE ACE4_FILE_INHERIT_ACE Falkner & Week Expires August 19, 2006 [Page 11] Internet-Draft NFS Version 4 ACLs February 2006 ACE4_DIRECTORY_INHERIT_ACE ACE4_INHERIT_ONLY_ACE Continue on to the next ACE. 2. If the type of file is "directory" and ACE4_FILE_INHERIT_ACE is set and ACE4_DIRECTORY_INHERIT_ACE is NOT set, then we ensure that ACE4_INHERIT_ONLY_ACE is set. Continue on to the next ACE. Otherwise: 3. If the type of the ACE is neither ALLOW nor DENY, then continue on to the next ACE. 4. Copy the original ACE into a second, adjacent ACE. 5. On the first ACE, ensure that ACE4_INHERIT_ONLY_ACE is set. 6. On the second ACE, clear the following flags: ACE4_NO_PROPAGATE_INHERIT_ACE ACE4_FILE_INHERIT_ACE ACE4_DIRECTORY_INHERIT_ACE ACE4_INHERIT_ONLY_ACE 7. On the second ACE, if the type field is ALLOW, an implementation MAY clear the following mask bits: ACE4_WRITE_ACL ACE4_WRITE_OWNER 5.3. What should happen to an existing ACL if a mode is applied to the file/directory? An existing ACL can mean two things in this context. One, that a file/directory already exists and it has an ACL. Two, that a directory has inheritable ACEs that will make up the ACL for any new files or directories created therein. The high-level goal of the behavior when a mode is set on a file with an existing ACL is to take the new mode into account, without needing to disregard a pre-existing ACL. When a mode is applied to an object, e.g. via SETATTR or CREATE/OPEN, Falkner & Week Expires August 19, 2006 [Page 12] Internet-Draft NFS Version 4 ACLs February 2006 the ACL must be modified to accommodate the mode. 1. The ACL is traversed, one ACE at a time. For each ACE: 1. If the type of the ACE is neither ALLOW nor DENY, the ACE is left unchanged. Continue to the next ACE. 2. If the ACE4_INHERIT_ONLY_ACE flag is set on the ACE, it is left unchanged. Continue to the next ACE. 3. If either or both of ACE4_FILE_INHERIT_ACE or ACE4_DIRECTORY_INHERIT_ACE are set: 1. A copy of the ACE is made, and placed in the ACL immediately following the current ACE. 2. In the first ACE, the flag ACE4_INHERIT_ONLY_ACE is set. 3. In the second ACE, the following flags are cleared: ACE4_FILE_INHERIT_ACE ACE4_DIRECTORY_INHERIT_ACE ACE4_NO_PROPAGATE_INHERIT_ACE The algorithm continues on with the second ACE. 4. If the "who" field is one of the following: OWNER@ GROUP@ EVERYONE@ then the following mask bits are cleared: ACE4_READ_DATA ACE4_LIST_DIRECTORY ACE4_WRITE_DATA ACE4_ADD_FILE ACE4_APPEND_DATA Falkner & Week Expires August 19, 2006 [Page 13] Internet-Draft NFS Version 4 ACLs February 2006 ACE4_ADD_SUBDIRECTORY ACE4_EXECUTE At this point, we proceed to the next ACE. 5. Otherwise, if the "who" field did not match one of OWNER@, GROUP@, or EVERYONE@, the following steps SHOULD be performed. 1. If the type of the ACE is ALLOW, we check the preceding ACE (if any). If it does not meet all of the following criteria: 1. The type field is DENY. 2. The who field is the same as the current ACE. 3. The flag bit ACE4_IDENTIFIER_GROUP is the same as it is in the current ACE, and no other flag bits are set. 4. The mask bits are a subset of the mask bits of the current ACE, and are also a subset of the following: ACE4_READ_DATA ACE4_LIST_DIRECTORY ACE4_WRITE_DATA ACE4_ADD_FILE ACE4_APPEND_DATA ACE4_ADD_SUBDIRECTORY ACE4_EXECUTE then an ACE of type DENY, with a who equal to the current ACE, flag bits equal to ( & ACE4_IDENTIFIER_GROUP), and no mask bits, is prepended. 2. The following modifications are made to the prepended ACE. The intent is to mask the following ACE to disallow ACE4_READ_DATA, ACE4_WRITE_DATA, ACE4_APPEND_DATA, or ACE4_EXECUTE, based upon the group permissions of the new mode. As a special case, if the ACE matches the current Falkner & Week Expires August 19, 2006 [Page 14] Internet-Draft NFS Version 4 ACLs February 2006 owner of the file, the owner bits are used, rather than the group bits. This is reflected in the algorithm below. Let there be three bits defined: #define READ 04 #define WRITE 02 #define EXEC 01 Let "amode" be the new mode, right-shifted three bits, in order to have the group permission bits placed in the three low order bits of amode, i.e. amode = mode >> 3 If ACE4_IDENTIFIER_GROUP is not set in the flags, and the "who" field of the ACE matches the owner of the file, we shift amode three more bits, in order to have the owner permission bits placed in the three low order bits of amode: amode = amode >> 3 amode is now used as follows: If ACE4_READ_DATA is set on the current ACE: If READ is set on amode: ACE4_READ_DATA is cleared on the prepended ACE else: ACE4_READ_DATA is set on the prepended ACE If ACE4_WRITE_DATA is set on the current ACE: If WRITE is set on amode: ACE4_WRITE_DATA is cleared on the prepended ACE else: ACE4_WRITE_DATA is set on the prepended ACE If ACE4_APPEND_DATA is set on the current ACE: If WRITE is set on amode: ACE4_APPEND_DATA is cleared on the prepended ACE else: ACE4_APPEND_DATA is set on the prepended ACE If ACE4_EXECUTE is set on the current ACE: If EXEC is set on amode: ACE4_EXECUTE is cleared on the prepended ACE else: Falkner & Week Expires August 19, 2006 [Page 15] Internet-Draft NFS Version 4 ACLs February 2006 ACE4_EXECUTE is set on the prepended ACE 3. To conform with POSIX, and prevent cases where the owner of the file is given permissions via an explicit group (i.e. alternate permissions are not disabled following a chmod), we implement the following step. If ACE4_IDENTIFIER_GROUP is set in the flags field of the ALLOW ACE: Let "mode" be the mode that we are chmoding to: extramode = (mode >> 3) & 07 ownermode = mode >> 6 extramode &= ~ownermode If extramode is not zero: If extramode & READ: Clear ACE4_READ_DATA in both the prepended DENY ACE and the ALLOW ACE If extramode & WRITE: Clear ACE4_WRITE_DATA and ACE_APPEND_DATA in both the prepended DENY ACE and the ALLOW ACE If extramode & EXEC: Clear ACE4_EXECUTE in both the prepended DENY ACE and the ALLOW ACE 2. If there are at least six ACEs, the final six ACEs are examined. If they are not equal to the following ACEs: A1) OWNER@:::DENY A2) OWNER@:ACE4_WRITE_ACL/ACE4_WRITE_OWNER/ ACE4_WRITE_ATTRIBUTES/ACE4_WRITE_NAMED_ATTRIBUTES::ALLOW A3) GROUP@::ACE4_IDENTIFIER_GROUP:DENY A4) GROUP@::ACE4_IDENTIFIER_GROUP:ALLOW A5) EVERYONE@:ACE4_WRITE_ACL/ACE4_WRITE_OWNER/ ACE4_WRITE_ATTRIBUTES/ACE4_WRITE_NAMED_ATTRIBUTES::DENY A6) EVERYONE@:ACE4_READ_ACL/ACE4_READ_ATTRIBUTES/ ACE4_READ_NAMED_ATTRIBUTES/ACE4_SYNCHRONIZE::ALLOW Then six ACEs matching the above are appended. 3. The final six ACEs are adjusted according to the incoming mode. Falkner & Week Expires August 19, 2006 [Page 16] Internet-Draft NFS Version 4 ACLs February 2006 /* octal constants for the mode bits */ RUSR = 0400 WUSR = 0200 XUSR = 0100 RGRP = 0040 WGRP = 0020 XGRP = 0010 ROTH = 0004 WOTH = 0002 XOTH = 0001 If RUSR is set: set ACE4_READ_DATA in A2 else: set ACE4_READ_DATA in A1 If WUSR is set: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A2 else: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A1 If XUSR is set: set ACE4_EXECUTE in A2 else: set ACE4_EXECUTE in A1 If RGRP is set: set ACE4_READ_DATA in A4 else: set ACE4_READ_DATA in A3 If WGRP is set: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A4 else: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A3 If XGRP is set: set ACE4_EXECUTE in A4 else: set ACE4_EXECUTE in A3 If ROTH is set: set ACE4_READ_DATA in A6 else: set ACE4_READ_DATA in A5 If WOTH is set: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A6 else: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A5 If XOTH is set: set ACE4_EXECUTE in A6 else: set ACE4_EXECUTE in A5 5.4. What should happen if both mode and ACL are given to SETATTR? The only reason that a mode and ACL should be set in the same SETATTR is if the user wants to set the SUID, SGID and SVTX bits along with setting the permissions by means of an ACL. There is still no way to enforce which order the attributes will be set in, and it is likely that different orders of operations will produce different results. In the long run, the best solution would be the ability to set SUID, SGID and SVTX bits independent of the mode, but since we don't have this ability in NFS version 4.0, this is what we recommend. 5.4.1. Client Side Recommendations If an application needs to enforce a certain behavior, it is recommended that the client implementations set mode and ACL in separate SETATTR requests. This will produce consistent and expected Falkner & Week Expires August 19, 2006 [Page 17] Internet-Draft NFS Version 4 ACLs February 2006 results. If an application wants to set SUID, SGID and SVTX bits and an ACL, we recommend: In the first SETATTR, set the mode with SUID, SGID and SVTX bits as desired and all other bits with a value of 0. In a following SETATTR (preferably in the same COMPOUND) set the ACL. 5.4.2. Server Side Recommendations If both mode and ACL are given to SETATTR, server implementations should verify that the mode and ACL don't conflict, i.e. the mode computed from the given ACL must be the same as the given mode, excluding the SUID, SGID and SVTX bits. The algorithm for assigning a new mode based on the ACL can be used. This is described in Section 5.1. If a server receives a request to set both mode and ACL, but the two conflict, the server should return NFS4ERR_INVAL. Falkner & Week Expires August 19, 2006 [Page 18] Internet-Draft NFS Version 4 ACLs February 2006 6. Deficiencies in a Mode Representation of an ACL As mentioned in Section 5.1, the representation of the mode is deterministic, but not guaranteed to be accurate. The mode bits potentially convey a more restrictive permission than what will actually be granted via the ACL. Given the following ACL of two ACEs: GROUP@:ACE4_READ_DATA/ACE4_WRITE_DATA/ACE4_EXECUTE: ACE4_IDENTIFIER_GROUP:ALLOW EVERYONE@:ACE4_READ_DATA/ACE4_WRITE_DATA/ACE4_EXECUTE::DENY we would compute a mode of 0070. However, it is possible, even likely, that the owner might be a member of the object's owning group, and thus, the owner would be granted read, write, and execute access to the object. This would conflict with the mode of 0070, where an owner would be denied this access. The only way to overcome this deficiency would be to determine whether the object's owner is a member of the object's owning group. This is difficult, but worse, on a POSIX or any UNIX-like system, it is a process' membership in a group that is important, not a user's. Thus, any fixed mode intended to represent the above ACL can be incorrect. Example: administrative databases (possibly /etc/passwd and /etc/ group) indicate that the user "bob" is a member of the group "staff". An object has the ACL given above, is owned by "bob", and has an owning group of "staff". User "bob" has logged in to the system, and thus processes have been created owned by "bob" and having membership in group "staff". A mode representation of the above ACL could thus be 0770, due to user "bob" having membership in group "staff". Now, the administrative databases are changed, such that user "bob" is no longer in group "staff". User "bob" logs in to the system again, and thus more processes are created, this time owned by "bob" but NOT in group "staff". A mode of 0770 is inaccurate for processes not belonging to group "staff". But even if the mode of the file were proactively changed to 0070 at the time the group database was edited, mode 0070 would be inaccurate for the pre-existing processes owned by user "bob" and having membership in group "staff". Falkner & Week Expires August 19, 2006 [Page 19] Internet-Draft NFS Version 4 ACLs February 2006 7. Access Control Semantics The NFS version 4 specification [RFC3530] defines how an ACL is interpreted, and it states that the access is undefined if you get through the entire ACL and haven't encountered an ALLOW or DENY ACE for the requester. We now recommend that if you fall through the ACL, access is denied. This allows the behavior to be clearly defined, and consistent across implementations. In fact, there is precedence for this behavior in current implementations. It is convenient that [RFC3530] gave implementations flexibility by leaving the access undefined, but the flexibility is still present given that there have always been security policies independent of file permissions. Servers can have other security policies in place, and in those cases, access will be decided outside of what is defined in the ACL. Examples of security policies that can be in place outside of what is defined (or not defined) in the ACL are: 1. The owner of the file will always be granted ACE4_WRITE_ACL and ACE4_READ_ACL permissions. 2. The ACL may say that an entity is to be granted ACE4_WRITE_DATA permission, but the file system is mounted read only. For multiple reasons, including the one listed above, client implementations are recommended not to do their own access checking. All access checking should be done on the server. Falkner & Week Expires August 19, 2006 [Page 20] Internet-Draft NFS Version 4 ACLs February 2006 8. Inheritance and turning it off The inheritance of access permissions may be problematic if a user cannot prevent their file from inheriting unwanted permissions. For example, a user, "samf", sets up a shared project directory to be used by everyone working on Project Foo. "lisagab" is a part of Project Foo, but is working on something that should not be seen by anyone else. How can "lisagab" make sure that any new files that she creates in this shared project directory do not inherit anything that could compromise the security of her work? More relevant to the implementors of NFS version 4 clients and servers is the question of how to communicate the fact that user, "lisagab", doesn't want any permissions to be inherited to her newly created file or directory. To do this, implementors should standardize on what the behavior of CREATE and OPEN must be if: 1. just mode is given In this case, inheritance will take place, but the mode will be applied to the inherited ACL as described in Section 5.1, thereby modifying the ACL. 2. just ACL is given In this case, inheritance will not take place, and the ACL as defined in the CREATE or OPEN will be set without modification. 3. both mode and ACL are given In this case, implementors should verify that the mode and ACL don't conflict, i.e. the mode computed from the given ACL must be the same as the given mode. The algorithm for assigning a new mode based on the ACL can be used. This is described in Section 5.1) If a server receives a request to set both mode and ACL, but the two conflict, the server should return NFS4ERR_INVAL. If the mode and ACL don't conflict, inheritance will not take place and both, the mode and ACL, will be set without modification. 4. neither mode nor ACL are given In this case, inheritance will take place and no modifications to the ACL will happen. It is worth noting that if no inheritable ACEs exist on the parent directory, the file will be created with an empty ACL, thus granting no accesses. Falkner & Week Expires August 19, 2006 [Page 21] Internet-Draft NFS Version 4 ACLs February 2006 9. EVERYONE@: What does it mean? The NFS version 4 specification [RFC3530] refers to the "EVERYONE@" special identifier as meaning "The world". This is confusing because there are a couple of different ways to interpret the wording. These different interpretations are problematic and it would be advantageous for implementors to standardize on a single meaning. The different interpretations are as follows: 1. "EVERYONE@" is equivalent to the UNIX "other" entity, which by definition does not include the owner or owning group of the file. 2. "EVERYONE@" literally means everyone, including the file's owner and owning group. The goal of standardizing on what "EVERYONE@" means may be best expressed from a user's point of view. A user of NFS version 4 ACLs should expect that setting an ACL such as the following will have the same affect regardless of what vendor's implementation they are using. EVERYONE@:ACE4_READ_DATA::ALLOW Examples of how the different interpretations could cause different behaviors are as follows: If we take interpretation #1 where "EVERYONE@" is equivalent to the UNIX "other" entity and the owner or a user in the owning group attempt to access the file for reading, they would be denied. This is because we fell through the ACL and didn't find any entries specifying the permissions for OWNER@ and GROUP@ (see Section 7). If we take interpretation #2 where "EVERYONE@" is literally everyone, including the owner and owning group, and the owner or a user in the owning group attempt to access the file for reading, they would be allowed. The first interpretation is understandable, but does not follow the intent of the special identifier. Therefore, it is recommended that implementors use "EVERYONE@" to mean literally everyone. Falkner & Week Expires August 19, 2006 [Page 22] Internet-Draft NFS Version 4 ACLs February 2006 10. Access Mask Bit Discussion The purpose of this section is to clarify the meaning of the different access mask bits. This will state the operations and a description of what the access mask bit controls. A major portion of the descriptions were taken from [RFC3530]. The following is a list of access mask bits that can be set on an ACE: ACE4_READ_DATA Operation(s) affected: READ OPEN Discussion: Permission to read the data of the file. ACE4_LIST_DIRECTORY Operation(s) affected: READDIR Discussion: Permission to list the contents of a directory. ACE4_WRITE_DATA Operation(s) affected: WRITE OPEN Discussion: Permission to modify a file's data anywhere in the file's offset range. This includes the ability to write to any arbitrary offset and as a result to grow the file. ACE4_ADD_FILE Operation(s) affected: CREATE OPEN Discussion: Permission to add a new file in a directory. The CREATE operation is affected when nfs_ftype4 is NF4LNK, NF4BLK, NF4CHR, NF4SOCK, or NF4FIFO. (NF4DIR is not listed because it is covered by ACE4_ADD_SUBDIRECTORY.) OPEN is affected when used to create a regular file. ACE4_APPEND_DATA Operation(s) affected: WRITE OPEN Discussion: Falkner & Week Expires August 19, 2006 [Page 23] Internet-Draft NFS Version 4 ACLs February 2006 The ability to modify a file's data, but only starting at EOF. See Section 11 for further discussion on the relationship between ACE4_APPEND_DATA and ACE4_WRITE_DATA. ACE4_ADD_SUBDIRECTORY Operation(s) affected: CREATE Discussion: Permission to create a subdirectory in a directory. The CREATE operation is affected when nfs_ftype4 is NF4DIR. ACE4_READ_NAMED_ATTRS Operation(s) affected: OPENATTR Discussion: Permission to lookup the named attributes directory. OPENATTR is affected when it is not used to create a named attribute directory. This is when 1.) createdir is TRUE, but a named attribute directory already exists, or 2.) createdir is FALSE. ACE4_WRITE_NAMED_ATTRS Operation(s) affected: OPENATTR Discussion: Permission to create a named attribute directory. OPENATTR is affected when it is used to create a named attribute directory. This is when createdir is TRUE and no named attribute directory exists. The ability to check whether or not a named attribute directory exists depends on the ability to look it up, therefore, users also need the ACE4_READ_NAMED_ATTRS permission in order to create a named attribute directory. ACE4_EXECUTE Operation(s) affected: LOOKUP Discussion: Permission to execute a file or traverse/search a directory. ACE4_DELETE_CHILD Operation(s) affected: Falkner & Week Expires August 19, 2006 [Page 24] Internet-Draft NFS Version 4 ACLs February 2006 REMOVE Discussion: Permission to delete a file or directory within a directory. ACE4_READ_ATTRIBUTES Operation(s) affected: GETATTR of file system object attributes Discussion: The ability to read basic attributes (non-ACLs) of a file. ACE4_WRITE_ATTRIBUTES Operation(s) affected: SETATTR of time_access_set, time_backup, time_create, time_modify_set Discussion: Permission to change the times associated with a file or directory to an arbitrary value. ACE4_DELETE Operation(s) affected: REMOVE Discussion: Permission to delete the file or directory. ACE4_READ_ACL Operation(s) affected: GETATTR of acl Discussion: Permission to read the ACL. ACE4_WRITE_ACL Operation(s) affected: SETATTR of acl and mode Discussion: Permission to write the acl and mode attributes. ACE4_WRITE_OWNER Operation(s) affected: SETATTR of owner and owner_group Discussions: Permission to write the owner and owner_group attributes. On UNIX systems, this is the ability to execute chown or chgrp. ACE4_SYNCHRONIZE Operation(s) affected: Falkner & Week Expires August 19, 2006 [Page 25] Internet-Draft NFS Version 4 ACLs February 2006 NONE Discussion: Permission to access file locally at the server with synchronized reads and writes. Falkner & Week Expires August 19, 2006 [Page 26] Internet-Draft NFS Version 4 ACLs February 2006 11. Append Only Behavior The NFS version 4 ACL model allows for the notion of append-only files, by allowing ACE4_APPEND_DATA and denying ACE4_WRITE_DATA to the same user or group. If a file has an ACL such as the one described above and a WRITE request is made for somewhere other than EOF, the server SHOULD return NFS4ERR_ACCESS. Falkner & Week Expires August 19, 2006 [Page 27] Internet-Draft NFS Version 4 ACLs February 2006 12. ACE4_DELETE/ACE4_DELETE_CHILD Behavior There are two separate access mask bits that govern the ability to delete a file: ACE4_DELETE and ACE4_DELETE_CHILD. ACE4_DELETE is intended to be specified by the ACL for the object to be deleted, and ACE4_DELETE_CHILD is intended to be specified by the ACL of the parent directory. In addition to ACE4_DELETE and ACE4_DELETE_CHILD, many systems also consider the "sticky bit" (MODE4_SVTX) and the appropriate "write" mode bit when determining whether to allow a file to be deleted. The mode bit for write corresponds to ACE4_WRITE_DATA, which is the same physical bit as ACE4_ADD_FILE. Therefore, ACE4_ADD_FILE can come into play when determining permission to delete. In the algorithm below, the strategy is that ACE4_DELETE and ACE4_DELETE_CHILD take precedence over the sticky bit, and the sticky bit takes precedence over the "write" mode bits (reflected in ACE4_ADD_FILE). Server implementations SHOULD grant or deny permission to delete based on the following algorithm. if ACE4_EXECUTE is denied by the parent directory ACL: deny delete else if ACE4_EXECUTE is unspecified by the parent directory ACL: deny delete else if ACE4_DELETE is allowed by the target object ACL: allow delete else if ACE4_DELETE_CHILD is allowed by the parent directory ACL: allow delete else if ACE4_DELETE_CHILD is denied by the parent directory ACL: deny delete else if ACE4_ADD_FILE is allowed by the parent directory ACL: if MODE4_SVTX is set for the parent directory: if the principal owns the parent directory OR the principal owns the target object OR ACE4_WRITE_DATA is allowed by the target object ACL: allow delete else: deny delete else: allow delete else: deny delete Falkner & Week Expires August 19, 2006 [Page 28] Internet-Draft NFS Version 4 ACLs February 2006 13. ACE4_ADD_FILE and ACE4_ADD_SUBDIRECTORY As specified in Section 10, the permission granted by ACE4_WRITE_DATA is a superset of the permission granted by ACE4_APPEND_DATA. With directories, ACE4_WRITE_DATA is analogous to ACE4_ADD_FILE, and ACE4_APPEND_DATA is analogous to ACE4_ADD_SUBDIRECTORY. A question this raises is whether ACE4_ADD_FILE is a superset of ACE4_ADD_SUBDIRECTORY. In other words, does the granting of ACE4_ADD_FILE imply the permission to create a subdirectory? It is proposed that ACE4_ADD_FILE does not imply ACE4_ADD_SUBDIRECTORY. Falkner & Week Expires August 19, 2006 [Page 29] Internet-Draft NFS Version 4 ACLs February 2006 14. POSIX Considerations Disclaimer: This section is relevant to platforms with requirements to be POSIX compliant. These platforms are typically UNIX based, and the following discussion will be heavily biased toward those platforms. 14.1. Background Information The standard POSIX (See [POSIX]) file access control mechanism uses the file permission bits contained in the file mode. The file permission bits are used to determine whether a process has read, write or execute/search permission to a file based on which class the process is in; file owner, file group or file other class. A process is in the file owner class if the effective user ID of the process matches the user ID of the file. A process is in the file group class if the process is not in the file owner class and if the effective group ID or one of the supplementary group IDs of the process matches the group ID associated with the file. A process is in the file other class if the effective user ID of the process is not in the file owner class or the file group class. The POSIX spec says that a process is in one and only one class, therefore, the access permissions that exist for that class are the only ones that will be considered when doing access checks. 14.2. Additional and Alternate File Access Control Mechanisms In addition to the standard file access control mechanism, the POSIX spec allows for additional and alternate file access control mechanisms. According to Section 4.4 of the POSIX spec, a file can have one or both mechanisms in place. The additional file access control mechanism is defined to be layered upon the file permission bits, but they can only further restrict the standard file access control mechanism. The alternate file access control mechanism is defined to be independent of the file permission bits and which if enabled on a file may either restrict or extend the permissions of a given user. Another major distinction between the additional and alternate file access control mechanisms is that any alternate mechanism must be disabled after the file permission bits are changed with a chmod. Additional mechanisms do not need to be disabled when a chmod is done. 14.3. NFSv4 ACLs vs. POSIX-draft ACLs The goal of both ACL models is similar in that we want to be able to Falkner & Week Expires August 19, 2006 [Page 30] Internet-Draft NFS Version 4 ACLs February 2006 give the owner of the file more fine grained access control than is available with the file permission bits. Much like POSIX draft ACLs, NFSv4 ACLs are made up of multiple Access Control Entries (ACEs), but the similarities don't go much further. One major difference between POSIX draft and NFSv4 is that NFSv4 ACLs have two types of ACEs that play a role in access checking. Those two types are ALLOW and DENY. One important thing to note about this distinction is that in POSIX draft ACLs, a single entry defines what is allowed and also what is denied for the user or group that the entry applies to. NFSv4 ACLs separate what is allowed and what is denied by having the distinct ALLOW and DENY types of ACEs. The importance of this is that a user shouldn't infer from any single NFSv4 ACE that defines some set of permissions whether or not the permissions that weren't defined in that ACE are allowed or denied. This leads us to have to look at the ACL as a whole in order to determine a user's access. For instance, in the following example, the first "bob@sun.com" entry defines the capability for user "bob@sun.com" regarding ACE4_READ_DATA, but you cannot infer from that entry whether "bob@sun.com" is granted ACE4_WRITE_DATA or not. One must continue through the ACL to see what the other capabilities are. bob@sun.com:ACE4_READ_DATA::ALLOW bob@sun.com:ACE4_WRITE_DATA::ALLOW GROUP@:ACE4_EXECUTE:ACE4_IDENTIFIER_GROUP:DENY bob@sun.com:ACE4_EXECUTE::ALLOW This example also illustrates a couple of other differences between the two models. The first difference to be noted is that the ordering of the ACEs is different from what is typical with POSIX- draft ACLs. POSIX-draft ACLs have a defined ordering of the ACEs which is as follows: owner, supplemental users, owning group, supplemental groups, and other. This ordering is maintained by the kernel and cannot be changed by the user. With NFSv4 ACLs, there is no rigid order of the ACEs and the order is user defined. The second difference that this example illustrates is that there is no MASK_OBJ or mask entry in this ACL. This is because NFSv4 ACLs have no notion of a mask. NFSv4 ACLs go beyond the ability to define access with regard to the standard read, write and execute/search permissions and allows the user to set ACLs to define file control permissions (i.e. - the ability to allow or deny a user the ability to write the ACL or Falkner & Week Expires August 19, 2006 [Page 31] Internet-Draft NFS Version 4 ACLs February 2006 change the owner). The model also allows inheriting both standard and file control permissions to newly created files. 14.4. NFSv4 ACLs vs. POSIX In various other vendors' implementations of NFSv4 ACLs, they have taken a chmod to mean the setting of a six member ACL, therefore throwing away the ACL and replacing it with six ACEs which reflect the mode. The user feedback on this behavior has been unfavorable. Some have gone as far as to say that it is unacceptable. We presume the dissatisfaction comes from a user spending time crafting an ACL only to get it stomped by a later chmod. Considering how many applications use chmod, we should not follow this behavior. In addition, security problems can arise if any explicit DENY ACEs are automatically removed as the result of a chmod (as shown in the example below). We believe it is a requirement to preserve an object's ACL upon chmod. A DENY type of ACE is considered to be an additional file access control mechanism, since it can only further restrict permissions. By categorizing DENY ACEs as additional, we have the ability to be able to keep the DENY ACEs without modification, except for on the abstract entities "OWNER@", "GROUP@" and "EVERYONE@" (see section Section 5.3 for further explanation). The importance of classifying DENY ACEs as a additional file access control mechanism is best shown in the following example: Suppose we have a file with the following ACL: www@sun.com:ACE4_READ_DATA::DENY OWNER@:::DENY OWNER@:::ALLOW GROUP@::ACE4_IDENTIFIER_GROUP:DENY GROUP@::ACE4_IDENTIFIER_GROUP:ALLOW EVERYONE@:::DENY EVERYONE@:::ALLOW We require the ability to keep the "www@sun.com:ACE4_READ_DATA::DENY" ACE in the event of a chmod so that "www@sun.com"'s permissions do Falkner & Week Expires August 19, 2006 [Page 32] Internet-Draft NFS Version 4 ACLs February 2006 not get elevated by the deletion of the ACE upon execution of chmod. The ALLOW type of ACE is considered to be an alternate file access control mechanism because it can further extend the permissions of a user. As previously mentioned, POSIX states that alternate mechanisms must be disabled at the time of chmod. This is different from requiring the deletion of any alternate mechanisms, and allows us to preserve the ACL. See Paragraph 1.5 in Section 5.3. 14.5. umask Considerations The umask is used by UNIX operating system users to affect or mask down the file permission bits of newly created files. umask is not part of the NFS version 4 protocol. Instead, it is an entirely client-side concept. umask can be briefly described as an attribute of a process which is a set of bits that are not to be set in the mode bits of a newly created file. If a process creates a new file via the open() system call, with an octal mode of 0777, and the process has a umask of 0022, the resulting file would have an octal mode attribute of 0755. On client implementations that implement the concept of a umask, NFSv4 client implementations SHOULD apply the umask on newly created files, whether or not a newly created file will be affected by inheritable ACEs in the parent directory. 15. Normative References [POSIX] "The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Edition", IEEE STD. 1003.1, January 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, STD 1, April 2003. Falkner & Week Expires August 19, 2006 [Page 33] Internet-Draft NFS Version 4 ACLs February 2006 Authors' Addresses Sam Falkner Sun Microsystems, Inc. 500 Eldorado Blvd. MS: UBRM05-171 Broomfield, CO 80021 USA Email: sam.falkner@sun.com Lisa Week Sun Microsystems, Inc. 500 Eldorado Blvd. MS: UBRM05-171 Broomfield, CO 80021 USA Email: lisa.week@sun.com Falkner & Week Expires August 19, 2006 [Page 34] Internet-Draft NFS Version 4 ACLs February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Falkner & Week Expires August 19, 2006 [Page 35]