Network Working Group                              Marius Aamodt Eriksen
Internet Draft                                           J. Bruce Fields
Document: draft-ietf-nfsv4-acl-mapping-01.txt draft-ietf-nfsv4-acl-mapping-02.txt               October 2004

               Mapping Between NFSv4 and Posix Draft ACLs

SSttaattuuss ooff tthhiiss MMeemmoo

Status of this Memo

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

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference mate-
   rial or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   "Copyright (C) The Internet Society (2002-2004).  All Rights
   Reserved."

AAbbssttrraacctt

   The

Abstract

   NFS (Network File System) version 4[rfc3010bis] 4 [rfc3530] (NFSv4) specifies a flavor of Access Control
   Lists (ACLs) that resembles that of Win-
   dows NT's.  ACLs are used to specify fine grained control of access
   to file system objects.  An ACL consists of a resembling Windows NT ACLs.  A number of Access Con-
   trol Entries (ACEs), each specify some level of access for an entity;
   an entity can be a operating sys-
   tems use a user, group or different flavor of ACL based on a special entity.  The access
   level is described using an access mask, which is withdrawn POSIX draft.
   NFSv4 clients and servers on such operating systems may wish to map

Mapping NFSv4 ACLs                                          October 2004

   between NFSv4 ACLs and their native ACLs.  To this end, we describe a bitmask where
   each bit describes
   mapping from POSIX draft ACLs to a level subset of access, for example read, write and
   execute permissions on the file system object. NFSv4 ACLs.

Mapping NFSv4 ACLs                                         February                                          October 2004

TTaabbllee ooff CCoonntteennttss

   11..  IInnttrroodduuccttiioonn

Table of Contents

   1.  Introduction . . . . . . . . . . . . . 3
   22..  NNFFSSvv44 AACCLLss . . . . . . . . . . . 4
   2.  NFSv4 ACLs . . . . . . . . . . . 3
   33..  PPOOSSIIXX AACCLLss . . . . . . . . . . . . . . 4
   44..  MMaappppiinngg PPoossiixx AACCLLss
           ttoo NNFFSSvv44 AACCLLss
   3.  POSIX ACLs . . . . . . . . . . . . . . . . . . . . . . . . . 5
   55..  SSeeccuurriittyy
           CCoonnssiiddeerraattiioonnss
   4.  Mapping Posix ACLs to NFSv4 ACLs . . . . . . . . . . . . . 7
   66..  BBiibblliiooggrraapphhyy . 6
   5.  Using the Mapping in NFSv4 Implementations . . . . . . . . . 8
   77..  AAcckknnoowwlleeddggmmeennttss
   6.  Security Considerations  . . . . . . . . . . . . . 9
   88..  AAuutthhoorr''ss AAddddrreessss . . . .  10
   99..  CCooppyyrriigghhtt
   7.  Bibliography . . . . . . . . . . . . .  10 . . . . . . . . . .  11
   8.  Author's Address . . . . . . . . . . . . . . . . . . . . .  12
   9.  Copyright  . . . . . . . . . . . . . . . . . . . . . . . .  12

Mapping NFSv4 ACLs                                         February                                          October 2004

11..  IInnttrroodduuccttiioonn

   The NFS (Network File System) version 4 [rfc3010bis] (NFSv4) speci-
   fies a flavor of

1.  Introduction

   Access Control Lists (ACLs) that resembles that of
   Windows NT's.  ACLs are used to specify fine grained control of fine-grained access
   rights to file system objects.  An ACL consists of a number of Access
   Control Entries (ACEs), each specifying some level of access for an
   entity; an
   entity.  The entity can may be a a user, group a group, or a special entity. entity (such
   as "everyone").  The
   access level of access is described using an access
   mask, which is a bitmask
   where with each bit describes corresponding to a level type of access, for example read, write
   access (such as "read" or "append").

   In the following sections we describe two ACL models: NFSv4 ACLs, and execute permissions
   ACLs based on the file system object.

