wdiff draft-ietf-nfsv4-acl-mapping-03.txt draft-ietf-nfsv4-acl-mapping-04.txt

Network Working Group Marius Aamodt M. Eriksen
Internet Draft
Internet-Draft J. Bruce Fields
Document: draft-ietf-nfsv4-acl-mapping-03.txt February 2005
Expires: November 16, 2006 CITI
May 15, 2006

Mapping Between NFSv4 and Posix Draft ACLs
draft-ietf-nfsv4-acl-mapping-04

Status of this Memo

By submitting this Internet-Draft, I certify each author represents that any
applicable patent or other IPR claims of which I am he or she is aware
have been disclosed, or will be disclosed, and any of which I become he or she becomes
aware will be dis-
closed, disclosed, in accordance with RFC 3668.

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 6 of RFC2026. 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 Internet-Drafts as reference mate-
rial
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
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.

"Copyright

This Internet-Draft will expire on November 16, 2006.

Abstract

NFS version 4 [rfc3530] (NFSv4) specifies a flavor of Access Control
Lists (ACLs) resembling Windows NT ACLs.

A number of operating sys-
tems use a different flavor of ACL filesystems and applications support ACLs based on a
withdrawn POSIX draft.
NFSv4 clients and servers on such operating systems may wish to map

Mapping NFSv4 ACLs February 2005

between NFSv4 ACLs and their native ACLs. To this end, we describe a
mapping from POSIX draft [2]. Those ACLs to a subset of NFSv4 ACLs.

Mapping NFSv4 ACLs February 2005

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. NFSv4 ACLs . . . . . . . . . . . . . . . . . . . . . . . . . differ significantly from NFS
version 4
3. POSIX ACLs . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Mapping POSIX (NFSv4) ACLs [1]. We describe how to NFSv4 ACLs . . . . . . . . . . . . . . 6
5. Using translate between the Mapping in NFSv4 Implementations . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . 11
7. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 12
8. Author's Address . . . . . . . . . . . . . . . . . . . . . 13
9. Copyright . . . . . . . . . . . . . . . . . . . . . . . . 13

Mapping NFSv4 ACLs February 2005
two types of ACLs.

1. Introduction

Access Control Lists (ACLs) are used to specify fine-grained access
rights to file system objects. An ACL is a list of Access Control
Entries (ACEs), each specifying an entity (such as a user) and some
level of access for that entity.

In the following sections we describe two ACL models: NFSv4 ACLs, and
ACLs based on a withdrawn POSIX draft. We will refer to the latter
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
a POSIX ACL with the same semantics. However, it is possible to map
any POSIX ACL to a NFSv4 ACL with nearly identical semantics. semantics, and it
is possible to map any NFSv4 ACL to a POSIX ACL in a way that
preserves certain guarantees. We will describe such a mapping, explain how to do this, and discuss its use in NFSv4
give guidelines for clients and servers. servers performing such translation.

2. NFSv4 ACLs

An NFSv4 ACL is an ordered sequence of ACEs, each having an entity, a
type, some flags, and an access mask.

The entity may be the name of a user or group, or may be one of a
small set of special entities. Among the special entities are
"OWNER@" (the current owner of the file), "GROUP@" (the group associ-
ated
associated with the file), and "EVERYONE@".

The type may be ALLOW or DENY. (AUDIT or ALARM are also allowed, but
they are not relevant to our discussion).

The access mask has 14 separate bits, including bits to control read,
write, execute, append, ACL modification, file owner modification,
etc.; consult [rfc3530] [1] for the full list.

Of the flags, four are relevant here. The ACE4_IDENTIFIER_GROUP flag
is used to indicate that the entity name is the name of a group. The
other three concern inheritance: ACE4_DIRECTORY_INHERIT_ACE indicates
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.

The NFSv4 ACL permission-checking algorithm is straightforward.
Assume a a requester asks for access, as specified by a single bit in

Mapping NFSv4 ACLs February 2005
the access bitmask. We allow the access if the first ACE in the ACL
that matches the requester and that has that bit set is an ALLOW ACE,
and we deny the access if the first such ACE is a DENY ACE. If no
matching ACE has the bit in question set, behaviour is undefined. If
an access mask consisting of more than one bit is requested, it suc-
ceeds
succeeds if and only if each bit in the mask is allowed.

