TOC 
Network Working GroupA. Gruenbacher
Internet-DraftSUSE Labs, Novell
Expires: March 15, 2007September 11, 2006

NFSv4 ACLs in POSIX

draft-gruenbacher-nfsv4-acls-in-posix-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 as reference 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.

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

This Internet-Draft will expire on March 15, 2007.

Copyright Notice

Copyright © The Internet Society (2006).

Abstract

The NFSv4 specification [1] (Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, “Network File System (NFS) version 4 Protocol,” April 2003.) defines an access control list model that is close to how access control lists work on Windows. IEEE Std 1003.1 [2] (Institute of Electrical and Electronics Engineers, “Information Technology - Portable Operating System Interface (POSIX) - Base Definitions,” December 2004.) (POSIX) defines a file access control mechanism, and mechanisms which can be used to extend it. The NFSv4 specification does not specify in sufficient detail how NFSv4 ACLs map to POSIX. This draft fills this gap by defining the additional concepts and mechanisms needed to achieve a functional and correct mapping.



Table of Contents

1.  Introduction
2.  Syntax for the Representation of ACLs
3.  Relationship Between ACLs and POSIX
    3.1.  Mapping Principals to File Classes
    3.2.  Synchronization Between the Mode and ACL Attributes
    3.3.  Disabling Access Mask Flags Using Masking
    3.4.  Mapping Between Access Mask Flags and Permissions
    3.5.  Write-Through Semantics of the File Mode
4.  Example Algorithms
    4.1.  Behavior Common to all Algorithms
    4.2.  Access Check Algorithm
    4.3.  Computing File Masks From An ACL
    4.4.  Synchronizing File Permission Bits And File Masks
    4.5.  Applying The File Masks to an ACL
5.  Algorithms For Write-Through
    5.1.  Access Check Algorithm With Write-Through
    5.2.  Applying The File Masks to an ACL For Write-Through
A.  POSIX Definitions
6.  References
§  Author's Address
§  Intellectual Property and Copyright Statements




 TOC 

1. Introduction

The NFSv4 specification [1] (Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, “Network File System (NFS) version 4 Protocol,” April 2003.) defines its own access control list model, including ACL semantics. The model chosen is much closer to Windows ACLs than to how the traditional UNIX permission model works. In addition to that, NFSv4 also supports the mode attribute, which corresponds with the UNIX file mode.

POSIX compliant systems that implement extended permission models must do so within the extension mechanisms that POSIX allows in order not to violate assumptions that applications may rightfully make about the system behavior. Violating these assumptions would lead to potential security holes.

The definitions in the NFSv4 specification [1] (Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, “Network File System (NFS) version 4 Protocol,” April 2003.), while sufficient for specifying the interactions with systems that implement the traditional UNIX permission model, are not fully consistent with the extension mechanisms that POSIX defines.

The purpose of this document is to clarify the relationship between NFSv4 ACLs and POSIX, and to detail how NFSv4 ACLs can be implemented correctly on POSIX compliant systems. To this end, the first part of this document discusses how NFSv4 ACLs relate to POSIX, and the second part describes example algorithms which can be used to implement NFSv4 ACLs in a POSIX compliant way.



 TOC 

2. Syntax for the Representation of ACLs

The representation used for ACLs in this document consists of one ACL entry per line, which contains a colon separated list of the who, access mask, flag, and type fields.

The who field is represented by a literal who string (e.g., OWNER@, GROUP@, user@domain, group@domain).

The access mask field is represented by a list of slash separated access mask names (e.g., READ_DATA/WRITE_ACL/EXECUTE).

The flag field is represented by a list of slash separated flag names (e.g., FILE_INHERIT_ACE/IDENTIFIER_GROUP).

The type field is represented as ALLOW, DENY, AUDIT, or ALARM.

The concept of masks is introduced in Section 3.3 (Disabling Access Mask Flags Using Masking): masks are sets of ACE access mask flags. They are represented by a list of slash separated access mask names, like ACE access mask fields.



 TOC 

3. Relationship Between ACLs and POSIX