22..  NNFFSSvv44 AACCLLss a withdrawn POSIX draft, which we will refer to as
   "POSIX ACLs".  Since NFSv4 ACLs are rich much finer-grained than POSIX
   ACLs, it is not possible in nature and expand upon general to map an arbitrary NFSv4 ACL to
   a POSIX ACL with the traditional idea of
   ACLs.  An same semantics.  It does, however, turn out to
   be possible to map any POSIX ACL to a NFSv4 ACE can ACL that has nearly iden-
   tical semantics.  We will describe such a mapping, and discuss how it
   might be used in NFSv4 client and server implementations.

2.  NFSv4 ACLs

   An NFSv4 ACL is an ordered sequence of type ALLOW, DENY, LOG or ALARM; ACEs, each
   specifies having an entity, a different action to take should
   type, and an access mask.  The entity may be the ACE match name of a current
   request.  NFSv4 ACLs user or
   group, or may also have be one of a rich 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 com-
   plements are more fine-
   grained than the traditional types.  These include appending data "read", "write", and "execute" permis-
   sions used in UNIX mode bits.

   The type may be ALLOW or DENY.  (AUDIT or ALARM are also allowed, but
   they are not relevant to the
   file object, deleting children of the file object, deleting the file
   object, etc [rfc3010bis]. our discussion).

   The NFSv4 ACLs are interpreted in ACL permission-checking algorithm is straightforward.
   Given an ACL and a requestor asking for a straightforward manner. set of permissions speci-
   fied by an access mask:

   1) Walk through the list of ACEs from the ACL in order order.

   2) If the "who" (entity) field in the ACE does not match that of the
      requester, the particular Ignore any ACE is for with an entity not processed. matching requestor.

Mapping NFSv4 ACLs                                          October 2004

   3) Process all ACEs until all the bits in the requested access mask
      have been ALLOWed; once ALLOWed by an ALLOW ace with that bit set.   Once a particular par-
      ticular bit has been ALLOWed by an ACE, it is no longer considered
      in further processing.

   4) If a particular bit in the requested access mask is DENYed (while that bit is
      still under consideration), the request is denied.

   5) If all bits have been ALLOWed, the access is granted, or else granted.  Otherwise
      behavior is undefined.

   NFSv4 ACLs

   There are also specify a number of special entities such as OWNER,
   GROUP, and EVERYONE.  These refer to the traditional UNIX mode bits.
   Others include DIALUP, BATCH, and AUTHENTICATED, which have special-
   ized uses.

Mapping NFSv4 ACLs                                         February 2004

   Additionally the NFSv4 ACLs specify a number of flags that can be applied to an ACL.  These include a specification on how an ACL on NFSv4 ACE.
   Three flags that we will need to use in the following discussion
   apply to ACEs in a directory may ACL.  They are: ACE4_DIREC-
   TORY_INHERIT_ACE, which indicates that the ACE should be propagated added to newly created files or directories
   inside new
   subdirectories of said directory.

   It is clear the directory; ACE4_FILE_INHERIT_ACE, which does
   the same for new files; and ACE4_INHERIT_ONLY, which indicates that
   the granularity of ACE should be ignored when determining access control that NFSv4 ACLs
   specify is well beyond to the standard UNIX capability of expressing
   file system object permissions.

33..  PPOOSSIIXX AACCLLss

   POSIX ACLs directory
   itself.

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