We refer the reader to [rfc3530] [1] for further details.

3. POSIX ACLs

A number of operating systems implement ACLs based on the withdrawn
POSIX 1003.1e/1003.2c Draft Standard 17 [posixacl]. [2]. We will refer to such
ACLs as "POSIX ACLs".

POSIX ACLs use access masks with only the traditional "read",
"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,
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
must have exactly one ACL_USER_OBJ, ACL_GROUP, ACL_GROUP_OBJ, 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.

Given a POSIX ACL and a requester asking for access, permission is
determined as follows:

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.
Otherwise,

2. if the requester's uid matches the uid of one of the ACL_USER
ACEs, 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 ACEs whose gid the requester is
a member of. Add to that set the ACL_GROUP_OBJ ACE, if the
requester is also a member of the file's group. Allow access if
any ACE in the resulting set allows access. If the set of match-
ing
matching ACEs is nonempty, and none allow access, then deny
access. 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,
then grant access. Otherwise, deny access.

The above description omits one detail: in steps (2) and (3), the
requested bits must be granted both by the matching ACE and by the
ACL_MASK ACE. The ACL_MASK ACE thus limits the maximum permissions
which may be granted by any ACL_USER or ACL_GROUP ACE, or by the
ACL_GROUP_OBJ ACE.

Each file may have a single POSIX ACL associated with it, used to
determine access to that file. Directories, however, may have two
ACLs: one, the "access ACL", used to determine access to the direc-
tory,
directory, and one, the "default ACL", used only as the ACL to be inher-
ited
inherited by newly created objects in the directory.

4. Mapping Ordering of NFSv4 and POSIX ACLs to NFSv4

POSIX ACLs

We now describe an algorithm are unordered--the order in which maps any the POSIX ACL access-
checking algorithm considers the entries is determined entirely by
the type of the entries, so the entries don't need to be kept in any
particular order.

By contrast, the meaning of an NFSv4 ACL
with can be dramatically changed
by modifying the same semantics.

First, translate order that the uid's and gid's on entries are listed in.

In the ACL_USER and ACL_GROUP
ACEs into following, we will say that an NFSv4 names. This ACL is an implementation-dependent process.
It might be done, for example, by consulting a directory service or a
password file. Also, in the special ACL_USER_OBJ, ACL_GROUP_OBJ, and
ACL_OTHER ACEs must be translated to NFSv4 ACEs with "canonical
order" if its entries are ordered in the order that the special
entities "OWNER@", "GROUP@", and "EVERYONE@", respectively.

Next, map each POSIX ACE (excepting any mask ACE) in
algorithm would consider them. That is, with all OWNER@ entries
first, followed by user entries, followed by GROUP@ entries, followed
by group entries, with all EVERYONE@ entries at the given end.

5. A Minor Eccentrity of POSIX
ACL ACLs

We will see below that it is possible to find an NFSv4 ALLOW ACE ACL with an entity determined
precisely the same effect as above, and any given POSIX ACL, with one extremely
minor exception: if a bitmask determined from the permission bits on the POSIX ACE
as follows:

1) If the read bit requester that is set a member of more than one
group listed in the POSIX ACE, then set ACE4_READ_DATA.

2) If the write bit is set in ACL requests multiple bits simultaneously, the
POSIX ACE, then set ACE4_WRITE_DATA
and ACE4_APPEND_DATA. If algorithm requires all of the object carrying bits to be granted simultaneously
by one of the ACL is group ACEs. Thus a direc-
tory, set ACE4_DELETE_CHILD POSIX ACL such as well.

3) If the execute bit

ACL_USER_OBJ: ---
ACL_GROUP_OBJ: ---
g1: r--
g2: -w-
ACL_MASK: rw-
ACL_OTHER: ---

will prevent a user that is set in the POSIX ACE, then set ACE4_EXECUTE.

4) Set ACE4_READ_ACL, ACE4_READ_ATTRIBUTES, a member of groups g1 and ACE4_SYNCHRONIZE
unconditionally.

5) If the ACE is g2 from opening
a file for the special "OWNER@" entity, set ACE4_WRITE_ACL both read and ACE4_WRITE_ATTRIBUTES.

