draft-ietf-nfsv4-acl-mapping-01.txt   draft-ietf-nfsv4-acl-mapping-02.txt 
Network Working Group Marius Aamodt Eriksen Network Working Group Marius Aamodt Eriksen
Internet Draft J. Bruce Fields
Document: draft-ietf-nfsv4-acl-mapping-01.txt Document: draft-ietf-nfsv4-acl-mapping-02.txt October 2004
Mapping Between NFSv4 and Posix Draft ACLs Mapping Between NFSv4 and Posix Draft ACLs
SSttaattuuss ooff tthhiiss MMeemmoo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be dis-
closed, in accordance with RFC 3668.
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 33 skipping to change at page 1, line 38
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
"Copyright (C) The Internet Society (2002-2004). All Rights "Copyright (C) The Internet Society (2002-2004). All Rights
Reserved." Reserved."
AAbbssttrraacctt Abstract
The NFS (Network File System) version 4[rfc3010bis] (NFSv4) specifies NFS version 4 [rfc3530] (NFSv4) specifies a flavor of Access Control
a flavor of Access Control Lists (ACLs) that resembles that of Win- Lists (ACLs) resembling Windows NT ACLs. A number of operating sys-
dows NT's. ACLs are used to specify fine grained control of access tems use a different flavor of ACL based on a withdrawn POSIX draft.
to file system objects. An ACL consists of a number of Access Con- NFSv4 clients and servers on such operating systems may wish to map
trol Entries (ACEs), each specify some level of access for an entity;
an entity can be a a user, group or a special entity. The access
level is described using an access mask, which is a bitmask where
each bit describes a level of access, for example read, write and
execute permissions on the file system object.
Mapping NFSv4 ACLs February 2004 Mapping NFSv4 ACLs October 2004
TTaabbllee ooff CCoonntteennttss between NFSv4 ACLs and their native ACLs. To this end, we describe a
mapping from POSIX draft ACLs to a subset of NFSv4 ACLs.
11.. IInnttrroodduuccttiioonn . . . . . . . . . . 3 Mapping NFSv4 ACLs October 2004
22.. NNFFSSvv44 AACCLLss . . . . . . . . . . . . . . 3
33.. PPOOSSIIXX AACCLLss . . . . . . . . . . . . . . 4
44.. MMaappppiinngg PPoossiixx AACCLLss
ttoo NNFFSSvv44 AACCLLss . . . . . . . . . . 5
55.. SSeeccuurriittyy
CCoonnssiiddeerraattiioonnss . . . . . . . 7
66.. BBiibblliiooggrraapphhyy . . . . . . . . . . 8
77.. AAcckknnoowwlleeddggmmeennttss . . . . . 9
88.. AAuutthhoorr''ss AAddddrreessss . . . . 10
99.. CCooppyyrriigghhtt . . . . . . . . . . . . . 10
Mapping NFSv4 ACLs February 2004 Table of Contents
11.. IInnttrroodduuccttiioonn 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. NFSv4 ACLs . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. POSIX ACLs . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Mapping Posix ACLs to NFSv4 ACLs . . . . . . . . . . . . . . 6
5. Using the Mapping in NFSv4 Implementations . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . 10
7. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 11
8. Author's Address . . . . . . . . . . . . . . . . . . . . . 12
9. Copyright . . . . . . . . . . . . . . . . . . . . . . . . 12
The NFS (Network File System) version 4 [rfc3010bis] (NFSv4) speci- Mapping NFSv4 ACLs October 2004
fies a flavor of Access Control Lists (ACLs) that resembles that of
Windows NT's. ACLs are used to specify fine grained control of 1. Introduction
access to file system objects. An ACL consists of a number of Access
Access Control Lists (ACLs) are used to specify fine-grained access
rights to file system objects. An ACL consists of a number of Access
Control Entries (ACEs), each specifying some level of access for an Control Entries (ACEs), each specifying some level of access for an
entity; an entity can be a a user, group or a special entity. The entity. The entity may be a user, a group, or a special entity (such
access level is described using an access mask, which is a bitmask as "everyone"). The level of access is described using an access
where each bit describes a level of access, for example read, write mask, which is a bitmask with each bit corresponding to a type of
and execute permissions on the file system object. access (such as "read" or "append").
22.. NNFFSSvv44 AACCLLss In the following sections we describe two ACL models: NFSv4 ACLs, and
ACLs based on a withdrawn POSIX draft, which we will refer to as
"POSIX ACLs". Since NFSv4 ACLs are much finer-grained than POSIX
ACLs, it is not possible in general to map an arbitrary NFSv4 ACL to
a POSIX ACL with the same semantics. It does, however, turn out to
be possible to map any POSIX ACL to a NFSv4 ACL that has nearly iden-
tical semantics. We will describe such a mapping, and discuss how it
might be used in NFSv4 client and server implementations.
NFSv4 ACLs are rich in nature and expand upon the traditional idea of 2. NFSv4 ACLs
ACLs. An NFSv4 ACE can be of type ALLOW, DENY, LOG or ALARM; each
specifies a different action to take should the ACE match a current
request. NFSv4 ACLs also have a rich set of access types that com-
plements the traditional types. These include appending data to the
file object, deleting children of the file object, deleting the file
object, etc [rfc3010bis].
NFSv4 ACLs are interpreted in a straightforward manner. An NFSv4 ACL is an ordered sequence of ACEs, each having an entity, a
type, and an access mask. The entity may be the name of a user or
group, or may also be one of a small set of special entities. Among
the special entities are "OWNER" (the current owner of the file),
"GROUP" (the group associated with the file), and "EVERYONE".
1) Walk through the list of ACEs from the ACL in order The access mask includes bits for access types that are more fine-
grained than the traditional "read", "write", and "execute" permis-
sions used in UNIX mode bits.
2) If the "who" (entity) field in the ACE does not match that of the The type may be ALLOW or DENY. (AUDIT or ALARM are also allowed, but
requester, the particular ACE is not processed. they are not relevant to our discussion).
3) Process all ACEs until all the bits in the requested access mask The NFSv4 ACL permission-checking algorithm is straightforward.
have been ALLOWed; once a particular bit has been ALLOWed by an Given an ACL and a requestor asking for a set of permissions speci-
ACE, it is no longer considered in further processing. fied by an access mask:
4) If a particular access is DENYed (while that bit is still under 1) Walk through the list of ACEs from the ACL in order.
consideration), the request is denied.
5) If all bits have been ALLOWed, the access is granted, or else 2) Ignore any ACE for with an entity not matching requestor.
behavior is undefined.
NFSv4 ACLs also specify a number of special entities such as OWNER, Mapping NFSv4 ACLs October 2004
GROUP, and EVERYONE. These refer to the traditional UNIX mode bits.
Others include DIALUP, BATCH, and AUTHENTICATED, which have special-
ized uses.
Mapping NFSv4 ACLs February 2004 3) Process all ACEs until all the bits in the requested access mask
have been ALLOWed by an ALLOW ace with that bit set. Once a par-
ticular bit has been ALLOWed by an ACE, it is no longer considered
in further processing.
Additionally the NFSv4 ACLs specify a number of flags that can be 4) If a bit in the requested access mask is DENYed (while that bit is
applied to an ACL. These include a specification on how an ACL on a still under consideration), the request is denied.
directory may be propagated to newly created files or directories
inside of said directory.
It is clear that the granularity of access control that NFSv4 ACLs 5) If all bits have been ALLOWed, the access is granted. Otherwise
specify is well beyond the standard UNIX capability of expressing behavior is undefined.
file system object permissions.
33.. PPOOSSIIXX AACCLLss There are also a number of flags that can be applied to an NFSv4 ACE.
Three flags that we will need to use in the following discussion
apply to ACEs in a directory ACL. They are: ACE4_DIREC-
TORY_INHERIT_ACE, which indicates that the ACE should be added to new
subdirectories of the directory; ACE4_FILE_INHERIT_ACE, which does
the same for new files; and ACE4_INHERIT_ONLY, which indicates that
the ACE should be ignored when determining access to the directory
itself.
POSIX ACLs refer to POSIX 1003.1e/1003.2c Draft Standard 17 [posix- We refer the reader to [rfc3530] for further details.
acl], which was meant to specify a POSIX standard for ACLs, but
unfortunately never materialized. However, many systems still use
it, both in the form of it's latest draft as well as earlier drafts.
POSIX ACLs are simpler than their NFSv4 equivalents. Each ACE an has 3. POSIX ACLs
an entity and the traditional UNIX mode bits that are assigned to the
particular entity. The entity may be an arbitrary UID or GID or one
of a few special entities, the most notable of which is the ACL_MASK
entity. POSIX ACLs are also interepreted differently than their
NFSv4 equivalents.
POSIX ACLs are interpreted as follows: A number of operating systems, including Linux and FreeBSD, implement
ACLs based on the withdrawn POSIX 1003.1e/1003.2c Draft Standard 17
[posixacl]. We will refer to such ACLs as "POSIX ACLs".
1) Process the ACL_USER_OBJ (equivalent to UNIX file owner) ACE POSIX ACLs use access masks with only the traditional "read",
first; if the UID of the requester does not match that of the "write", and "execute" bits. Each ACE in a POSIX ACL is one of five
ACL_USER_OBJ, then the ACE is ignored. Otherwise, if the types: ACL_USER_OBJ, ACL_USER, ACL_GROUP_OBJ, ACL_GROUP, ACL_MASK,
requester's access mask is allowed by the access mask of the ACE, and ACL_OTHER. Each ACL_USER ACE has a uid associated with it, and
the request is granted, else the request is denied. each ACL_GROUP ACE has a gid associated with it. Every POSIX ACL
must have exactly one ACL_USER_OBJ, ACL_GROUP, and ACL_OTHER ACE, and
at most one ACL_MASK ace. The ACL_MASK ace is required if the ACL
has any ACL_USER or ACL_GROUP aces. There may not be two ACL_USER
aces with the same uid, and there may not be two ACL_GROUP aces with
the same gid.
2) Process all of the ACL_USER ACEs; the entity of these ACEs specify Given a POSIX ACL and a requestor asking for access, permission is
a user on the system. If the UID of the requester does not match determined as follows:
that of the ACE, then the ACE is ignored. Otherwise, if the
requester's access mask is allowed by the access mask of the ACE,
the request is granted, else the request is denied.
3) Process the ACL_GROUP_OBJ ACE and all of the ACL_GROUP ACEs; the 1) If the requestor is the file owner, then allow or deny access
entity of these ACEs specify a group on the system. If none of depending on whether the ACL_USER_OBJ ACE allows or denies it.
the GIDs of the requester match the current ACE, the particular
ACE is ignored. For any matching ACE, if the the requester's
access mask is allowed by the ACEs access mask, then access is
permitted. If there are matching ACEs, but none allow access,
then access is denied.
Mapping NFSv4 ACLs February 2004 Mapping NFSv4 ACLs October 2004
4) If the requester's access mask is allowed by the ACL_OTHER ACE, Otherwise,
then grant access.
5) Deny access. 2) if the requestor's uid matches the uid of one of the ACL_USER
ACE's, then allow or deny access depending on whether the
ACL_USER_OBJ ACE allows or denies it. Otherwise,
3) Consider the set of all ACL_GROUP ACE's whose gid the requestor is
a member of. Add to that set the ACL_GROUP_OBJ ACE, if the
requestor is also a member of that group. Allow access if one of
the ACE's in the resulting set allows access. If the set of
matching ACEs is nonempty, and none allow access, then deny
access. Otherwise, if none of these ACEs match,
4) if the requester's access mask is allowed by the ACL_OTHER ACE,
then grant access. Otherwise, deny access.
Steps (2) and (3) have an additional criteria; in addition to check- Steps (2) and (3) have an additional criteria; in addition to check-
ing whether the requested access mask is allowed by the access mask ing whether the requested access mask is allowed by the access mask
in the ACE, the requested bits also have to be in the access mask of in the ACE, the requested bits also have to be in the access mask of
the special ACE with the ACL_MASK entity. This allows file owners to the special ACE with the ACL_MASK entity. This allows file owners to
specify a maximum level of access allowed by any other user or group specify a maximum level of access allowed by any other user or group
that has any access to the file system object. that has any access to the file system object.
In addition to a regular POSIX ACL, a directory in the file system In addition to a regular POSIX ACL, a directory in the file system
may also have associated with it a default ACL. This default ACL may also have associated with it a default ACL. This default ACL
does not affect permissions to the directory itself. Instead, it
governs the ACL a file system object will be assigned initially when governs the ACL a file system object will be assigned initially when
it is created as a child of the particular directory. it is created as a child of the particular directory.
44.. MMaappppiinngg PPoossiixx AACCLLss ttoo NNFFSSvv44 AACCLLss 4. Mapping Posix ACLs to NFSv4 ACLs
Given the difference in both extensiveness and interpretation of Given the differences between POSIX and NFSv4 ACLs, any conversion
POSIX and NFSv4 ACLs, any conversion between the two is difficult. between the two is difficult. However, POSIX ACLs are a subset of
However, POSIX ACLs are a subset of NFSv4 ACLs. Any POSIX ACL can be NFSv4 ACLs, and any POSIX ACL can be emulated with an NFSv4 ACL using
emulated with an NFSv4 ACL using the following mapping. the following mapping.
The ACE entities are translated as follows. The non-special entities First, the uid's and gid's on the ACL_USER and ACL_GROUP ACEs must be
in form of UIDs and GIDs is translated to equivalent strings (a sys- translated into NFSv4 names--a system-dependent process, which, on
tem dependent process, typically done by lookups to /etc/passwd in UNIX for example, may be done by lookups to /etc/passwd. Also, the
UNIX). The POSIX ACL_USER_OBJ entity is translated to the "OWNER" special ACL_USER_OBJ, ACL_GROUP_OBJ, and ACL_OTHER ACEs must be
NFSv4 entity. Similary, the POSIX ACL_GROUP_OBJ is translated to the translated to NFSv4 ACEs with the special entities "OWNER", "GROUP",
"GROUP" NFSv4 entity. The ACL_OTHER entity is translated to the and "EVERYONE", respectively.
"EVERYONE" NFSv4 entity.
The ACE access mask is translated as follows. The read bit of the The ACE access mask is translated as follows. The read bit of the
POSIX access mask is translated to the logical OR of the POSIX access mask is translated to the logical OR of the
Mapping NFSv4 ACLs October 2004
ACE4_READ_DATA and ACE4_READ_NAMED_ATTRS NFSv4 access mask fields. ACE4_READ_DATA and ACE4_READ_NAMED_ATTRS NFSv4 access mask fields.
The write bit of the POSIX access mask is translated to the logical The write bit of the POSIX access mask is translated to the logical
OR of the ACE4_WRITE_DATA, ACE4_WRITE_NAMED_ATTRIBUTES and OR of the ACE4_WRITE_DATA, ACE4_WRITE_NAMED_ATTRS and
ACE4_APPEND_DATA NFSv4 access mask fields. The execute bit of the ACE4_APPEND_DATA NFSv4 access mask fields. The execute bit of the
POSIX access mask is translated into the ACE4_EXECUTE and POSIX access mask is translated into the ACE4_EXECUTE and
ACE4_READ_DATA NFSv4 acess mask fields. Note that NFSv4 defines ACE4_READ_DATA NFSv4 acess mask fields. Note that NFSv4 defines
ACE4_READ_DATA, ACE4_WRITE_DATA, and ACE4_APPEND_DATA to be equal to ACE4_READ_DATA, ACE4_WRITE_DATA, and ACE4_APPEND_DATA to be equal to
ACE4_LIST_DIRECTORY, ACE4_ADD_FILE, and ACE4_ADD_SUBDIRECTORY, ACE4_LIST_DIRECTORY, ACE4_ADD_FILE, and ACE4_ADD_SUBDIRECTORY,
respectively, so this translation makes sense for directories as respectively, so this translation makes sense for directories as
well. However, on directories the ACE4_DELETE_CHILD field must be well. However, on directories the ACE4_DELETE_CHILD field must be
included in the translation of the POSIX write bit. included in the translation of the POSIX write bit.
Mapping NFSv4 ACLs February 2004
In addition to the above, the OWNER entity must always be given In addition to the above, the OWNER entity must always be given
ACE4_WRITE_ACL and ACE4_WRITE_ATTRIBUTES, and all entities must be ACE4_WRITE_ACL and ACE4_WRITE_ATTRIBUTES, and all entities must be
given ACE4_READ_ACL and ACE4_READ_ATTRIBUTES. given ACE4_READ_ACL, ACE4_READ_ATTRIBUTES, and ACE4_SYNCHRONIZE. The
ACE4_DELETE bit should be neither allowed nor denied by any ACE.
The ACE flag field also has a simple translation. If the file system The ACE flag field also has a simple translation. If the file system
object is a directory, and the POSIX ACE belongs to a default ACL, object is a directory, and the POSIX ACE belongs to a default ACL,
the "ACE4_INHERIT_ONLY_ACE" flag is set in the NFSv4 ACE. If the the ACE4_INHERIT_ONLY_ACE, ACE4_DIRECTORY_INHERIT, and
entity in the POSIX ACE refers to a group, the "ACE4_IDENTI- ACE4_FILE_INHERIT flags are set in the NFSv4 ACE. If the entity in
FIER_GROUP" flag is set in the NFSv4 ACE. the POSIX ACE refers to a group, the "ACE4_IDENTIFIER_GROUP" flag is
set in the NFSv4 ACE.
The POSIX ACL_USER_OBJ ACE is also always given the permission bits The POSIX ACL_USER_OBJ ACE is also always given the permission bits
"ACE4_READ_ACL" and "ACE4_WRITE_ACL." "ACE4_READ_ACL" and "ACE4_WRITE_ACL."
Completing the mapping reduces to being able to emulate an ACL_MASK Completing the mapping reduces to being able to emulate an ACL_MASK
and compensate for the difference in interpretation between two ACL and compensate for some differences in the permission-checking algo-
implementations. rithms of the two ACL implementations.
The difference in interpretation of the two ACL types call for a The difference in permission-checking algorithms is handled as fol-
translation scheme. The scheme follows: lows:
Every user ACE in the POSIX ACL maps into 2 NFSv4 ACEs; one ALLOW ACE Every user ACE in the POSIX ACL maps into 2 NFSv4 ACEs; one ALLOW ACE
which is translated as specified by the above scheme, then a comple- which is translated as specified by the above scheme, then a comple-
menting DENY ACE which is also translated as specified by the above menting DENY ACE which is also translated as specified by the above
scheme, with the exception that the access mask is inverted. Note scheme, with the exception that the access mask is inverted. Note
that the ACL_USER_OBJ ACE is placed first in this list. that the ACL_USER_OBJ ACE is placed first in this list.
Every group ACE in the POSIX ACL produces a similar pair, but instead Every group ACE in the POSIX ACL produces a similar pair, but instead
of being in sequence, all of the ALLOW ACEs are all in sequence, fol- of being in sequence, all of the ALLOW ACEs are all in sequence, fol-
lowed by all the DENY ACEs. The ACL_GROUP_OBJ ACE is placed first in lowed by all the DENY ACEs. The ACL_GROUP_OBJ ACE is placed first in
both lists. both lists.
Lastly, the POSIX ACL_OTHER ACE is translated into a pair of ACEs as Lastly, the POSIX ACL_OTHER ACE is translated into a pair of ACEs as
in the user ACE case. in the user ACE case.
This translation strategy allows us to emulate POSIX ACL interpreta- Mapping NFSv4 ACLs October 2004
tion in an NFSv4 ACL.
With this done, the NFSv4 permission-checking algorithm applied to
the resulting NFSv4 ACL will produce the same result as the POSIX
permission-checking algorithm did on the original POSIX ACL.
To handle the special POSIX entity ACL_MASK, we slightly modify the To handle the special POSIX entity ACL_MASK, we slightly modify the
above translation: above translation:
With the exception of the "OWNER" and "EVERYONE" ACEs, another ACE is With the exception of the "OWNER" and "EVERYONE" ACEs, another ACE is
prepended to the ACE. The prepended ACE is a DENY ACE with the same prepended to the ACE. The prepended ACE is a DENY ACE with the same
entity as the following ALLOW ACE, but with a permission mask set to entity as the following ALLOW ACE, but with a permission mask set to
the complement of the POSIX ACL_MASK. the complement of the POSIX ACL_MASK.
This method allows us to preserve the real permission bits of each This method allows us to preserve the real permission bits of each
ACE should the ACL_MASK be changed. ACE should the ACL_MASK be changed.
Mapping NFSv4 ACLs February 2004 5. Using the Mapping in NFSv4 Implementations
55.. SSeeccuurriittyy CCoonnssiiddeerraattiioonnss Note that the algorithm described in the previous section not only
provides a way to map any POSIX ACL to be mapped to an NFSv4 ACL with
similar semantics, but also provides the reverse mapping in the case
where the NFSv4 ACL is precisely in the format of an ACL produced by
the algorithm above.
Since this draft deals with the mapping of Access Control Lists, it The algorithm can therefore be used to implement a subset of the
is deeply involved with security. The body of this document needs to NFSv4 ACL model. This may be useful to NFSv4 clients and servers
address the issue of mapping ACLs in a way as to not disobey the with preexisting system interfaces that support POSIX ACLs and that
intent of or mislead the user. cannot be modified to support NFSv4 ACLs.
Mapping NFSv4 ACLs February 2004 A server, for example, that wishes to export via NFSv4 a filesystem
that supports only POSIX ACLs, may use this mapping to answer client
requests for existing ACLs by translating POSIX ACLs on its filesys-
tem to NFSv4 ACLs to send to the client. However, when a client
attempts to set an ACL, the server faces a problem. If the given ACL
happens to be in precisely the format of an ACL produced by this map-
ping (as would happen if, for example, the client was performing the
same translation), then the server can map it to a POSIX ACL to store
on the filesystem. But for any other NFSv4 ACL, the server should
return an error to avoid any chance of inaccurately representing the
client's intention.
66.. BBiibblliiooggrraapphhyy The language of [rfc3530] allows a server some flexibility in han-
dling ACLs that it cannot enforce completely accurately, as long as
it adheres to "the guiding principle... that the server must not
accept ACLs that appear to make [a file] more secure than it really
is."
[rfc3010bis] Mapping NFSv4 ACLs October 2004
Shepler, S. et. al., "NFS version 4 Protocol", draft-ietf-
nfsv4-rfc3010bis-05.txt, April 2003.
http://www.ietf.org/internet-drafts/draft-ietf- It may therefore be possible for a server to accept a wider range of
nfsv4-rfc3010bis-05.txt NFSv4 ACLs, as long as it can ensure that in every case the resulting
POSIX ACL denies at least all access that the original NFSv4 ACL
denied. The results of such a mapping may, however, be somewhat
unexpected, and it is preferable simply to refuse all NFSv4 ACLs that
do not map accurately, and provide clients with software to help gen-
erate POSIX-mappable NFSv4 ACLs if necessary.
[posixacl] Similarly, a client that uses NFSv4 ACLS to implement user interfaces
IEEE, "IEEE Draft P1003.1e", October 1997 (last draft). that only deal in POSIX ACLs may handle user requests to set ACLs
easily enough, but should return errors when the user requests ACLs
that, on consulting the server, turn out to not be mappable to POSIX
ACLs.
http://wt.xpilot.org/publications/posix.1e/download.html Mapping NFSv4 ACLs October 2004
Mapping NFSv4 ACLs February 2004 6. Security Considerations
77.. AAcckknnoowwlleeddggmmeennttss Any automatic mapping from one ACL model to another must provide
guarantees that the mapping preserves semantics, or risk misleading
users about the permissions set on filesystem objects. For this rea-
son, we recommend performing such mapping only when it can be done
accurately, and returning errors in all other cases.
The author would like to thank and acknowledge Bruce Fields for his Mapping NFSv4 ACLs October 2004
careful scrutiny and excellent comments and suggestions.
Mapping NFSv4 ACLs February 2004 7. Bibliography
88.. AAuutthhoorr''ss AAddddrreessss [rfc3530]
Shepler, S. et. al., "NFS version 4 Protocol", April 2003.
http://www.ietf.org/rfc/rfc3530.txt
[posixacl]
IEEE, "IEEE Draft P1003.1e", October 1997 (last draft).
http://wt.xpilot.org/publications/posix.1e/download.html
Mapping NFSv4 ACLs October 2004
8. Author's Address
Address comments related to this memorandum to: Address comments related to this memorandum to:
marius@umich.edu marius@umich.edu bfields@umich.edu
Marius Aamodt Eriksen Marius Aamodt Eriksen
J. Bruce Fields
University of Michigan / CITI University of Michigan / CITI
535 West William 535 West William
Ann Arbor, Michigan Ann Arbor, Michigan
E-mail: marius@umich.edu E-mail: marius@umich.edu
E-mail: bfields@umich.edu
99.. CCooppyyrriigghhtt 9. Copyright
Copyright (C) The Internet Society (2002-2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this doc-
ument itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be Copyright (C) The Internet Society (2004). This document is subject
revoked by the Internet Society or its successors or assigns. to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein is provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/