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.

Copyright Notice

   Copyright (C) The Internet Society (2002-2004).  All Rights
   Reserved." (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)

   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)

   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)

   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)

   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

   Copyright (C) Center for Information Technology Integration

   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 Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.