Mapping write, even though read and write would be
individually permitted.

The NFSv4 ACLs February 2005

6) Clear all other bits in ACL permission-checking algorithm has the NFSv4 bitmask.

In addition, we set the GROUP flag in each ACE which corresponds to property that it
permits a
named group (but not in of bits whenever it would permit each bit
individually, so it is impossible to mimic this behaviour with an
NFSv4 ACL.

6. Mapping POSIX ACLs to NFSv4 ACLs

6.1. Requirements

In the GROUP@ ACE, or any next section we give an example of a mapping of POSIX ACLs
into NFSv4 ACLs. We permit a server or client to use a different
mapping, provided the other special
entity ACEs). At this point, we've replaced mapping meets the following requirements:

It must map the POSIX ACL by to an NFSv4 ACL with identical access
semantics, ignoring the same number minor exception described in the previous
section.

It must map the read mode bit to ACE4_READ_DATA, the write bit to
ACE4_WRITE_DATA and ACE4_APPEND_DATA (and ACE4_DELETE_CHILD for
directories), and the EXECUTE bit to ACE4_EXECUTE. It should also
allow ACE4_READ_ACL, ACE4_READ_ATTRIBUTES, and ACE4_SYNCHRONIZE
unconditionally, and allow ACE4_WRITE_ACL and ACE4_WRITE_ATTRIBUTES
to the owner. The handling of other NFSv4 mode bits may depend on
the implementation, but it is preferable to leave them unused.

It should avoid using DENY ACEs. If DENY ACEs (ignoring any are required, it
should attempt to place them at the beginning. (This is not always
possible.)

For simplicity's sake, the translator may choose to handle the mask ACE). To
emulate
by first applying it to the POSIX USER, GROUP, and GROUP_OBJ ACEs, and then
mapping the resulting ACL. However, that will result in an ACL permission-checking algorithm, we need from
which it is impossible to mod-
ify determine the ACL further, as follows:

1) Order original value of the mask or
of the masked USER, GROUP, and GROUP_OBJ bitmasks. If the resulting
ACL so is later translated back to a POSIX ACL, the translator will
assume that the OWNER@ ACE value of the mask is the first ACE union of the ACL,
followed by bitmasks
permitted to any user ACEs, followed by USER, GROUP, or GROUP_OBJ. If that would be
incorrect, the GROUP@ ACE, followed by
any group ACEs, and ending finally with original translation should not modify the EVERYONE@ ACE.

2) The POSIX algorithm stops as soon bitmasks of
the USER, GROUP, and GROUP_OBJ bitmasks, and should instead use
additional DENY ACEs as necessary to give the requester matches an
ACL_USER_OBJ, ACL_OTHER, or ACL_USER ACE. To emulate this
behaviour, add effect of the mask. It
should also arrange for the first GROUP@ ACE to be a single DENY ACE after each ALLOW whose
bitmask is determined by the mask, allowing that ACE for OWNER@,
EVERYONE@, or to be used to
determine the original mask value.

6.2. Example POSIX->NFSv4 Mapping

We now describe an algorithm which maps any named user. The DENY ACE should have POSIX ACL to an NFSv4 ACL
with the same
entity semantics, meeting the above requirements.

First, translate the uid's and flags gid's on the ACL_USER and ACL_GROUP
ACEs into NFSv4 names, using directory services, etc., as
appropriate, and translate ACL_USER_OBJ, ACL_GROUP_OBJ, and ACL_OTHER
to the corresponding special NFSv4 names "OWNER@", "GROUP@", and "EVERYONE@",
respectively.

Next, map each POSIX ACE (excepting any mask ACE) in the given POSIX
ACL to an NFSv4 ALLOW ACE. The ACE with an entity determined as above, and
with a bitmask determined from the permission bits on the DENY POSIX ACE should be the bitwise NOT of
as follows:

1. If the bitmask on read bit is set in the ALLOW POSIX ACE, except that the ACE4_WRITE_OWNER and ACE4_DELETE bits should
be cleared, and then set ACE4_READ_DATA.

2. If the ACE4_DELETE_CHILD write bit should be cleared on
non-directories. (Also, is set in the xdr-encoded POSIX ACE, then set
ACE4_WRITE_DATA and ACE4_APPEND_DATA. If the object carrying the
ACL that is transmit-
ted, all bits not defined in the protocol should be cleared.)