The Portable Operating System Interface (POSIX) standard [2] (Institute of Electrical and Electronics Engineers, “Information Technology - Portable Operating System Interface (POSIX) - Base Definitions,” December 2004.) defines the framework within which ACLs may grant or deny permissions on POSIX compliant systems. ACLs go beyond the POSIX permission model. POSIX defines extension mechanisms, and the conditions that these extension mechanisms must fulfill in order to comply. We must determine which aspects of ACLs map onto which POSIX concepts, and how ACLs can extend the POSIX permission model without violating POSIX requirements and expectations.

For reference, Appendix A (POSIX Definitions) repeats the definitions of the Definitions volume of POSIX [2] (Institute of Electrical and Electronics Engineers, “Information Technology - Portable Operating System Interface (POSIX) - Base Definitions,” December 2004.) which are relevant to file permissions.



 TOC 

3.1. Mapping Principals to File Classes

POSIX defines that the owner, group, and other file permission bits in the file mode are to be used with the corresponding file classes of processes. In order to apply this definition to files with NFSv4 ACLs, we define the following mapping of principals to file classes:

  • Principals that match the owner attribute (and thus match ACL entries with a who value of OWNER@) are in the file owner class.
  • Principals that are not in the file owner class and match the owner_group attribute (and thus match ACL entries with a who value of GROUP@), or match one or more ACL entries with a who value other than EVERYONE@, are in the file group class.
  • Principals that are not in the file owner or file group class (and thus only match ACL entries with a who value of EVERYONE@) are in the file other class.
  • This definition is consistent with POSIX: the file permission bits in the mode attribute can be converted into an equivalent ACL that grants the same permissions. POSIX allows the group file class to be extended by implementation-defined members. It is reasonable to assign principals that match ACL entries other than OWNER@ to the group file class because these principals are not others in the sense of not being mentioned in the ACL. It is reasonable to assign principals that only match EVERYONE@ ACL entries to the other file class because EVERYONE@ matches all principals, which includes POSIX's others.



     TOC 

    3.2. Synchronization Between the Mode and ACL Attributes

    Principals are associated with a set of Read, Write, and Execute permissions by their file class. Unless Alternate File Access Control Mechanisms as defined in the Definitions volume of POSIX [2] (Institute of Electrical and Electronics Engineers, “Information Technology - Portable Operating System Interface (POSIX) - Base Definitions,” December 2004.) are in effect, this set of permissions defines an upper bound to the permissions that may be granted, and ACLs may further restrict these permissions.

    POSIX requires that for new files and after a setting the file mode, Alternate File Access Control Mechanisms must be disabled, and therefore no more permissions than allowed by the file permission bits must be granted by the ACL. An explicit user action on a per-file basis, such as setting an ACL, may later re-enable Alternate File Access Control Mechanisms.

    Ensuring that an ACL does not granted more permissions than the file mode allows may require removing excess access mask flags from ACL entries, inserting DENY entries at certain positions in the ACL, etc. A worthwhile goal for such an algorithm is that the result of applying a file mode to an ACL should allow as many of the original permissions as possible, without exceeding the file mask.

    Various different algorithms to solve this problem have been proposed. We recommend the algorithm outlined in Section 4.5 (Applying The File Masks to an ACL), because it meets the above-stated goal very well. (Note that the concept of file masks is explained in Section 3.3 (Disabling Access Mask Flags Using Masking).)

    Conversely, setting ACLs should update the mode attribute so that it reflects the permissions that the ACL grants as closely as possible.

    The file permission bits are not enough to cover all mask flags that an ACL may grant, because mask flags such as WRITE_OWNER go beyond Read, Write, and Execute. Nevertheless, the computed mode should reflect which mask flags that are covered by Read, Write, and Execute are granted to which file classes.

    RFC 3530 [1] (Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, “Network File System (NFS) version 4 Protocol,” April 2003.) specifies that the server must synchronize the MODE4_*USR, MODE4_*GRP, and MODE4_*OTH bits with the ACEs which have respective who fields of OWNER@, GROUP@, and EVERYONE@. This definition conflicts with the semantics that POSIX gives the file mode:

    Therefore, to better align NFSv4 with POSIX, we recommend to change the algorithm for computing a file mode from an ACL as follows: upon setting an ACL, set the file permission bits corresponding to the owner, group, and other class to the maximum the permissions that the respective file class is granted, or a superset.

    We allow the mode to be a superset of the permissions that are actually granted because computing the precise maximum is difficult, and POSIX allows implementations to grant fewer permissions to processes than the file permission bits would imply.

    Section 4.3 (Computing File Masks From An ACL) describes an algorithm which can be used to compute the file permission bits from an ACL.

    It is a common misbelief to assume that the group file permission bits reflect the permissions of the owning group: in fact, the group file permission bits correspond with the permissions of the file group class. The file group class also includes principals that do not match the owning group. (See the classification given in Section 3.1 (Mapping Principals to File Classes).)



     TOC 

    3.3. Disabling Access Mask Flags Using Masking

    A server that wishes to implement the mode attribute in a POSIX compliant was must, when the file mode is set, ensure that no process is granted more permissions than allowed by the file mode itself.

    In the process, much or all of the information present in the original ACL can be lost. This is often undesirable. Traditional POSIX filesystems have the property that restoring a mode to a previous value will restore all permissions to the previous value, and some applications may depend on this property.

    Therefore, many filesystems that support both ACLs and mode bits implement them in such a way that setting a more restrictive mode and then restoring the original mode will also restore as much of the original ACL as possible.

    Filesystems do this by storing a "mask" which is independent from the rest of the ACL, and modifying only the mask when the file mode is set. This allows the filesystem to enforce restricted permissions without having to modify the original ACL.

    We recommend to employ this mechanism in NFSv4 servers, and to implement file masks as described in draft-gruenbacher-nfsv4-file-masks-00 [3] (Gruenbacher, A. and J. Fields, “NFSv4 file_masks Attribute,” August 2006.). This proposal introduces file owner, group, and other masks, each containing ACE access masks. The file masks correspond with the owner, group, and other classes of principals. Each mask defines the maximum set of mask flags that a principal in the respective class may be granted, much like the file mode. Setting the file mode sets the file masks, and vice versa.

    This approach allows simple and efficient algorithms for access checking and setting the file mode and ACL attributes, and allows servers to compute the ACL that corresponds to an ACL with a mode applied only when clients request the ACL of a file. It is possible to implemented file masks whether or not the proposal to expose them over the NFSv4 protocol by introducing a file_masks attribute is accepted by the working group.

    The example algorithms in Section 4 (Example Algorithms) detail how to check for permissions and compute file masks from a given ACL, how the file mode interacts with the file masks, and how the file masks can be applied to an ACL to produce an ACL that grants no more than the permissions that the file masks allow.



     TOC 

    3.4. Mapping Between Access Mask Flags and Permissions

    ACLs offer an extended set of access mask flags which goes beyond what can be expressed with the POSIX read, write, and execute permissions. Some of these mask flags are always allowed under POSIX, some correspond to a POSIX permission or are subset of a POSIX permission, and some have no POSIX equivalent. In order to define which access mask flags need to be disabled upon a mode SETATTR, and which permissions in the file mode need to be set upon an ACL SETATTR, we define the following classification of mask flags:


    Access Mask FlagClassification
    READ_DATA Read
    LIST_DIRECTORY Read
    WRITE_DATA Write
    ADD_FILE Write
    APPEND_DATA Write
    ADD_SUBDIRECTORY Write
    READ_NAMED_ATTRS Implementation Defined
    WRITE_NAMED_ATTRS Implementation Defined
    EXECUTE Execute
    DELETE_CHILD Write
    READ_ATTRIBUTES Always Allowed
    WRITE_ATTRIBUTES Alternate
    DELETE Alternate
    READ_ACL Always Allowed
    WRITE_ACL Alternate
    WRITE_OWNER Alternate
    SYNCHRONIZE Does Not Apply
     Table 1: Mapping Between Access Mask Flags and Permissions 

    Mask flags classified as Read, Write, or Execute are equivalent to or a subset of the respective permission. Mask flags classified as Alternate have no equivalent in POSIX, and go beyond Read, Write, and Execute. Mask flags classified as Always Allowed are always allowed under POSIX.

    The READ_NAMED_ATTRS and WRITE_NAMED_ATTRS flags are classified as Implementation Defined. Depending on how access to named attributes is controlled, these mask flags may either have no equivalent in POSIX, or they may be subsets of the Read and Write permissions, respectively. If other means such as file ownership determine access, the two flags should be classified as Alternate.

    The SYNCHRONIZE is classified as Does Not Apply. It defines the permission to access a file locally at the server with synchronized reads and writes. Synchronized reads do not have a correspondence in POSIX.

    A mode SETATTR must disable mask flags classified as Alternate, and must only keep mask flags classified as Read, Write, and Execute enabled if the file class corresponding with the principal includes the respective permissions. It is not required to disable mask flags classified as Always Allowed or Does Not Apply.

    An ACL SETATTR should compute an upper bound of the mask flags granted to each file class of principals. For each file mask in this upper bound that is classified as Read, Write, or Execute, the corresponding permission should be set in the corresponding set of permissions in the file mask.



     TOC 

    3.5. Write-Through Semantics of the File Mode

    Setting the file mode can be given two different semantics: the file mode can be used to define an upper bound to the permissions that the ACL may grant, or it can be used to do that, and additionally define the permissions that the owner, owning group, and others are always granted.

    Conceptually, the latter approach can be thought of as if setting the file mode would "write through" to OWNER@, GROUP@, and EVERYONE@ ACL entries. There are more details to it such as adding missing OWNER@, GROUP@, and EVERYONE@ ALLOW entries, and ensuring that file masks that are not monotonically descreasing will work as expected; see Section 4 (Example Algorithms) for details.

    Each of the two approaches has advantages and disadvantages:

    It is unclear which of the two behaviors is more useful, or if a different behavior such as write-through for only the owner would be more useful. Therefore, we do not recommend any of the two behaviors at this point.



     TOC 

    4. Example Algorithms

    When a mode is applied to a file, this operation can be given two different meanings: the mode can be used to further limit the mask flags that the ACL allows, or it can be used to limit the mask flags that the ACL allows, while at the same time defining the permissions of the owner, owning group, and others.

    Both variants correspond to different ways of applying file masks to an ACL. The latter variant corresponds to having the file masks "write through" to OWNER@, GROUP@, and EVERYONE@ ACL entries and replace their existing mask flags.

    This section describes algorithms that can be used to implement the former variant, where the file masks act as an upper limit on the permissions granted. Please refer to for algorithms that implement the "write-through" behavior.



     TOC 

    4.1. Behavior Common to all Algorithms

    NFSv4 ACLs may include AUDIT and ALARM type entries which are unrelated to file permissions, as well as ALLOW and DENY entries related to access checking, inheritance, or both. Unless stated otherwise, all algorithms treat AUDIT and ALARM type entries and entries with the FILE_INHERIT_ACE, DIRECTORY_INHERIT_ACE, or INHERIT_ONLY_ACE flags set as follows:



     TOC 

    4.2. Access Check Algorithm

    When the ACL and file masks are stored separately as suggested in Section 3.3 (Disabling Access Mask Flags Using Masking), the access check algorithm must take both the ACL and the file masks into account. We achieve this by separately checking if the ACL and the file masks permit the requested access as follows:

    1. If the principal does not match the file owner, continue with the next paragraph. Otherwise, if the requested mask flags exceed the owner mask, deny access. Otherwise, use the NFSv4 access check algorithm to determine access.
    2. If the principal is not a member in the owning group and none of the entries in the ACL with who values other than EVERYONE@ match the principal, continue with the next paragraph. Otherwise, if the requested mask flags exceed the group mask, deny access. Otherwise, use the NFSv4 access check algorithm to determine access.
    3. If the requested mask flags exceed the other mask, deny access. Otherwise, use the NFSv4 access check algorithm to determine access.



     TOC 

    4.3. Computing File Masks From An ACL

    When an ACL is set without setting the file masks at the same time, either when a client only provides the ACL, or when a new file inherits an ACL from its parent directory, the file masks must be computed from the ACL.

    The following algorithm can be used to do this. This algorithm ensures that principals are allowed all mask flags that the ACL allows, independent of which principals are a member of which groups. The algorithm attempts to set the file masks to reasonably restrictive values, so that the resulting file mode which is computed from the file masks will not indicate accesses that the ACL will never grant.

    Set the file owner, group, and other masks to the empty set. Go through all ACL entries in reverse order, and process each ACL entry as follows:

    1. If the entry is a OWNER@ entry, add the mask flags in the entry to the file owner mask if the entry type is ALLOW, and remove them from the file owner mask if the entry type is DENY. Continue with the next entry. Otherwise, continue with the next paragraph.
    2. If the entry is a EVERYONE@ entry, add the mask flags in the entry to the file owner, group, and other masks if the entry type is ALLOW, and remove them from the file owner, group, and other masks if the entry type is DENY. Continue with the next entry. Otherwise, continue with the next paragraph.
    3. If the entry type is ALLOW, add the mask flags in the entry to the file owner and group masks.

    This algorithm results in more permissive file masks in cases where an ACL contains a DENY entry for a who value other than OWNER@ and EVERYONE@, followed by an overlapping ALLOW entry for EVERYONE@ or the same who value. The algorithm can be extended to recognize those situations, which will lead to tighter file masks.

    After updating the file masks, the file permission bits are updated according to Section 4.4.2 (Updating the File Masks).



     TOC 

    4.4. Synchronizing File Permission Bits And File Masks

    The following two algorithms keep the file permission bits in sync with the file masks, which ensures that no principals are granted mask flags that go beyond the file mode after setting the file mode (for new files or after a chmod()), and that the file mode reflects the mask flags granted to owner, group, and other class principals. No principal that has the Read permission cleared in its corresponding file class will be granted read access, etc.


     TOC 

    4.4.1. Updating the File Permission Bits

    Each of the file masks is set so that its mask flags correspond to the permissions granted to the associated class of principals: the owner mask is updated according to the owner class permissions, etc.

    In each file mask, all mask flags that correspond to the permissions in the associated file class according to Table 1 (Mapping Between Access Mask Flags and Permissions) are set, and all others are cleared.

    In addition, all mask flags classified as Always Allowed and Does Not Apply are set in all three file masks in order to avoid confusing principals that rely on these mask flags. Adding these flags is harmless: the ACE4_SYNCHRONIZE flag has no meaning on POSIX systems, while the ACE4_READ_ATTRIBUTES and ACE4_READ_ACL flags are always granted on POSIX systems.



     TOC 

    4.4.2. Updating the File Masks

    In each set of file permissions in the file mode, all permissions that correspond to one or mask flags in the associated file mask according to Table 1 (Mapping Between Access Mask Flags and Permissions) are set.



     TOC 

    4.5. Applying The File Masks to an ACL

    This algorithm applies the file masks to an ACL, so that the resulting ACL grants no more permissions than what the original ACL and the file masks would grant. When clients request the ACL after a mode has been applied to a file, this algorithm determines the ACL which they are returned.

    The algorithm is idempotent: feeding the masked ACL back into the algorithm will result in the identical ACL being returned.

    The algorithm consists of the following steps, each being further described in the respective section in this document:

    1. Propagate all EVERYONE@ ALLOW and DENY entries in the ACL down to the end of the ACL as described in Section 4.5.1 (Move EVERYONE@ ACL Entries Down).
    2. Make sure that applying the file other mask to the optional trailing EVERYONE@ ALLOW entry will not cause non-EVERYONE@ entries to be allowed fewer mask flags than before applying the file other mask by carrying out the algorithm described in Section 4.5.2 (Propagate EVERYONE@ ALLOW Mask Flags).
    3. Apply the file masks to all ACL entries as described in Section 4.5.3 (Apply The File Masks To The ACL Entries).
    4. If the group or file other masks contain mask flags that are not contained in the file owner mask, limit the mask flags allowed to OWNER@ to the file owner mask as described in Section 4.5.4 (Isolate The Owner Class).
    5. If the file other mask contains mask flags that are not contained in the file group mask, limit the mask flags allowed to all group class entries to the file group mask as described in Section 4.5.5 (Isolate The Group Class).



     TOC 

    4.5.1. Move EVERYONE@ ACL Entries Down

    Having EVERYONE@ ALLOW entries in the middle of an ACL makes it difficult to determine which permissions the ACL grants to the other class. To simplify the algorithm in Section 4.5 (Applying The File Masks to an ACL), we propagate all EVERYONE@ ALLOW and DENY entries to the end of the ACL, and replace them by a single optional trailing EVERYONE@ ALLOW entry as follows:

    Let allowed and denied be two empty sets of mask flags.

    1. Go through all ACL entries in forward order. Depending on the type of entry, process the entries as follows:
    2. If allowed is non-empty, insert an EVERYONE@ ALLOW entry at the end of the ACL, and set its mask to allowed.

    This transformation does not change the mask flags allowed to any principal, so this step is always safe to perform.



     TOC 

    4.5.2. Propagate EVERYONE@ ALLOW Mask Flags

    The following ACL grants Read and Write access to the owner, and Read access to the owning group. Applying a mode like 0640 to this ACL requires the mask flags of the EVERYONE@ entry to be cleared, which would modify the permissions that this ACL grants to the owner and owning group, even though mode 0640 does not require that:

    OWNER@:READ_DATA::ALLOW
    GROUP@:WRITE_DATA::DENY
    EVERYONE@:READ_DATA/WRITE_DATA::ALLOW
    

    The following algorithm prevents this from happening.

    If the ACL does not end in an EVERYONE@ ALLOW entry, this algorithm finishes. Otherwise, let allowed be the mask flags of the EVERYONE@ ALLOW entry at the end of the ACL. For OWNER@, GROUP@, and all other who values in the ACL other than EVERYONE@, do the following:

    1. Let add be the mask flags in allowed that who is neither allowed nor denied in any entry in the ACL. If add is empty, continue with the next who value. Otherwise, continue with the next paragraph.
    2. Go through the ACL in reverse order, and search for an ALLOW entry for who. Stop when reaching a DENY entry for any who value.
    3. If an ALLOW entry for who was found, add the mask flags in allowed to the mask of this entry. Otherwise, insert an ALLOW entry for who before the EVERYONE@ ALLOW entry at the end of the ACL, and set its mask to allowed.

    This transformation does not change the mask flags allowed to any principal, so this step is always safe to perform.



     TOC 

    4.5.3. Apply The File Masks To The ACL Entries

    Go through the ACL and apply the appropriate file mask to each ACL entry: apply the file owner mask to OWNER@ entries, apply the file other mask to EVERYONE@ entries, and apply the file group mask to all other entries.

    This ensures that the ACL will not grant any principals more than the associated file mode permissions, if the file masks are monotonically decreasing. (The following two steps ensure that non-monotonically decreasing file masks are handled correctly as well.)



     TOC 

    4.5.4. Isolate The Owner Class

    If the file group or other masks contain mask flags not contained in the owner class, we must ensure that the file owner is not granted any of those mask flags from ACL entries with who values other than OWNER@. The following algorithm achieves this.

    Let owner_deny be the mask flags in the file group and other masks that are not in the file owner mask. If owner_deny is empty, this algorithm finishes. Otherwise:

    1. Go through the ACL in forward order, and search for a OWNER@ DENY entry. Stop when reaching an ALLOW entry for any who value.
    2. If a OWNER@ DENY entry was found, add the mask flags in owner_deny to the mask of this entry. Otherwise, insert an OWNER@ DENY entry at the beginning of the ACL, and set its mask to owner_deny.



     TOC 

    4.5.5. Isolate The Group Class

    If the other mask contains mask flags not contained in the group mask, we must ensure that none of the who values in the ACL is granted any of those mask flags from EVERYONE@ ALLOW entries. The following algorithm achieves this.

    Let group_deny be the mask flags in the file other mask that are not in the file group mask. If group_deny is empty or the ACL does not end in an EVERYONE@ ALLOW entry, this algorithm finishes. Otherwise, for each who value in the ACL other than OWNER@ and EVERYONE@:

    1. Go through the ACL in reverse order starting above the EVERYONE@ ALLOW entry, and search for a DENY entry for who. Stop when reaching an ALLOW entry for any who value.
    2. If a DENY entry for who was found, add the mask flags in group_deny to the mask of this entry. Otherwise, insert a DENY entry for who above the EVERYONE@ ALLOW entry, and set its mask to group_deny.

    Some clients have problems dealing with ACLs that contain DENY entries after ALLOW entries. In order to avoid introducing such entries, implementations may choose to limit the mask flags granted to the trailing EVERYONE@ ALLOW entry to the intersection of the file group and other masks, instead.



     TOC 

    5. Algorithms For Write-Through

    An alternative to assuming that the ACL and mode attributes define permissions independently is to assume that the file mode always defines the permissions granted to the owner, owning group, and others. A simplified way of thinking about this is that setting the file mode "writes through" to OWNER@, GROUP@, and EVERYONE@ entries in the ACL.

    This interpretation of the mode attribute requires a modified access check algorithm so that the file mask flags are always granted to the respective principals, and a modified algorithm for applying the file masks to an ACL, as described in this section.


     TOC 

    5.1. Access Check Algorithm With Write-Through

    The access check algorithm in the write-through case is the same as in the non-write-through case, except that when mask flags are allowed by the file masks, access is immediately granted instead of consulting the ACL. Access checking can be implemented as follows:

    1. If the principal does not match the file owner, continue with the next paragraph. Otherwise, if the requested mask flags exceed the owner mask, deny access. Otherwise, allow access.
    2. If the principal is not a member in the owning group, continue with the next paragraph. Otherwise, if the requested mask flags exceed the group mask, deny access. Otherwise, allow access.
    3. If none of the entries in the ACL with who values other then EVERYONE@ match the principal, continue with the next paragraph. Otherwise, if the requested mask flags exceed the group mask, deny access. Otherwise, use the NFSv4 access check algorithm to determine access.
    4. If the requested mask flags exceed the other mask, deny access. Otherwise, allow access.



     TOC 

    5.2. Applying The File Masks to an ACL For Write-Through

    This algorithm is similar to the equivalent algorithm in the non-write-through case, except that OWNER@, GROUP@, and EVERYONE@ are inserted, and their mask flags set to the file masks, as necessary.

    The algorithm consists of the following steps, each being further described in the respective section in this document:

    1. Propagate all EVERYONE@ ALLOW and DENY entries in the ACL down to the end of the ACL, and replace them by an optional single trailing EVERYONE@ ALLOW entry as described in Section 4.5.1 (Move EVERYONE@ ACL Entries Down).
    2. Make sure that applying the file other mask to the optional trailing EVERYONE@ ALLOW entry will not cause non-EVERYONE@ entries to be allowed fewer mask flags than before applying the file other mask by carrying out the algorithm described in Section 4.5.2 (Propagate EVERYONE@ ALLOW Mask Flags).
    3. Apply the file masks to all ACL entries as described in Section 4.5.3 (Apply The File Masks To The ACL Entries).
    4. Set the permissions allowed to OWNER@, GROUP@, and EVERYONE@ to the full file masks as described in Section 5.2.1 (Allow OWNER@, GROUP@, and EVERYONE@ The Full File Mask Flags). This also ensures that OWNER@ is not allowed more mask flags from group class entries than the file owner mask allows.
    5. If the group or file other masks contain mask flags that are not contained in the file owner mask, limit the mask flags allowed to OWNER@ to the file owner mask as described in Section 4.5.4 (Isolate The Owner Class).



     TOC 

    5.2.1. Allow OWNER@, GROUP@, and EVERYONE@ The Full File Mask Flags

    This algorithm ensures that the owner, owning group, and others are granted all mask flags in the file masks, and that the owner is not granted any mask flags that exceed the owner mask from other ACL entries.

    1. Remove all OWNER@ and GROUP@ entries from the ACL (both ALLOW and DENY entries).
    2. If the ACL ends in an EVERYONE@ ALLOW entry, set the mask of this entry to the file other mask. Otherwise, insert an EVERYONE@ ALLOW entry at the end of the ACL, and set its mask to the file other mask.
    3. Insert a GROUP@ ALLOW entry at the beginning of the ACL, and set its mask to the file group mask.
    4. Insert an OWNER@ ALLOW entry at the beginning of the ACL, and set its mask to the file owner mask.
    5. Let owner_deny be the mask flags in the group or file other masks that are not in the file owner mask. If owner_deny is empty, this algorithm finishes. Otherwise, insert an OWNER@ DENY entry at the beginning of the ACL, and set its mask to owner_deny.



     TOC 

    Appendix A. POSIX Definitions

    For reference, we include the definitions related to file permissions from the Definitions volume of POSIX [2] (Institute of Electrical and Electronics Engineers, “Information Technology - Portable Operating System Interface (POSIX) - Base Definitions,” December 2004.) here.

    File Permission Bits
    Information about a file that is used, along with other information, to determine whether a process has read, write, or execute/search permission to a file. The bits are divided into three parts: owner, group, and other. Each part is used with the corresponding file class of processes. These bits are contained in the file mode.
    File Owner Class
    The property of a file indicating access permissions for a process related to the user identification of a process. A process is in the file owner class of a file if the effective user ID of the process matches the user ID of the file.
    File Group Class
    The property of a file indicating access permissions for a process related to the group identification of a process. A process is in the file group class of a file if the process is not in the file owner class and if the effective group ID or one of the supplementary group IDs of the process matches the group ID associated with the file. Other members of the class may be implementation-defined.
    File Other Class
    The property of a file indicating access permissions for a process related to the user and group identification of a process. A process is in the file other class of a file if the process is not in the file owner class or file group class.
    Additional File Access Control Mechanism
    An implementation-defined mechanism that is layered upon the access control mechanisms defined in [2] (Institute of Electrical and Electronics Engineers, “Information Technology - Portable Operating System Interface (POSIX) - Base Definitions,” December 2004.), but which does not grant permissions beyond those defined in [2] (Institute of Electrical and Electronics Engineers, “Information Technology - Portable Operating System Interface (POSIX) - Base Definitions,” December 2004.), although they may further restrict them.
    Alternate File Access Control Mechanism
    An implementation-defined mechanism that is independent of the access control mechanisms defined in [2] (Institute of Electrical and Electronics Engineers, “Information Technology - Portable Operating System Interface (POSIX) - Base Definitions,” December 2004.), and which if enabled on a file may either restrict or extend the permissions of a given user. IEEE Std 1003.1-2001 defines when such mechanisms can be enabled and when they are disabled.
    File Access Permissions
    The standard file access control mechanism uses the file permission bits, as described below.
    Implementations may provide additional or alternate file access control mechanisms, or both. An additional access control mechanism shall only further restrict the access permissions defined by the file permission bits. An alternate file access control mechanism shall:
    • Specify file permission bits for the file owner class, file group class, and file other class of that file, corresponding to the access permissions.
    • Be enabled only by explicit user action, on a per-file basis by the file owner or a user with the appropriate privilege.
    • Be disabled for a file after the file permission bits are changed for that file with chmod(). The disabling of the alternate mechanism need not disable any additional mechanisms supported by an implementation.
    Whenever a process requests file access permission for read, write, or execute/search, if no additional mechanism denies access, access shall be determined as follows:
    • If a process has the appropriate privilege:
      • If read, write, or directory search permission is requested, access shall be granted.
      • If execute permission is requested, access shall be granted if execute permission is granted to at least one user by the file permission bits or by an alternate access control mechanism; otherwise, access shall be denied.
    • Otherwise:
      • The file permission bits of a file contain read, write, and execute/search permissions for the file owner class, file group class, and file other class.
      • Access shall be granted if an alternate access control mechanism is not enabled and the requested access permission bit is set for the class (file owner class, file group class, or file other class) to which the process belongs, or if an alternate access control mechanism is enabled and it allows the requested access; otherwise, access shall be denied.


     TOC 

    6. References

    [1] Shepler, 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.
    [2] Institute of Electrical and Electronics Engineers, “Information Technology - Portable Operating System Interface (POSIX) - Base Definitions,” IEEE Standard 1003.1, December 2004.
    [3] Gruenbacher, A. and J. Fields, “NFSv4 file_masks Attribute,” Internet Draft draft-gruenbacher-nfsv4-file-masks-00, August 2006.


     TOC 

    Author's Address

      Andreas Gruenbacher
      SUSE Labs, Novell
    Email:  a.gruenbacher@computer.org


     TOC 

    Intellectual Property Statement

    Disclaimer of Validity

    Copyright Statement

    Acknowledgment