Internet DRAFT - draft-ietf-nfsv4-acls
draft-ietf-nfsv4-acls
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>:<Field #2>:<Field #3>:<Field #4>
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 (<current-ACE-flags> &
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@:<arbitrary mask>::DENY
OWNER@:<arbitrary mask>::ALLOW
GROUP@:<arbitrary mask>:ACE4_IDENTIFIER_GROUP:DENY
GROUP@:<arbitrary mask>:ACE4_IDENTIFIER_GROUP:ALLOW
EVERYONE@:<arbitrary mask>::DENY
EVERYONE@:<arbitrary mask>::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]