3) Unlike a directory, set ACE4_DELETE_CHILD as well.

3. If the other ACEs execute bit is set 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, ACE, then it must deny any permissions they do not allow. To
emulate this behaviour, instead of adding a single DENY after set
ACE4_EXECUTE.

4. Set ACE4_READ_ACL, ACE4_READ_ATTRIBUTES, and ACE4_SYNCHRONIZE
unconditionally.

5. If the ACE is for the special "OWNER@" entity, set ACE4_WRITE_ACL
and ACE4_WRITE_ATTRIBUTES.

6. Clear all other bits in the NFSv4 bitmask.

In addition, we set the GROUP flag in each
corresponding GROUP@ or ACE which corresponds to a
named group (but not in the GROUP@ ACE, we insert a list or any of DENY
ACEs at the end of other special
entity ACEs).

At this point, we've replaced the list POSIX ACL by an NFSv4 ACL with the
same number of GROUP@ and named group ACEs. Each
DENY ACE is determined from its corresponding ACEs (ignoring any mask ACE), all of them ALLOW ACE exactly as
in step 2, and should occur ACEs.

Order this NFSv4 ACL in the inserted list in canonical order: OWNER@, users, GROUP@,
groups, then EVERYONE@.

If the same posi-
tion as bitmasks in the corresponding ALLOW resulting ACEs are non-increasing (so no ACE occurs in
allows a bit not allowed by a previous ACE), then we can skip the list of ALLOW
ACEs.

4) Finally,
next step.

Otherwise, we enforce need to insert additional DENY ACE's to emulate the
first-match semantics of the POSIX mask ACL permission-checking algorithm:

1. If an ACL_USER_OBJ, ACL_OTHER, or ACL_USER ACE by prepending each ALLOW fails to grant
some permissions that are granted later in the ACL, then that ACE for a named user, GROUP@, or named group, with
must be prepended by a single DENY ACE. The DENY ACE whose should have
the same entity and flags are the same as those for the corre-
sponding corresponding ALLOW ACE, but whose the
bitmask is on the inverse of DENY ACE should be the bit-
mask determined from bitwise NOT of the mask bitmask
on the ALLOW ACE, with except that the inverse calculated as
described in step 2.

As an example, take a POSIX ACL with two named users (u1 and u2) and
two named groups (g1 ACE4_WRITE_OWNER, ACE4_DELETE,
ACE4_READ_NAMED_ATTRIBUTES, ACE4_WRITE_NAMED_ATTRIBUTES bits
should be cleared, and g2), the ACE4_DELETE_CHILD bit should be
cleared on non-directories. (Also, in addition to the required
ACL_USER_OBJ, ACL_GROUP_OBJ, ACL_OTHER, and ACL_MASK ACEs.

Such an ACL will map to an NFSv4 xdr-encoded ACL that
is transmitted, all bits not defined in the protocol should be
cleared.)

2. All of the form

Mapping NFSv4 ACLs February 2005

ALLOW OWNER@
DENY OWNER@
DENY u1 (mask)
ALLOW u1
DENY u1
DENY u2 (mask)
ALLOW u2
DENY u2 ACL_GROUP_OBJ and ACL_GROUP ACEs are consulted by the
POSIX algorithm before determining permissions. To emulate this
behaviour, instead of adding a single DENY before corresponding
GROUP@ (mask)
ALLOW GROUP@
DENY g1 (mask)
ALLOW g1
DENY g2 (mask)
ALLOW g2 or named group ACEs, we insert a list of DENY ACEs after
the list of GROUP@ and named group ACEs. Each DENY g1
DENY g2 ACE is
determined from its corresponding ALLOW EVERYONE@ ACE exactly as in the
previous step. As before, these DENY aces should only be added
when they are necessitated by an ACE that is less permissive than
the final EVERYONE@

where ace.

