Network Working Group
Marius AamodtM. Eriksen Internet DraftInternet-Draft J. BruceFields Document: draft-ietf-nfsv4-acl-mapping-03.txt February 2005Expires: 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 certifyeach author represents that any applicable patent or other IPR claims of which I amhe or she is aware have been disclosed,or will be disclosed, and any of which I becomehe 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 ofSection 106 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- DraftsInternet-Drafts as reference mate- rialmaterial 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.txthttp://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. "CopyrightThis 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 ACLfilesystems 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 POSIXdraft . 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 . We describe how to NFSv4 ACLs . . . . . . . . . . . . . . 6 5. Usingtranslate 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 2005two 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 NFSv4give 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- atedassociated 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] 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 2005the 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- ceedssucceeds if and only if each bit in the mask is allowed. We refer the reader to [rfc3530] 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].. 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- ingmatching 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- itedinherited by newly created objects in the directory. 4. MappingOrdering of NFSv4 and POSIX ACLs to NFSv4POSIX ACLs We now describe an algorithmare unordered--the order in which maps anythe POSIX ACLaccess- 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 withcan be dramatically changed by modifying the same semantics. First, translateorder that the uid's and gid's onentries are listed in. In the ACL_USER and ACL_GROUP ACEs intofollowing, we will say that an NFSv4 names. ThisACL 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 eachPOSIX ACE (excepting any mask ACE) inalgorithm 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 givenend. 5. A Minor Eccentrity of POSIX ACLACLs We will see below that it is possible to find an NFSv4 ALLOW ACEACL with an entity determinedprecisely the same effect as above, andany 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 bitrequester that is seta member of more than one group listed in the POSIX ACE, then set ACE4_READ_DATA. 2) If the write bit is set inACL requests multiple bits simultaneously, the POSIX ACE, then set ACE4_WRITE_DATA and ACE4_APPEND_DATA. Ifalgorithm requires all of the object carryingbits to be granted simultaneously by one of the ACL isgroup ACEs. Thus a direc- tory, set ACE4_DELETE_CHILDPOSIX ACL such as well. 3) If the execute bitACL_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 isg2 from opening a file for the special "OWNER@" entity, set ACE4_WRITE_ACLboth read and ACE4_WRITE_ATTRIBUTES. Mappingwrite, even though read and write would be individually permitted. The NFSv4 ACLs February 2005 6) Clear all other bits inACL permission-checking algorithm has the NFSv4 bitmask. In addition, we set the GROUP flag in each ACE which corresponds toproperty that it permits a namedgroup (but not inof 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 anynext 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 replacedmapping meets the following requirements: It must map the POSIX ACL byto an NFSv4 ACL with identical access semantics, ignoring the same numberminor 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 anyare 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 emulateby first applying it to the POSIXUSER, GROUP, and GROUP_OBJ ACEs, and then mapping the resulting ACL. However, that will result in an ACL permission-checking algorithm, we needfrom which it is impossible to mod- ifydetermine the ACL further, as follows: 1) Orderoriginal value of the mask or of the masked USER, GROUP, and GROUP_OBJ bitmasks. If the resulting ACL sois later translated back to a POSIX ACL, the translator will assume that the OWNER@ ACEvalue of the mask is the first ACEunion of the ACL, followed bybitmasks permitted to any user ACEs, followed byUSER, GROUP, or GROUP_OBJ. If that would be incorrect, the GROUP@ ACE, followed by any group ACEs, and ending finally withoriginal translation should not modify the EVERYONE@ ACE. 2) The POSIX algorithm stops as soonbitmasks 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, addeffect of the mask. It should also arrange for the first GROUP@ ACE to be a singleDENY ACE after each ALLOWwhose bitmask is determined by the mask, allowing that ACE for OWNER@, EVERYONE@, orto 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 havePOSIX ACL to an NFSv4 ACL with the same entitysemantics, meeting the above requirements. First, translate the uid's and flagsgid'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 correspondingspecial 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. TheACE with an entity determined as above, and with a bitmask determined from the permission bits on the DENYPOSIX ACE should be the bitwise NOT ofas follows: 1. If the bitmask onread bit is set in the ALLOWPOSIX ACE, except that the ACE4_WRITE_OWNER and ACE4_DELETE bits should be cleared, andthen set ACE4_READ_DATA. 2. If the ACE4_DELETE_CHILDwrite bit should be cleared on non-directories. (Also,is set in the xdr-encodedPOSIX ACE, then set ACE4_WRITE_DATA and ACE4_APPEND_DATA. If the object carrying the ACL thatis transmit- ted, all bits not defined in the protocol should be cleared.) 3) Unlikea directory, set ACE4_DELETE_CHILD as well. 3. If the other ACEsexecute bit is set in step 2, all of the ACL_GROUP_OBJ and ACL_GROUP ACEs are consulted bythe 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 afterset 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@ orACE which corresponds to a named group (but not in the GROUP@ ACE, we insert a listor any of DENY ACEs atthe end ofother special entity ACEs). At this point, we've replaced the listPOSIX ACL by an NFSv4 ACL with the same number of GROUP@ and named group ACEs. Each DENY ACE is determined from its correspondingACEs (ignoring any mask ACE), all of them ALLOW ACE exactly as in step 2, and should occurACEs. Order this NFSv4 ACL in the inserted list incanonical order: OWNER@, users, GROUP@, groups, then EVERYONE@. If the same posi- tion asbitmasks in the corresponding ALLOWresulting ACEs are non-increasing (so no ACE occurs inallows a bit not allowed by a previous ACE), then we can skip the list of ALLOW ACEs. 4) Finally,next step. Otherwise, we enforceneed to insert additional DENY ACE's to emulate the first-match semantics of the POSIX maskACL permission-checking algorithm: 1. If an ACL_USER_OBJ, ACL_OTHER, or ACL_USER ACE by prepending each ALLOWfails to grant some permissions that are granted later in the ACL, then that ACE for a named user, GROUP@, or named group, withmust be prepended by a single DENY ACE. The DENY ACE whoseshould have the same entity and flags are the sameas those forthe corre- spondingcorresponding ALLOW ACE, but whosethe bitmask ison the inverse ofDENY ACE should be the bit- mask determined frombitwise NOT of the maskbitmask on the ALLOW ACE, withexcept 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 (g1ACE4_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 tothe required ACL_USER_OBJ, ACL_GROUP_OBJ, ACL_OTHER, and ACL_MASK ACEs. Such an ACL will map to an NFSv4xdr-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 u2ACL_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 g2or named group ACEs, we insert a list of DENY ACEs after the list of GROUP@ and named group ACEs. Each DENY g1 DENY g2ACE 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@ whereace. Finally, we enforce the ACEs markedPOSIX 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- minedis the inverse of the bitmask determined from the ACL_MASK ACEmask ACE, with the inverse calculated as described in step 4above. In general, a POSIX ACL with m named users and nthe case of named groups will map to an NFSv4 ACLusers, these DENY aces may be coalesced with (3*(m + n) + 7) ACLs, unless m and nany existing prepended DENY aces. The DENY aces are both zero, in which case the result willomitted entirely if they would have either 6no affect, or 7 ACLs, dependingif 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 whetherthe originalaffected 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 requester7. 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 thePOSIX ACL requests multiple bits simultaneously,(with the POSIX algorithm requires allexception of the bits"minor inaccuracy" mentioned above) to be granted simultaneously by one ofthe group ACEs. Thus aequivalent POSIX ACL suchACL. 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 memberthe mask doesn't affect the semantics of groups g1the NFSv4 ACL, and g2 from openingas there is more than one way the mask might be encoded, we require a fileconvention for both read and write, even though read and write wouldthis. Specifically: we require that the mask be individually permitted. The NFSv4 ACL permission-checking algorithm hascomputed as the property that it permits a groupbitmask 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 itthe 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 impossibleto mimic this behaviourany user matching the entity). Implementations may vary in how they deal with anNFSv4 ACLs that are not precisely semantically equivalent to any POSIX ACL. 5. Using the MappingIn 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  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 ExaminationACL 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 showsthat no information is lost;meets the originalabove requirements. We assume it is to be used by a server mapping client- provided NFSv4 ACLs to POSIX ACLACLs it can be recon- structedstore 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 mappedfirst GROUP@ DENY ACE from the original NFSv4 ACL. ThusACL, 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 havecan swap their order without changing the effect of the ACL. 2. If it would be impossible for a way to map NFSv4 ACLssingle user to POSIX ACLs in the case wherematch both of the NFSv4 ACL is precisely inentities on two consecutive ACEs, then we can swap their order without changing the formateffect of the ACL. 3. If an ACL producedALLOW ACE is immediately followed by the algorithm above. The algorithm can therefore be used to implementa subsetDENY ACE, then swapping the order of the NFSv4two 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 NFSv4any more permissive. 4. If a filesystem that supports only POSIX ACLs, may use this mapping to answer client requests for existing ACLsDENY 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 setan ACL,ALLOW ACE, then swapping the server faces a problem. Iforder of the given ACL istwo ACEs will not in preciselymake the format of anACL producedany more permissive, *if* we modify the bitmask on the ALLOW ACE by this mapping, thenclearing any bits that are set in the serverDENY ACE. The second observation is the trickiest: it may usually be required to return an errorsafe to avoid inaccu- rately representingassume that two distinct user names cannot match the client's intention. The correct error to return in this case is NFS4ERR_ATTRNOTSUPP. Insame user. An implementation with knowledge about group memberships or about the case wherecurrent value of the file owner might also use that information, but if it does so it will produce a client sets an ACLtranslation that leaves certain bits nei- ther allowed nor denied, the server may choose to allowis no longer accurate after owners or deny those bits as necessarygroup memberships change. Fortunately, observations 1, 3, and 4 are sufficient to make mapping possible. Insort any ACL into canonical order, so a paranoid implementation can simply ignore number 2 completely, while an implementation willing to sacrifice some situations itaccuracy may also be possible for a serverchoose to mapdo something more complex. Ensure that the resulting ACL if it adds a DENY ACE or denies a few additional bits. The languageposesses at least one each of [rfc3530] allowsOWNER@, GROUP@, and EVERYONE@ ACEs, by inserting an ALLOW ACE with a server some flexibilityzero bitmask if necessary in handling ACLsthe correct position. Next, for each entity, calculate a bitmask for that it cannot enforce completely accurately, as longentity 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 ACLsNFSv4 ACL-checking algorithm for a user that appearis assumed to make [a file] more secure than it really is." Givenmatch the choice, as long asentity on every DENY ACE that a user matching the "guiding principle"given entity might match, but is not violated, servers should optassumed to be forgiving. The complexity ofmatch only those entities on ALLOW ACEs that *any* user matching the POSIX<->NFSv4 mapping makes difficultcurrent entity must match. Finally, construct the task of generating ACLs MappingPOSIX ACL by translating NFSv4 ACLs February 2005 that will satisfyentity names to uid's and gid's (and handling special entities in the obvious way), then assign a server usingPOSIX bitmask determined by the mapping. By makingNFSv4 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 implementPOSIX-to-NFSv4 mapping, erring on the full NFSv4 protocol should also handle carefully ACLs that leaveside of denying bits neither allowed nor denied. It is better to fall back on someif it cannot determine a sensible mapping. However, if certain bits simply cannot be mapped in a reasonable default rather thanway to always allow or always deny. A client that, formode bits, the server may simply ignore them rather than returning an error. (For example, setsthe server should deny write if either ACE4_WRITE_DATA but leaves unspecifiedor ACE4_APPEND_DATA probably does so because its system interfacesare incapable of independently rep- resenting ACE4_APPEND_DATA, not becausedenied. But it intends to deny ACE4_APPEND_DATA. By leaving the bit unspecified, the client leaves the server the opportunitymay choose to provideignore ACE4_READ_ATTRIBUTES entirely.) The resulting mapping errs on the reasonable defaultside of set- tingcreating a more restrictive ACE. However it can be modified to match ACE4_WRITE_DATA. Similar issues exist whenproduce a client usesmapping that errs on the side of permissiveness, for the purposes of translating a server- provided NFSv4 ACLsACL to implement user interfaces that only deal ina 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 fromstart 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 ACLsstart of the ACL only as stricter than they really are. Clients that provide access tolong as we clear any of the fullDENY ACE's bitmask bits that are set ofin the intervening ALLOW ACEs. 2. When calculating the NFSv4 ACLs may also wish to provide usersbitmask for each entity, err on the side of assuming that ALLOW ACEs apply and that DENY ACEs don't, with utilities to generatethe one exception that when calculating the GROUP@ and interpret POSIX-mappednamed 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 thePOSIX 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, cautionreason, 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 implementingcompletely unable to map to mode bits, and advertising this fact loudly in the server documentation. If this map- ping. Itis betterconsidered insufficient, we should add to return errors thanthe 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- namesusernames 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  Shepler, S. et. al., "NFSS., 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, 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: firstname.lastname@example.org email@example.com, <http://wt.xpilot.org/publications/posix.1e/download.html>. Authors' Addresses Marius Aamodt Eriksen U. of Michigan Center for Information Technology Integration Email: firstname.lastname@example.org J. Bruce Fields UniversityU. of Michigan / CITI 535 West William Ann Arbor, Michigan E-mail: email@example.com E-mail: firstname.lastname@example.org 9. Copyright Copyright (C)Center for Information Technology Integration Email: email@example.com Intellectual Property Statement The Internet Society (2004). ThisIETF 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 subjector 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 containedprocedures 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 firstname.lastname@example.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- MATIONINFORMATION 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.