3.  POSIX ACLs

   A number of operating systems, including Linux and FreeBSD, implement
   ACLs based on the withdrawn POSIX 1003.1e/1003.2c Draft Standard 17 [posix-
   acl], which was meant
   [posixacl].  We will refer to specify a such ACLs as "POSIX ACLs".

   POSIX standard for ACLs, but
   unfortunately never materialized.  However, many systems still ACLs use
   it, both in access masks with only the form of it's latest draft as well as earlier drafts. traditional "read",
   "write", and "execute" bits.  Each ACE in a POSIX ACLs are simpler than their NFSv4 equivalents. 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 an has
   an entity a uid associated with it, and the traditional UNIX mode bits that are assigned to the
   particular entity.
   each ACL_GROUP ACE has a gid associated with it.  Every POSIX ACL
   must have exactly one ACL_USER_OBJ, ACL_GROUP, and ACL_OTHER ACE, and
   at most one ACL_MASK ace.  The entity ACL_MASK ace is required if the ACL
   has any ACL_USER or ACL_GROUP aces.  There may not be an arbitrary UID or GID or one
   of a few special entities, two ACL_USER
   aces with the most notable of which is same uid, and there may not be two ACL_GROUP aces with
   the ACL_MASK
   entity.  POSIX ACLs are also interepreted differently than their
   NFSv4 equivalents. same gid.

   Given a POSIX ACLs are interpreted ACL and a requestor asking for access, permission is
   determined as follows:

   1) Process If the ACL_USER_OBJ (equivalent to UNIX file owner) ACE
      first; if requestor is the UID of the requester does not match that of the
      ACL_USER_OBJ, file owner, then allow or deny access
      depending on whether the ACL_USER_OBJ ACE is ignored. allows or denies it.

Mapping NFSv4 ACLs                                          October 2004

      Otherwise,

   2) if the
      requester's access mask is allowed by requestor's uid matches the access mask uid of the ACE,
      the request is granted, else the request is denied.

   2) Process all one of the ACL_USER ACEs; the entity of these ACEs specify
      a user
      ACE's, then allow or deny access depending on whether the system.  If
      ACL_USER_OBJ ACE allows or denies it.  Otherwise,

   3) Consider the UID set of all ACL_GROUP ACE's whose gid the requester does not match requestor is
      a member of.  Add to that of set the ACL_GROUP_OBJ ACE, then the ACE is ignored.  Otherwise, if the
      requester's access mask
      requestor is allowed by the access mask also a member of the ACE,
      the request is granted, else the request is denied.

   3) Process the ACL_GROUP_OBJ ACE and all that group.  Allow access if one of
      the ACL_GROUP ACEs; the
      entity of these ACEs specify a group on ACE's in the system. resulting set allows access.  If none of the GIDs set of the requester match the current ACE, the particular
      ACE is ignored.  For any
      matching ACE, if the the requester's
      access mask is allowed by the ACEs access mask, then access is
      permitted.  If there are matching ACEs, but nonempty, and none allow access, then access is denied.

Mapping NFSv4 ACLs                                         February 2004 deny
      access.  Otherwise, if none of these ACEs match,

   4) If if the requester's access mask is allowed by the ACL_OTHER ACE,
      then grant access.

   5) Deny  Otherwise, deny access.

   Steps (2) and (3) have an additional criteria; in addition to check-
   ing whether the requested access mask is allowed by the access mask
   in the ACE, the requested bits also have to be in the access mask of
   the special ACE with the ACL_MASK entity.  This allows file owners to
   specify a maximum level of access allowed by any other user or group
   that has any access to the file system object.

   In addition to a regular POSIX ACL, a directory in the file system
   may also have associated with it a default ACL.  This default ACL
   does not affect permissions to the directory itself.  Instead, it
   governs the ACL a file system object will be assigned initially when
   it is created as a child of the particular directory.

44..  MMaappppiinngg PPoossiixx AACCLLss ttoo NNFFSSvv44 AACCLLss