Finally, we enforce the ACEs marked POSIX mask ACE by prepending each ALLOW ACE
for a named user, GROUP@, or named group, with (mask) a single DENY ACE
whose entity and flags are the same as those for the corresponding
ALLOW ACE, but whose bitmask are deter-
mined is the inverse of the bitmask determined
from the ACL_MASK ACE mask ACE, with the inverse calculated as described in step 4 above.
In general, a POSIX ACL with m named users and n the case of named groups will
map to an NFSv4 ACL users, these DENY aces may be coalesced with (3*(m + n) + 7) ACLs, unless m and n any
existing prepended DENY aces. The DENY aces are
both zero, in which case the result will omitted entirely if
they would have either 6 no affect, or 7 ACLs,
depending if the mask ACE has the same bitmask as
the maximum of the affected ACEs. (With the one exception that if
the POSIX ACL posesses exactly 4 ACEs, then a mask-derived DENY ace
should be inserted before the GROUP@ ace, even if it would not
otherwise be.)

Regardless of what scheme is used to represent the mask, the receiver
will use the first GROUP@ DENY ace to determine the value of the mask
(if it is different from the union of the bitmasks on whether the original affected
ACEs), and use the relevant ALLOWs to determine the pre-mask values
of user and group ACEs.

The implementation may also choose to just mask out the bitmasks on
the relevant ALLOW ACEs. This will produce a simpler ACL had (in
particular, an ACL_MASK ACE. ACL that usually requires no DENY ACE's), at the
expense of losing some ACL information after a chmod.

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

7. Mapping NFSv4 ACLs to POSIX ACLs

7.1. Requirements

Any mapping of NFSv4 ACLs to POSIX ACLs must map any NFSv4 ACL that
is semantically equivalent to a member of more than one group listed in the POSIX ACL
requests multiple bits simultaneously, (with the POSIX algorithm requires
all exception of the bits
"minor inaccuracy" mentioned above) to be granted simultaneously by one of the group
ACEs. Thus a equivalent POSIX ACL such ACL. It
should also extract the mask correctly; 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 the mask doesn't affect
the semantics of groups g1 the NFSv4 ACL, and g2 from opening as there is more than one way the
mask might be encoded, we require a file convention for both read and write, even though read and write would this.
Specifically: we require that the mask be
individually permitted.

The NFSv4 ACL permission-checking algorithm has computed as the property that it
permits a group bitmask
used on the first GROUP@ DENY ACE which precedes any GROUP@ allow
ACE, unless no such DENY ACE exists, in which case the mask must be
computed as the union of bits whenever it the bitmasks allowed to all named users,
groups, and GROUP@ (where by the "bitmask allowed to" an entity we
mean the maximum bitmask that the ACL would permit each bit individu-
ally, so it is impossible to mimic this behaviour any user
matching the entity).

Implementations may vary in how they deal with an NFSv4 ACLs that are
not precisely semantically equivalent to any POSIX ACL.

5. Using the Mapping In
particular they may return errors for such ACLs instead of attempting
to map them. However, when possible without compromising security,
they should attempt to be forgiving.

The language of [1] 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."

Note that an NFSv4 Implementations

Examination ACL consisting entirely of ALLOW ACLs can always
be transformed into a POSIX-equivalent ACL by first sorting it into
the canonical order, and then inserting DENY ACEs as necessary to
ensure POSIX first-match semantics. Since inserting DENY ACEs can
only restrict access, it is safe for a server to do this.

We require any server to accept, at least, any NFSv4 ACL that
consists entirely of ALLOW ACLs.

Clients should also be at least as forgiving, to promote
interoperability when heterogeneous clients share files.

7.2. Example NFSv4->POSIX Mapping

We now give an example of an algorithm described in the previous section shows that no information is lost; meets the original above
requirements. We assume it is to be used by a server mapping client-
provided NFSv4 ACLs to POSIX ACL ACLs it can be recon-
structed store in its filesystem, so
the translation errs on the side of making the ACL less permissive.

Given an NFSv4 ACL, first calculate the mask by taking the bitmask
from the mapped first GROUP@ DENY ACE from the original NFSv4 ACL. Thus ACL, if it
exists. After doing so, remove that DENY ACE, and clear the bits in
its bitmask from any DENY ACE for a named user, group, or GROUP@
which precedes an ALLOW ACE for the same entity.

In the case where there is no such GROUP@ DENY ACE, continue through
the rest of the algorithm and then calculate the mask as the union of
the calculated permissions of all named users, group, and the
GROUP_OBJ ACE.

Given an NFSv4 ACL, sort it into canonical order (OWNER@ ACEs first,
then user ACEs, then GROUP@ ACEs, then group ACEs, then EVERYONE@
ACEs.) Also, sort the GROUP@ and group ACEs that all ALLOW ACEs
precede all DENY ACEs. To do so, take advantage of the following
observations:

1. If two consecutive ACEs are either both ALLOW ACEs, or both DENY
ACEs, then we also have can swap their order without changing the effect of
the ACL.

2. If it would be impossible for a way to map
NFSv4 ACLs single user to POSIX ACLs in the case where match both of the NFSv4 ACL is precisely
in
entities on two consecutive ACEs, then we can swap their order
without changing the format effect of the ACL.

3. If an ACL produced ALLOW ACE is immediately followed by the algorithm above.

The algorithm can therefore be used to implement a subset DENY ACE, then
swapping the order of the
NFSv4 two ACEs will not make the ACL model. This may be useful to NFSv4 clients and servers
with preexisting system interfaces that support POSIX ACLs and that
cannot be modified to support NFSv4 ACLs.

A server, for example, that wishes to export via NFSv4 any more
permissive.

4. If a filesystem
that supports only POSIX ACLs, may use this mapping to answer client
requests for existing ACLs DENY ACE is immediately followed 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, ALLOW ACE, then
swapping the server faces a problem. If order of the given ACL
is two ACEs will not in precisely make the format of an ACL produced any more
permissive, *if* we modify the bitmask on the ALLOW ACE by this mapping,
then
clearing any bits that are set in the server DENY ACE.

The second observation is the trickiest: it may usually be required to return an error safe to avoid inaccu-
rately representing
assume that two distinct user names cannot match the client's intention. The correct error to
return in this case is NFS4ERR_ATTRNOTSUPP.

In same user. An
implementation with knowledge about group memberships or about the case where
current value of the file owner might also use that information, but
if it does so it will produce a client sets an ACL translation that leaves certain bits nei-
ther allowed nor denied, the server may choose to allow is no longer
accurate after owners or deny those
bits as necessary group memberships change.

Fortunately, observations 1, 3, and 4 are sufficient to make mapping possible. In sort any ACL
into canonical order, so a paranoid implementation can simply ignore
number 2 completely, while an implementation willing to sacrifice
some situations it accuracy may also be possible for a server choose to map do something more complex.

Ensure that the resulting ACL if it adds a DENY
ACE or denies a few additional bits. The language posesses at least one each of [rfc3530]
allows OWNER@,
GROUP@, and EVERYONE@ ACEs, by inserting an ALLOW ACE with a server some flexibility zero
bitmask if necessary in handling ACLs the correct position.

Next, for each entity, calculate a bitmask for that it cannot
enforce completely accurately, as long entity as it adheres to "the guiding
principle...
follows: Starting with the first ACE for that entity (ignoring all
previous ACEs), perform the server must not accept ACLs NFSv4 ACL-checking algorithm for a user
that appear is assumed to make
[a file] more secure than it really is."

Given match the choice, as long as entity on every DENY ACE that a user
matching the "guiding principle" given entity might match, but is not violated,
servers should opt assumed to be forgiving. The complexity of match only
those entities on ALLOW ACEs that *any* user matching the
POSIX<->NFSv4 mapping makes difficult current
entity must match.

Finally, construct the task of generating ACLs

Mapping POSIX ACL by translating NFSv4 ACLs February 2005

that will satisfy entity names to
uid's and gid's (and handling special entities in the obvious way),
then assign a server using POSIX bitmask determined by the mapping. By making NFSv4 bitmask
calculated in the previous step; the bitmask calculation should use
the inverse of the mapping
more forgiving, described previously in the server can simplify that task, improving interop-
erability.

Servers that implement POSIX-to-NFSv4
mapping, erring on the full NFSv4 protocol should also handle
carefully ACLs that leave side of denying bits neither allowed nor denied. It is
better to fall back on some if it cannot determine a
sensible mapping. However, if certain bits simply cannot be mapped
in a reasonable default rather than way to always
allow or always deny. A client that, for mode bits, the server may simply ignore them
rather than returning an error. (For example, sets the server should deny
write if either ACE4_WRITE_DATA but leaves unspecified or ACE4_APPEND_DATA probably does
so because its system interfaces are incapable of independently rep-
resenting ACE4_APPEND_DATA, not because denied. But
it intends to deny
ACE4_APPEND_DATA. By leaving the bit unspecified, the client leaves
the server the opportunity may choose to provide ignore ACE4_READ_ATTRIBUTES entirely.)

The resulting mapping errs on the reasonable default side of set-
ting creating a more restrictive
ACE. However it can be modified to match ACE4_WRITE_DATA.

Similar issues exist when produce a client uses mapping that errs on
the side of permissiveness, for the purposes of translating a server-
provided NFSv4 ACLs ACL to implement user
interfaces that only deal in a POSIX ACLs. ACL to present to a user or
application, as follows:

1. When sorting ACEs, ALLOW ACEs can always be moved towards the client translates
ACLs received from
start of the server to POSIX ACLs, some flexibility may
help interopability, ACL, but a DENY ACE can be moved towards the client must take care not to represent
any ACLs start
of the ACL only as stricter than they really are. Clients that provide
access to long as we clear any of the full DENY ACE's bitmask
bits that are set of in the intervening ALLOW ACEs.

2. When calculating the NFSv4 ACLs may also wish to provide users bitmask for each entity, err on the
side of assuming that ALLOW ACEs apply and that DENY ACEs don't,
with utilities to generate the one exception that when calculating the GROUP@ and interpret POSIX-mapped named
group bitmasks, ALLOW ACEs for groups other than the one under
consideration should be ignored.

3. When mapping the NFSv4 ACLs, bitmask to
aid users working with servers using the POSIX mapping.

Mapping NFSv4 ACLs February 2005

6. mode bits, err on the
side of allowing access.

8. Security Considerations

Any automatic mapping from one ACL model to another must provide
guarantees as to how the mapping affects the meaning of ACLs, or risk
misleading users about the permissions set on filesystem objects.
For this reason, caution reason, caution is recommended when implementing this
mapping. It is better to return errors than to break any such
guarantees.

That said, there may be cases where small losses in accuracy can
avoid dramatic interoperability and usability problems; as long as
the losses in accuracy are clearly documented, these tradeoffs may be
found acceptable.

For example, a server unable to support all of the NFSv4 mode bits
does not have a way to communicate its exact limitations to clients,
so clients (and users) may be unable to recover from such errors.
For this reason we recommend ignoring bitmask bits that the server is recommended when implementing
completely unable to map to mode bits, and advertising this fact
loudly in the server documentation. If this map-
ping. It is better considered
insufficient, we should add to return errors than the NFSv4 protocol additional
attributes necessary to break any such guaran-
tees. advertise the server's limitations.

Note also that this ACL mapping requires mapping between NFSv4 user-
names
usernames 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

[rfc3530]

9. References

[1] Shepler, S. et. al., "NFS S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
C., Eisler, M., and D. Noveck, "Network File System (NFS)
version 4 Protocol", RFC 3530, April 2003.

http://www.ietf.org/rfc/rfc3530.txt

[posixacl]
IEEE,

[2] Institute of Electrical and Electronics Engineers, Inc., "IEEE
Draft P1003.1e", October 1997 (last draft).

http://wt.xpilot.org/publications/posix.1e/download.html

Mapping NFSv4 ACLs February 2005

8. Author's Address

Address comments related to this memorandum to:

marius@umich.edu bfields@umich.edu 1997,
<http://wt.xpilot.org/publications/posix.1e/download.html>.

Authors' Addresses

Marius Aamodt Eriksen
U. of Michigan Center for Information Technology Integration

Email: marius@citi.umich.edu

J. Bruce Fields
University
U. of Michigan / CITI
535 West William
Ann Arbor, Michigan

E-mail: marius@umich.edu
E-mail: bfields@umich.edu

9. Copyright

Email: marius@citi.umich.edu

Intellectual Property Statement

The Internet Society (2004). This 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 is subject 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 rights, licenses and restrictions contained procedures with respect to rights in RFC documents can be
found in BCP 78, 78 and
except as set forth therein, BCP 79.

Copies of IPR disclosures made to the authors retain all their rights. 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 INFOR-
MATION
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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.