draft-ietf-nfsv4-acl-mapping-02.txt		draft-ietf-nfsv4-acl-mapping-03.txt
	Network Working Group Marius Aamodt Eriksen		Network Working Group Marius Aamodt Eriksen
	Internet Draft J. Bruce Fields		Internet Draft J. Bruce Fields
	Document: draft-ietf-nfsv4-acl-mapping-02.txt October 2004		Document: draft-ietf-nfsv4-acl-mapping-03.txt February 2005
	Mapping Between NFSv4 and Posix Draft ACLs		Mapping Between NFSv4 and Posix Draft ACLs
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		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-		or will be disclosed, and any of which I become aware will be dis-
	closed, in accordance with RFC 3668.		closed, in accordance with RFC 3668.
	skipping to change at page 2, line 5		skipping to change at page 2, line 5
	"Copyright (C) The Internet Society (2002-2004). All Rights		"Copyright (C) The Internet Society (2002-2004). All Rights
	Reserved."		Reserved."
	Abstract		Abstract
	NFS version 4 [rfc3530] (NFSv4) specifies a flavor of Access Control		NFS version 4 [rfc3530] (NFSv4) specifies a flavor of Access Control
	Lists (ACLs) resembling Windows NT ACLs. A number of operating sys-		Lists (ACLs) resembling Windows NT ACLs. A number of operating sys-
	tems use a different flavor of ACL based on a withdrawn POSIX draft.		tems use a different flavor of ACL based on a withdrawn POSIX draft.
	NFSv4 clients and servers on such operating systems may wish to map		NFSv4 clients and servers on such operating systems may wish to map
	Mapping NFSv4 ACLs October 2004		Mapping NFSv4 ACLs February 2005
	between NFSv4 ACLs and their native ACLs. To this end, we describe a		between NFSv4 ACLs and their native ACLs. To this end, we describe a
	mapping from POSIX draft ACLs to a subset of NFSv4 ACLs.		mapping from POSIX draft ACLs to a subset of NFSv4 ACLs.
	Mapping NFSv4 ACLs October 2004		Mapping NFSv4 ACLs February 2005
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. NFSv4 ACLs . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. NFSv4 ACLs . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. POSIX ACLs . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. POSIX ACLs . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Mapping Posix ACLs to NFSv4 ACLs . . . . . . . . . . . . . . 6		4. Mapping POSIX ACLs to NFSv4 ACLs . . . . . . . . . . . . . . 6
	5. Using the Mapping in NFSv4 Implementations . . . . . . . . . 8		5. Using the Mapping in NFSv4 Implementations . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . 10		6. Security Considerations . . . . . . . . . . . . . . . . . 11
	7. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 11		7. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 12
	8. Author's Address . . . . . . . . . . . . . . . . . . . . . 12		8. Author's Address . . . . . . . . . . . . . . . . . . . . . 13
	9. Copyright . . . . . . . . . . . . . . . . . . . . . . . . 12		9. Copyright . . . . . . . . . . . . . . . . . . . . . . . . 13
	Mapping NFSv4 ACLs October 2004		Mapping NFSv4 ACLs February 2005
	1. Introduction		1. Introduction
	Access Control Lists (ACLs) are used to specify fine-grained 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		rights to file system objects. An ACL is a list of Access Control
	Control Entries (ACEs), each specifying some level of access for an		Entries (ACEs), each specifying an entity (such as a user) and some
	entity. The entity may be a user, a group, or a special entity (such		level of access for that entity.
	as "everyone"). The level of access is described using an access
	mask, which is a bitmask with each bit corresponding to a type of
	access (such as "read" or "append").
	In the following sections we describe two ACL models: NFSv4 ACLs, and		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		ACLs based on a withdrawn POSIX draft. We will refer to the latter
	"POSIX ACLs". Since NFSv4 ACLs are much finer-grained than POSIX		as "POSIX ACLs". Since NFSv4 ACLs are more fine-grained than POSIX
	ACLs, it is not possible in general to map an arbitrary NFSv4 ACL to		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		a POSIX ACL with the same semantics. However, it is possible to map
	be possible to map any POSIX ACL to a NFSv4 ACL that has nearly iden-		any POSIX ACL to a NFSv4 ACL with nearly identical semantics. We
	tical semantics. We will describe such a mapping, and discuss how it		will describe such a mapping, and discuss its use in NFSv4 clients
	might be used in NFSv4 client and server implementations.		and servers.
	2. NFSv4 ACLs		2. NFSv4 ACLs
	An NFSv4 ACL is an ordered sequence of ACEs, each having an entity, a		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		type, some flags, and an access mask.
	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".
	The access mask includes bits for access types that are more fine-		The entity may be the name of a user or group, or may be one of a
	grained than the traditional "read", "write", and "execute" permis-		small set of special entities. Among the special entities are
	sions used in UNIX mode bits.		"OWNER@" (the current owner of the file), "GROUP@" (the group associ-
			ated with the file), and "EVERYONE@".
	The type may be ALLOW or DENY. (AUDIT or ALARM are also allowed, but		The type may be ALLOW or DENY. (AUDIT or ALARM are also allowed, but
	they are not relevant to our discussion).		they are not relevant to our discussion).
	The NFSv4 ACL permission-checking algorithm is straightforward.		The access mask has 14 separate bits, including bits to control read,
	Given an ACL and a requestor asking for a set of permissions speci-		write, execute, append, ACL modification, file owner modification,
	fied by an access mask:		etc.; consult [rfc3530] for the full list.
	1) Walk through the list of ACEs from the ACL in order.
	2) Ignore any ACE for with an entity not matching requestor.
	Mapping NFSv4 ACLs October 2004
	3) Process all ACEs until all the bits in the requested access mask		Of the flags, four are relevant here. The ACE4_IDENTIFIER_GROUP flag
	have been ALLOWed by an ALLOW ace with that bit set. Once a par-		is used to indicate that the entity name is the name of a group. The
	ticular bit has been ALLOWed by an ACE, it is no longer considered		other three concern inheritance: ACE4_DIRECTORY_INHERIT_ACE indicates
	in further processing.		that the ACE should be added to new subdirectories of the directory;
			ACE4_FILE_INHERIT_ACE does the same for new files; and
			ACE4_INHERIT_ONLY indicates that the ACE should be ignored when
			determining access to the directory itself.
	4) If a bit in the requested access mask is DENYed (while that bit is		The NFSv4 ACL permission-checking algorithm is straightforward.
	still under consideration), the request is denied.		Assume a a requester asks for access, as specified by a single bit in
	5) If all bits have been ALLOWed, the access is granted. Otherwise		Mapping NFSv4 ACLs February 2005
	behavior is undefined.
	There are also a number of flags that can be applied to an NFSv4 ACE.		the access bitmask. We allow the access if the first ACE in the ACL
	Three flags that we will need to use in the following discussion		that matches the requester and that has that bit set is an ALLOW ACE,
	apply to ACEs in a directory ACL. They are: ACE4_DIREC-		and we deny the access if the first such ACE is a DENY ACE. If no
	TORY_INHERIT_ACE, which indicates that the ACE should be added to new		matching ACE has the bit in question set, behaviour is undefined. If
	subdirectories of the directory; ACE4_FILE_INHERIT_ACE, which does		an access mask consisting of more than one bit is requested, it suc-
	the same for new files; and ACE4_INHERIT_ONLY, which indicates that		ceeds if and only if each bit in the mask is allowed.
	the ACE should be ignored when determining access to the directory
	itself.
	We refer the reader to [rfc3530] for further details.		We refer the reader to [rfc3530] for further details.
	3. POSIX ACLs		3. POSIX ACLs
	A number of operating systems, including Linux and FreeBSD, implement		A number of operating systems implement ACLs based on the withdrawn
	ACLs based on the withdrawn POSIX 1003.1e/1003.2c Draft Standard 17		POSIX 1003.1e/1003.2c Draft Standard 17 [posixacl]. We will refer to
	[posixacl]. We will refer to such ACLs as "POSIX ACLs".		such ACLs as "POSIX ACLs".
	POSIX ACLs use access masks with only the traditional "read",		POSIX ACLs use access masks with only the traditional "read",
	"write", and "execute" bits. Each ACE in a POSIX ACL is one of five		"write", and "execute" bits. Each ACE in a POSIX ACL is one of five
	types: ACL_USER_OBJ, ACL_USER, ACL_GROUP_OBJ, ACL_GROUP, ACL_MASK,		types: ACL_USER_OBJ, ACL_USER, ACL_GROUP_OBJ, ACL_GROUP, ACL_MASK,
	and ACL_OTHER. Each ACL_USER ACE has a uid associated with it, and		and ACL_OTHER. Each ACL_USER ACE has a uid associated with it, and
	each ACL_GROUP ACE has a gid associated with it. Every POSIX ACL		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		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		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		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		ACEs with the same uid, and there may not be two ACL_GROUP ACEs with
	the same gid.		the same gid.
	Given a POSIX ACL and a requestor asking for access, permission is		Given a POSIX ACL and a requester asking for access, permission is
	determined as follows:		determined as follows:
	1) If the requestor is the file owner, then allow or deny access		1) If the requester is the file owner, then allow or deny access
	depending on whether the ACL_USER_OBJ ACE allows or denies it.		depending on whether the ACL_USER_OBJ ACE allows or denies it.
	Mapping NFSv4 ACLs October 2004
	Otherwise,		Otherwise,
	2) if the requestor's uid matches the uid of one of the ACL_USER		2) if the requester's uid matches the uid of one of the ACL_USER
	ACE's, then allow or deny access depending on whether the		ACEs, then allow or deny access depending on whether the
	ACL_USER_OBJ ACE allows or denies it. Otherwise,		ACL_USER_OBJ ACE allows or denies it. Otherwise,
	3) Consider the set of all ACL_GROUP ACE's whose gid the requestor is		3) Consider the set of all ACL_GROUP ACEs whose gid the requester is
	a member of. Add to that set the ACL_GROUP_OBJ ACE, if the		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		requester is also a member of the file's group. Allow access if
	the ACE's in the resulting set allows access. If the set of		any ACE in the resulting set allows access. If the set of match-
	matching ACEs is nonempty, and none allow access, then deny		ing ACEs is nonempty, and none allow access, then deny access.
	access. Otherwise, if none of these ACEs match,		Otherwise, if the set of matching ACEs is empty,
			Mapping NFSv4 ACLs February 2005
	4) if the requester's access mask is allowed by the ACL_OTHER ACE,		4) if the requester's access mask is allowed by the ACL_OTHER ACE,
	then grant access. Otherwise, deny access.		then grant access. Otherwise, deny access.
	Steps (2) and (3) have an additional criteria; in addition to check-		The above description omits one detail: in steps (2) and (3), the
	ing whether the requested access mask is allowed by the access mask		requested bits must be granted both by the matching ACE and by the
	in the ACE, the requested bits also have to be in the access mask of		ACL_MASK ACE. The ACL_MASK ACE thus limits the maximum permissions
	the special ACE with the ACL_MASK entity. This allows file owners to		which may be granted by any ACL_USER or ACL_GROUP ACE, or by the
	specify a maximum level of access allowed by any other user or group		ACL_GROUP_OBJ ACE.
	that has any access to the file system object.
	In addition to a regular POSIX ACL, a directory in the file system		Each file may have a single POSIX ACL associated with it, used to
	may also have associated with it a default ACL. This default ACL		determine access to that file. Directories, however, may have two
	does not affect permissions to the directory itself. Instead, it		ACLs: one, the "access ACL", used to determine access to the direc-
	governs the ACL a file system object will be assigned initially when		tory, and one, the "default ACL", used only as the ACL to be inher-
	it is created as a child of the particular directory.		ited by newly created objects in the directory.
	4. Mapping Posix ACLs to NFSv4 ACLs		4. Mapping POSIX ACLs to NFSv4 ACLs
	Given the differences between POSIX and NFSv4 ACLs, any conversion		We now describe an algorithm which maps any POSIX ACL to an NFSv4 ACL
	between the two is difficult. However, POSIX ACLs are a subset of		with the same semantics.
	NFSv4 ACLs, and any POSIX ACL can be emulated with an NFSv4 ACL using
	the following mapping.
	First, the uid's and gid's on the ACL_USER and ACL_GROUP ACEs must be		First, translate the uid's and gid's on the ACL_USER and ACL_GROUP
	translated into NFSv4 names--a system-dependent process, which, on		ACEs into NFSv4 names. This is an implementation-dependent process.
	UNIX for example, may be done by lookups to /etc/passwd. Also, the		It might be done, for example, by consulting a directory service or a
	special ACL_USER_OBJ, ACL_GROUP_OBJ, and ACL_OTHER ACEs must be		password file. Also, the special ACL_USER_OBJ, ACL_GROUP_OBJ, and
	translated to NFSv4 ACEs with the special entities "OWNER", "GROUP",		ACL_OTHER ACEs must be translated to NFSv4 ACEs with the special
	and "EVERYONE", respectively.		entities "OWNER@", "GROUP@", and "EVERYONE@", respectively.
	The ACE access mask is translated as follows. The read bit of the		Next, map each POSIX ACE (excepting any mask ACE) in the given POSIX
	POSIX access mask is translated to the logical OR of the		ACL to an NFSv4 ALLOW ACE with an entity determined as above, and
			with a bitmask determined from the permission bits on the POSIX ACE
			as follows:
	Mapping NFSv4 ACLs October 2004		1) If the read bit is set in the POSIX ACE, then set ACE4_READ_DATA.
	ACE4_READ_DATA and ACE4_READ_NAMED_ATTRS NFSv4 access mask fields.		2) If the write bit is set in the POSIX ACE, then set ACE4_WRITE_DATA
	The write bit of the POSIX access mask is translated to the logical		and ACE4_APPEND_DATA. If the object carrying the ACL is a direc-
	OR of the ACE4_WRITE_DATA, ACE4_WRITE_NAMED_ATTRS and		tory, set ACE4_DELETE_CHILD as well.
	ACE4_APPEND_DATA NFSv4 access mask fields. The execute bit of the
	POSIX access mask is translated into the ACE4_EXECUTE and
	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_LIST_DIRECTORY, ACE4_ADD_FILE, and ACE4_ADD_SUBDIRECTORY,
	respectively, so this translation makes sense for directories as
	well. However, on directories the ACE4_DELETE_CHILD field must be
	included in the translation of the POSIX write bit.
	In addition to the above, the OWNER entity must always be given		3) If the execute bit is set in the POSIX ACE, then set ACE4_EXECUTE.
	ACE4_WRITE_ACL and ACE4_WRITE_ATTRIBUTES, and all entities must be
	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		4) Set ACE4_READ_ACL, ACE4_READ_ATTRIBUTES, and ACE4_SYNCHRONIZE
	object is a directory, and the POSIX ACE belongs to a default ACL,		unconditionally.
	the ACE4_INHERIT_ONLY_ACE, ACE4_DIRECTORY_INHERIT, and
	ACE4_FILE_INHERIT flags are set in the NFSv4 ACE. If the entity in
	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		5) If the ACE is for the special "OWNER@" entity, set ACE4_WRITE_ACL
	"ACE4_READ_ACL" and "ACE4_WRITE_ACL."		and ACE4_WRITE_ATTRIBUTES.
	Completing the mapping reduces to being able to emulate an ACL_MASK		Mapping NFSv4 ACLs February 2005
	and compensate for some differences in the permission-checking algo-
	rithms of the two ACL implementations.
	The difference in permission-checking algorithms is handled as fol-		6) Clear all other bits in the NFSv4 bitmask.
	lows:
	Every user ACE in the POSIX ACL maps into 2 NFSv4 ACEs; one ALLOW ACE		In addition, we set the GROUP flag in each ACE which corresponds to a
	which is translated as specified by the above scheme, then a comple-		named group (but not in the GROUP@ ACE, or any of the other special
	menting DENY ACE which is also translated as specified by the above		entity ACEs). At this point, we've replaced the POSIX ACL by an
	scheme, with the exception that the access mask is inverted. Note		NFSv4 ACL with the same number of ACEs (ignoring any mask ACE). To
	that the ACL_USER_OBJ ACE is placed first in this list.		emulate the POSIX ACL permission-checking algorithm, we need to mod-
			ify the ACL further, as follows:
	Every group ACE in the POSIX ACL produces a similar pair, but instead		1) Order the ACL so that the OWNER@ ACE is the first ACE of the ACL,
	of being in sequence, all of the ALLOW ACEs are all in sequence, fol-		followed by any user ACEs, followed by the GROUP@ ACE, followed by
	lowed by all the DENY ACEs. The ACL_GROUP_OBJ ACE is placed first in		any group ACEs, and ending finally with the EVERYONE@ ACE.
	both lists.
	Lastly, the POSIX ACL_OTHER ACE is translated into a pair of ACEs as		2) The POSIX algorithm stops as soon as the requester matches an
	in the user ACE case.		ACL_USER_OBJ, ACL_OTHER, or ACL_USER ACE. To emulate this
			behaviour, add a single DENY ACE after each ALLOW ACE for OWNER@,
			EVERYONE@, or any named user. The DENY ACE should have the same
			entity and flags as the corresponding ALLOW ACE. The bitmask on
			the DENY ACE should be the bitwise NOT of the bitmask on the ALLOW
			ACE, except that the ACE4_WRITE_OWNER and ACE4_DELETE bits should
			be cleared, and the ACE4_DELETE_CHILD bit should be cleared on
			non-directories. (Also, in the xdr-encoded ACL that is transmit-
			ted, all bits not defined in the protocol should be cleared.)
	Mapping NFSv4 ACLs October 2004		3) Unlike the other ACEs in step 2, all of the ACL_GROUP_OBJ and
			ACL_GROUP ACEs are consulted by the POSIX algorithm before deter-
			mining permissions. However, if the requester matches any one of
			them, then it must deny any permissions they do not allow. To
			emulate this behaviour, instead of adding a single DENY after each
			corresponding GROUP@ or named group ACE, we insert a list of DENY
			ACEs at the end of the list of GROUP@ and named group ACEs. Each
			DENY ACE is determined from its corresponding ALLOW ACE exactly as
			in step 2, and should occur in the inserted list in the same posi-
			tion as the corresponding ALLOW ACE occurs in the list of ALLOW
			ACEs.
	With this done, the NFSv4 permission-checking algorithm applied to		4) Finally, we enforce the POSIX mask ACE by prepending each ALLOW
	the resulting NFSv4 ACL will produce the same result as the POSIX		ACE for a named user, GROUP@, or named group, with a single DENY
	permission-checking algorithm did on the original POSIX ACL.		ACE whose entity and flags are the same as those for the corre-
			sponding ALLOW ACE, but whose bitmask is the inverse of the bit-
			mask determined from the mask ACE, with the inverse calculated as
			described in step 2.
	To handle the special POSIX entity ACL_MASK, we slightly modify the		As an example, take a POSIX ACL with two named users (u1 and u2) and
	above translation:		two named groups (g1 and g2), in addition to the required
			ACL_USER_OBJ, ACL_GROUP_OBJ, ACL_OTHER, and ACL_MASK ACEs.
	With the exception of the "OWNER" and "EVERYONE" ACEs, another ACE is		Such an ACL will map to an NFSv4 ACL of the form
	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
	the complement of the POSIX ACL_MASK.
	This method allows us to preserve the real permission bits of each		Mapping NFSv4 ACLs February 2005
	ACE should the ACL_MASK be changed.
			ALLOW OWNER@
			DENY OWNER@
			DENY u1 (mask)
			ALLOW u1
			DENY u1
			DENY u2 (mask)
			ALLOW u2
			DENY u2
			DENY GROUP@ (mask)
			ALLOW GROUP@
			DENY g1 (mask)
			ALLOW g1
			DENY g2 (mask)
			ALLOW g2
			DENY GROUP@
			DENY g1
			DENY g2
			ALLOW EVERYONE@
			DENY EVERYONE@
			where the ACEs marked with (mask) are those whose bitmask are deter-
			mined from the ACL_MASK ACE as described in step 4 above.
			In general, a POSIX ACL with m named users and n named groups will
			map to an NFSv4 ACL with (3*(m + n) + 7) ACLs, unless m and n are
			both zero, in which case the result will have either 6 or 7 ACLs,
			depending on whether the original ACL had an ACL_MASK ACE.
			On directories with default ACLs, we translate the default ACL as
			above, but set the ACE4_INHERIT_ONLY_ACE, ACE4_DIRECTORY_INHERIT_ACE,
			and ACE4_FILE_INHERIT_ACE flags on every ACE in the resulting ACL.
			On directories with both default and access ACLs, we translate the
			two ACLs and then concatenate them. The order of the concatenation
			is unimportant.
			There is one extremely minor inaccuracy in this mapping: if a
			requester that is a member of more than one group listed in the ACL
			requests multiple bits simultaneously, the POSIX algorithm requires
			all of the bits to be granted simultaneously by one of the group
			ACEs. Thus a POSIX ACL such as
			ACL_USER_OBJ: ---
			ACL_GROUP_OBJ: ---
			g1: r--
			g2: -w-
			ACL_MASK: rw-
			ACL_OTHER: ---
			Mapping NFSv4 ACLs February 2005
			will prevent a user that is a member of groups g1 and g2 from opening
			a file for both read and write, even though read and write would be
			individually permitted.
			The NFSv4 ACL permission-checking algorithm has the property that it
			permits a group of bits whenever it would permit each bit individu-
			ally, so it is impossible to mimic this behaviour with an NFSv4 ACL.
	5. Using the Mapping in NFSv4 Implementations		5. Using the Mapping in NFSv4 Implementations
	Note that the algorithm described in the previous section not only		Examination of the algorithm described in the previous section shows
	provides a way to map any POSIX ACL to be mapped to an NFSv4 ACL with		that no information is lost; the original POSIX ACL can be recon-
	similar semantics, but also provides the reverse mapping in the case		structed from the mapped NFSv4 ACL. Thus we also have a way to map
	where the NFSv4 ACL is precisely in the format of an ACL produced by		NFSv4 ACLs to POSIX ACLs in the case where the NFSv4 ACL is precisely
	the algorithm above.		in the format of an ACL produced by the algorithm above.
	The algorithm can therefore be used to implement a subset of the		The algorithm can therefore be used to implement a subset of the
	NFSv4 ACL model. This may be useful to NFSv4 clients and servers		NFSv4 ACL model. This may be useful to NFSv4 clients and servers
	with preexisting system interfaces that support POSIX ACLs and that		with preexisting system interfaces that support POSIX ACLs and that
	cannot be modified to support NFSv4 ACLs.		cannot be modified to support NFSv4 ACLs.
	A server, for example, that wishes to export via NFSv4 a filesystem		A server, for example, that wishes to export via NFSv4 a filesystem
	that supports only POSIX ACLs, may use this mapping to answer client		that supports only POSIX ACLs, may use this mapping to answer client
	requests for existing ACLs by translating POSIX ACLs on its filesys-		requests for existing ACLs by translating POSIX ACLs on its filesys-
	tem to NFSv4 ACLs to send to the client. However, when a client		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		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-		is not in precisely the format of an ACL produced by this mapping,
	ping (as would happen if, for example, the client was performing the		then the server may be required to return an error to avoid inaccu-
	same translation), then the server can map it to a POSIX ACL to store		rately representing the client's intention. The correct error to
	on the filesystem. But for any other NFSv4 ACL, the server should		return in this case is NFS4ERR_ATTRNOTSUPP.
	return an error to avoid any chance of inaccurately representing the
	client's intention.
	The language of [rfc3530] allows a server some flexibility in han-		In the case where a client sets an ACL that leaves certain bits nei-
	dling ACLs that it cannot enforce completely accurately, as long as		ther allowed nor denied, the server may choose to allow or deny those
	it adheres to "the guiding principle... that the server must not		bits as necessary to make mapping possible. In some situations it
	accept ACLs that appear to make [a file] more secure than it really		may also be possible for a server to map the ACL if it adds a DENY
	is."		ACE or denies a few additional bits. The language of [rfc3530]
			allows a server some flexibility in handling 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."
	Mapping NFSv4 ACLs October 2004		Given the choice, as long as the "guiding principle" is not violated,
			servers should opt to be forgiving. The complexity of the
			POSIX<->NFSv4 mapping makes difficult the task of generating ACLs
	It may therefore be possible for a server to accept a wider range of		Mapping NFSv4 ACLs February 2005
	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.
	Similarly, a client that uses NFSv4 ACLS to implement user interfaces		that will satisfy a server using the mapping. By making the mapping
	that only deal in POSIX ACLs may handle user requests to set ACLs		more forgiving, the server can simplify that task, improving interop-
	easily enough, but should return errors when the user requests ACLs		erability.
	that, on consulting the server, turn out to not be mappable to POSIX
	ACLs.
	Mapping NFSv4 ACLs October 2004		Servers that implement the full NFSv4 protocol should also handle
			carefully ACLs that leave bits neither allowed nor denied. It is
			better to fall back on some reasonable default rather than to always
			allow or always deny. A client that, for example, sets
			ACE4_WRITE_DATA but leaves unspecified ACE4_APPEND_DATA probably does
			so because its system interfaces are incapable of independently rep-
			resenting ACE4_APPEND_DATA, not because it intends to deny
			ACE4_APPEND_DATA. By leaving the bit unspecified, the client leaves
			the server the opportunity to provide the reasonable default of set-
			ting it to match ACE4_WRITE_DATA.
			Similar issues exist when a client uses NFSv4 ACLs to implement user
			interfaces that only deal in POSIX ACLs. When the client translates
			ACLs received from the server to POSIX ACLs, some flexibility may
			help interopability, but the client must take care not to represent
			any ACLs as stricter than they really are. Clients that provide
			access to the full set of NFSv4 ACLs may also wish to provide users
			with utilities to generate and interpret POSIX-mapped NFSv4 ACLs, to
			aid users working with servers using the POSIX mapping.
			Mapping NFSv4 ACLs February 2005
	6. Security Considerations		6. Security Considerations
	Any automatic mapping from one ACL model to another must provide		Any automatic mapping from one ACL model to another must provide
	guarantees that the mapping preserves semantics, or risk misleading		guarantees as to how the mapping affects the meaning of ACLs, or risk
	users about the permissions set on filesystem objects. For this rea-		misleading users about the permissions set on filesystem objects.
	son, we recommend performing such mapping only when it can be done		For this reason, caution is recommended when implementing this map-
	accurately, and returning errors in all other cases.		ping. It is better to return errors than to break any such guaran-
			tees.
	Mapping NFSv4 ACLs October 2004		Note also that this ACL mapping requires mapping between NFSv4 user-
			names and local id's. When the mapping of id's depends on remote
			services, the method used for the mapping must be at least as secure
			as the method used to set or get ACLs.
			Mapping NFSv4 ACLs February 2005
	7. Bibliography		7. Bibliography
	[rfc3530]		[rfc3530]
	Shepler, S. et. al., "NFS version 4 Protocol", April 2003.		Shepler, S. et. al., "NFS version 4 Protocol", April 2003.
	http://www.ietf.org/rfc/rfc3530.txt		http://www.ietf.org/rfc/rfc3530.txt
	[posixacl]		[posixacl]
	IEEE, "IEEE Draft P1003.1e", October 1997 (last draft).		IEEE, "IEEE Draft P1003.1e", October 1997 (last draft).
	http://wt.xpilot.org/publications/posix.1e/download.html		http://wt.xpilot.org/publications/posix.1e/download.html
	Mapping NFSv4 ACLs October 2004		Mapping NFSv4 ACLs February 2005
	8. Author's Address		8. Author's Address
	Address comments related to this memorandum to:		Address comments related to this memorandum to:
	marius@umich.edu bfields@umich.edu		marius@umich.edu bfields@umich.edu
	Marius Aamodt Eriksen		Marius Aamodt Eriksen
	J. Bruce Fields		J. Bruce Fields
	University of Michigan / CITI		University of Michigan / CITI
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/