4.  Mapping Posix ACLs to NFSv4 ACLs

   Given the difference in both extensiveness and interpretation of differences between POSIX and NFSv4 ACLs, any conversion
   between the two is difficult.  However, POSIX ACLs are a subset of
   NFSv4 ACLs.  Any ACLs, and any POSIX ACL can be emulated with an NFSv4 ACL using
   the following mapping.

   The ACE entities are translated as follows.  The non-special entities
   in form of UIDs

   First, the uid's and GIDs is gid's on the ACL_USER and ACL_GROUP ACEs must be
   translated to equivalent strings (a sys-
   tem dependent into NFSv4 names--a system-dependent process, typically which, on
   UNIX for example, may be done by lookups to /etc/passwd in
   UNIX).  The POSIX ACL_USER_OBJ entity is /etc/passwd.  Also, the
   special ACL_USER_OBJ, ACL_GROUP_OBJ, and ACL_OTHER ACEs must be
   translated to the "OWNER" NFSv4 entity.  Similary, ACEs with the POSIX ACL_GROUP_OBJ is translated to the
   "GROUP" NFSv4 entity.  The ACL_OTHER entity is translated to the
   "EVERYONE" NFSv4 entity. special entities "OWNER", "GROUP",
   and "EVERYONE", respectively.

   The ACE access mask is translated as follows.  The read bit of the
   POSIX access mask is translated to the logical OR of the

Mapping NFSv4 ACLs                                          October 2004

   ACE4_READ_DATA and ACE4_READ_NAMED_ATTRS NFSv4 access mask fields.
   The write bit of the POSIX access mask is translated to the logical
   OR of the ACE4_WRITE_DATA, ACE4_WRITE_NAMED_ATTRIBUTES ACE4_WRITE_NAMED_ATTRS and
   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.

Mapping NFSv4 ACLs                                         February 2004

   In addition to the above, the OWNER entity must always be given
   ACE4_WRITE_ACL and ACE4_WRITE_ATTRIBUTES, and all entities must be
   given ACE4_READ_ACL ACE4_READ_ACL, ACE4_READ_ATTRIBUTES, and ACE4_READ_ATTRIBUTES. 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
   object is a directory, and the POSIX ACE belongs to a default ACL,
   the "ACE4_INHERIT_ONLY_ACE" flag is 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_IDENTI-
   FIER_GROUP" "ACE4_IDENTIFIER_GROUP" flag is
   set in the NFSv4 ACE.

   The POSIX ACL_USER_OBJ ACE is also always given the permission bits
   "ACE4_READ_ACL" and "ACE4_WRITE_ACL."

   Completing the mapping reduces to being able to emulate an ACL_MASK
   and compensate for the difference some differences in interpretation between the permission-checking algo-
   rithms of the two ACL implementations.

   The difference in interpretation of the two ACL types call for a
   translation scheme.  The scheme follows: permission-checking algorithms is handled as fol-
   lows:

   Every user ACE in the POSIX ACL maps into 2 NFSv4 ACEs; one ALLOW ACE
   which is translated as specified by the above scheme, then a comple-
   menting DENY ACE which is also translated as specified by the above
   scheme, with the exception that the access mask is inverted.  Note
   that the ACL_USER_OBJ ACE is placed first in this list.

   Every group ACE in the POSIX ACL produces a similar pair, but instead
   of being in sequence, all of the ALLOW ACEs are all in sequence, fol-
   lowed by all the DENY ACEs.  The ACL_GROUP_OBJ ACE is placed first in
   both lists.

   Lastly, the POSIX ACL_OTHER ACE is translated into a pair of ACEs as
   in the user ACE case.

   This translation strategy allows us

Mapping NFSv4 ACLs                                          October 2004

   With this done, the NFSv4 permission-checking algorithm applied to emulate POSIX ACL interpreta-
   tion in an
   the resulting NFSv4 ACL will produce the same result as the POSIX
   permission-checking algorithm did on the original POSIX ACL.

   To handle the special POSIX entity ACL_MASK, we slightly modify the
   above translation:

   With the exception of the "OWNER" and "EVERYONE" ACEs, another ACE is
   prepended to the ACE. 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
   ACE should the ACL_MASK be changed.

5.  Using the Mapping in NFSv4 Implementations

   Note that the algorithm described in the previous section not only
   provides a way to map any POSIX ACL to be mapped to an NFSv4 ACL with
   similar semantics, but also provides the reverse mapping in the case
   where the NFSv4 ACL is precisely in the format of an ACL produced by
   the algorithm above.

   The algorithm can therefore be used to implement a subset of the
   NFSv4 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 a filesystem
   that supports only POSIX ACLs, may use this mapping to answer client
   requests for existing ACLs by translating POSIX ACLs on its filesys-
   tem to NFSv4 ACLs to send to the client.  However, when a client
   attempts to set an ACL, the server faces a problem.  If the given ACL
   happens to be in precisely the format of an ACL produced by this map-
   ping (as would happen if, for example, the client was performing the
   same translation), then the server can map it to a POSIX ACL to store
   on the filesystem.  But for any other NFSv4 ACL, the server should
   return an error to avoid any chance of inaccurately representing the
   client's intention.

   The language of [rfc3530] allows a server some flexibility in han-
   dling ACLs that it cannot enforce completely accurately, as long as
   it adheres to "the guiding principle... that the server must not
   accept ACLs that appear to make [a file] more secure than it really
   is."

Mapping NFSv4 ACLs                                          October 2004

   It may therefore be possible for a server to accept a wider range of
   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 prepended ACE is results of such a DENY ACE with the same
   entity as the following ALLOW ACE, but 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 permission mask set client that uses NFSv4 ACLS to
   the complement of the implement user interfaces
   that only deal in POSIX ACL_MASK.

   This method allows us ACLs may handle user requests to preserve the real permission bits of each
   ACE set ACLs
   easily enough, but should return errors when the ACL_MASK user requests ACLs
   that, on consulting the server, turn out to not be changed. mappable to POSIX
   ACLs.

Mapping NFSv4 ACLs                                         February                                          October 2004

55..  SSeeccuurriittyy CCoonnssiiddeerraattiioonnss

   Since this draft deals with the

6.  Security Considerations

   Any automatic mapping of Access Control Lists, it
   is deeply involved with security.  The body of this document needs from one ACL model to
   address another must provide
   guarantees that the issue of mapping ACLs in a way as to not disobey the
   intent of preserves semantics, or mislead risk misleading
   users about the user. permissions set on filesystem objects.  For this rea-
   son, we recommend performing such mapping only when it can be done
   accurately, and returning errors in all other cases.

Mapping NFSv4 ACLs                                         February                                          October 2004

66..  BBiibblliiooggrraapphhyy

   [rfc3010bis]

7.  Bibliography

   [rfc3530]
   Shepler, S. et. al., "NFS version 4 Protocol", draft-ietf-
   nfsv4-rfc3010bis-05.txt, April 2003.

   http://www.ietf.org/internet-drafts/draft-ietf-
   nfsv4-rfc3010bis-05.txt

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

   [posixacl]
   IEEE, "IEEE Draft P1003.1e", October 1997 (last draft).

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

Mapping NFSv4 ACLs                                         February 2004

77..  AAcckknnoowwlleeddggmmeennttss

   The author would like to thank and acknowledge Bruce Fields for his
   careful scrutiny and excellent comments and suggestions.

Mapping NFSv4 ACLs                                         February                                          October 2004

88..  AAuutthhoorr''ss AAddddrreessss

8.  Author's Address

   Address comments related to this memorandum to:

      marius@umich.edu bfields@umich.edu

   Marius Aamodt Eriksen
   J. Bruce Fields
   University of Michigan / CITI
   535 West William
   Ann Arbor, Michigan

   E-mail: marius@umich.edu

99..  CCooppyyrriigghhtt
   E-mail: bfields@umich.edu

9.  Copyright

   Copyright (C) The Internet Society (2002-2004).  All Rights Reserved. (2004). This document and translations of it may be copied and furnished is subject
   to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies rights, licenses and derivative works.  However, this doc-
   ument itself may not be modified restrictions contained in any way, such as by removing the
   copyright notice or references to the Internet Society or other
   Internet organizations, BCP 78, and
   except as needed for the purpose of develop-
   ing Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or as
   required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by set forth therein, the Internet Society or its successors or assigns. authors retain all their rights.

   This document and the information contained herein is 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 DISCLAIMS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION INFOR-
   MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
   OF MER-
   CHANTABILITY MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.