ACLs within the NFSv4 Protocols

1.3.1. New ACL Description Framework

There are a number of significant changes in the desriptive framework used to describe the semantics of ACLs, although the XDR description remains the same. The most important concern how to address the need to support multiple semantic models for ACLs,including UNIX ACLs, NFSv4 ACLs and various hybrids of the two.¶

[Author Aside (Item #104a)]: In this document, we adapt a very different approach frm that used previously. This shift, elements of which affect large parts of this document will be identified as Consensus Item #104.¶

In this document the more limited UNIX ACL Model is presented aa foundational, while the elements necessary to provide support for NFSv4 ACLs are treated as OPTIONAL extensions to the UNIX ACL model.¶

[Author Aside (#Item #105a)]: The apparatus provided to inform the client of the semantics provided by the server is described in Section 1.3.2 and other later sections of this document where it is identified as Consensus Item #105.¶

To help better support existing unchangeable minor versions, some elements of the semantic model provided can be inferred from the set of ACE types supported. For NFSv4.2 and future minor versions an additional OPTIONAL attribute Aclfeature is defined as an extension of NFSv4.2.¶

1.3.2. Providing Implementation Information to the Client

The task of fully providing information about the ACL semantics supported by the server to the client is made complicated because of the lack of clear semantic descriptions in previous specifications. This lack of clarity goes beyond what would be necessary to allow use of the two supported ACL models and reasonable hybrids of the two.¶

Previous versions of NFS avoided the need for detailed descriptions of file system semantics by relying on POSIX semantics, with slight modifications to deal with NFSv3 peculiarities such as the lack of over-the-wire open. As a result, the working group had no experience with provding semantic descriptions at the needed level of detail when NFSv4 included additional filesytem semantics for features not covered by POSIX. As a result what emrged was more like a rough plan to develop a complete specfication rather than the specification that should have been part of NFSv4 specifications.¶

As a result of this lack of clear semantic description and the attempt to support two different models without clearly delineating the choices to be made, the Aclfeature attribute described in Section 3.6 is considerably more complex than a small set of bits, one for each potential extension to UNIX ACLs to arive at a full implementation of the NFSv4 ACL model.¶

In many cases, a large number of possible variants of one potentitial feature are likely to exist in different implementations given the lack of detailed semantic description in existing specfifications and the common belief that it is not the job of the implementation to conform to the specification, making it the job of the protocol to serve as an intermediary bewteen clients who are meant to be unaware of these details and servers who are not to be constrained in this regard. As a result, the Aclfeaure attribute, as the only available vehicle to communicate server implementation choices, will provide for all reasonable choices to be commnicated, although there is the prospect of constraining those choces, as described in Section 1.3.3, as we find out whether the lack of deails in existing specfications resulted in substantally different implementations.¶

1.3.3. Limiting Implementation Choices

Although our ultimate goal of defining a clear set of individual extensions to UNIX ACLs that servers can choose and communicate will not be immediately available, we can make progress toward that goal based on the approach taken here and its gradual refinement as we work to move this document forward, taking into account what we learn about existing client and servers that contain ACL support. Note that the reslts will vary based on the minor versions used and the existing use, if any, of many of the extensions to the UNIX ACL model that collectivly constitute the NFSv4 ACL model.¶

Because of the nature of current ACL specifications and the consequent lack of attention to interoperability, we are not, in the initial specification of this attriute, able to communicate the implementation choices made by servers in a compact way, as a small set of individual features that server can choose to implement or not.¶

As a result, the initial specification of the AclFeature attribute provides many choices that exist only because of a lack of detail and clarity in existing specfications.¶

Even if no server implementations implement that initial specifcation, the options that it provides can be used within the working group as a language defining the choices particular implmentations have made, whether made explicitly or by as a consequence of adapting to existing implemetations. Similarly, the expectations of clients could be expressed in terms of the Aclfeature values that particular clients are prepared to deal with.¶

As work proceeds on this document, there are number of ways that the Aclfeature attribute could be refined to more closely approximate the desirable situation dsecibed above, in which the choices are limited to things like the choice of ACL model, support for DENY ACEs, extend-only files and finer-grained directory operation authorization all together with separate choices regarding the set of ACLs to be stored but not necessarily fully supported. As part of that procees, the group will try to delete presentation of choices that could conceivably result from different implementers making different choices to deal with lack of specification detail, but where there is no actual divergence of behavior. Some illustrative examples follow:¶

• Cases where the way in which the default setting for a particular mask bit is not specified or, similarly, where autnorization constraints for actions associated with an unsupported mask bits is not clearly specified.¶

• Two choices that might appear independent are always made together, allowing them the associated options to be coalesced, if otherwise appropriate.¶

• Some extensions, although anticipated as possibilities, might never have been realized in any impementation, allowing the corresponding options to be deleted.¶

There might also be a few situations which Aclfeature might be extended as in the examples below:¶

• The handling of within-directory RENAME might follow the prsentation in th original specification in which it assumes it requires both ACE4_ADD_FILE (ACE4_ADD_SUBDIRECTORY if one is renaming a subdirectory) and ACE4_DELETE_CHILD.¶

  To have this difference in handling have any visible effects would require servers which support distinct permissions for adding and removing files from a drectory (only one has been found so far) together with clients tht set ACLs that have distinct permissions for these two operations (none found so far).¶

• The handling of the mask bits ACE4_{READ,WRITE}_NAMED_ATTRIBUTES might follow the original prsentation, which focused solely on permission to execute the OPENATTR operation, or the one in this document, which, in line with the POSIX-BASED approach to authorization of operations on named attribute directories, has these bit covering the reading and writing of the named attributes directories.¶

  So far no seve implementations have been found supporting this features. If one does and it follows the older approach, the working group will have to decide which approachs needs to be considered recommendd.¶

1.3.4. ACLs in various Minor Versions

[Author Aside (Item #105b), through end of bulleted list]: This sections role is primarily to guide use and development of the Aclfeature attribute. As such, the current version is directed to the Working Group rather than the larger it would have as an approved standards-track doument. In light of it is likely that some of the following changes might be needed.¶

• If the original goals for the Aclfeature attribute are met and the resuling RFC candidate enters WGLC, then sections would need to be feavily revised. Material relating to the earlier stages of attribute development would be eliminated. The description of the situation for various minor vesions would stay pretty much as it is.¶

• If the development of the Aclfeature does not proceed in a timely fashion, and it became necessary to disconnect the development of the Aclfeature from the rfc5661bis effort, the RFC to be included as part of rfc5661bis, while derived from this document will be substantially different:¶

  As part of the deletion of the Aclfeure attribute, this section and a number of other sub-sections of Section 1.3 would be deleted.¶

• If the disconnect described above does occur, the work on the Aclfeature attribute would proceed in a separate document whose iitial draft would derived from this one. We will refer to that document as aclv2, with its handling of this section as described immediately below¶

  The list of stages will be pruned to eliminate those no longer relevant. The description of the situation for various minor vesions would stay pretty much as it is.¶

• When aclv2 was nearly ready for WGLC, another set of changes would be requied¶

  Material relating to the earlier stages of attribute development would be eliminated. The description of the situation for various minor vesions would be lminet to NFSv2 and NFSv3.¶

We can define the various stages of ACL handling as they relate to the development of the aAclfeature attribute as follows:¶

• Stages where the Aclfeature extension is not available.¶

  During this stage we only have the ability to infer the ACL model supported from the set of ACE types supported, with no provision for hybrids.¶

• Stages where the Aclfeature extension is made available for experimental use.¶

  It is expected that this stage would begin when this docuument or a successsor is published as a Working Group Document. At that point the working group would be able¶

• Stages where the Aclfeature extension is first made available for production use.¶

• Stages where the Aclfeature extension is available and other extensions can be made.¶

• Stages where it is possible to further restrct server ehavior or to create additional REQUIRED attributes.¶

  This stage would only be available in a new minor version (e.g. NFsv4.3)¶

These stages apply to various minor vesrsions as follows:¶

• NFSv4.0 implementations have no realistic propect of diretly benefiting from the Aclfeature attribute.¶

  However,¶

• While NFSv4.1 implementations cannot support the Aclfeature attribute, it is relatively easy to convert an NFSv4.1 server implementation to a NFSv4.2 server implementation that supports no v4.2 OPTIONAL feature other that the Aclfeature attribute.¶

  Similarly, an NFSv4.1 client implementation can be easily converted to an NFSv4.2 cliet implementtion that use no v4.2 OPTIONAL feature other that the Aclfeature attribute.¶

• Existing NFsv4.2 client and server implementations could add support for the AclFeature attribute once this is published as part of the set of rfc5661bis-related RFCs.¶

• When and if there is a new NFSv4 minor version that could add REQUIRED attributes or further limit expected ACL behavior (e.g. NFSv4.3), we could limits servers to either of the existing ACL models (with one clear definition of each) or reasonable hybrids thereof.¶

5.1.1. Existing ACE Types

The constants used for the type field (acetype4) and as shifts used in determining ACE type support are as follows:¶

const ACE4_ACCESS_ALLOWED_ACE_TYPE      = 0x00000000;
const ACE4_ACCESS_DENIED_ACE_TYPE       = 0x00000001;
const ACE4_SYSTEM_AUDIT_ACE_TYPE        = 0x00000002;
const ACE4_SYSTEM_ALARM_ACE_TYPE        = 0x00000003;

All four are permitted in the Acl attribute. For NFSv4.1 and beyond, only the ALLOWED and DENIED types are used in the Dacl attribute, and only the AUDIT and ALARM types are used in the Sacl attribute.¶

The "Abbreviation" column denotes how the types will be referred to throughout the rest of this document.¶

5.1.2. ACE Type Support Discovery

[Consensus needed (Item #105i), through end of section]:¶

Discovery of the ACE types that it is appropriate to use can occur in two ways:¶

• By use of the OPTIONAL attribute Aclsupport, the set of supported ACE types can be determined.¶

  This set is limited to ACE types defined in Section 5.1.1and cannot be extended.¶

• By use of the OPTIONAL attribute Aclfeature, the set of supported ACE types can be determined together with a potentially larger set of ACE types that can be set and retriedved without necessarily being supported.¶

  These sets can include ACE types defined by protocol extensions as described in Section 5.1.3 as well as those defined in Section 5.1.1.¶

When neither of these attribute values are available, the client has no way of determining the ACE types supported and when attempting the use of ACE tpes other than ALLOW needs to be prepared for a failure due to non-support. Similarly, when the Aclfeature attribute is not supported, clients attempting to use ACE types other than those defined in Section 5.1.1, need to be prepared for failure to be returned due to non-support.¶

Within the Aclfeature value, words of type af4typemask are analyzed using the definitions below to determine the sets of types which are supported or are storeable without necessarily being supported.¶

const AF4TYPE_GSUPPMASK         = 0x000003ff;
const AF4TYPE_BSUPPMASK         = 0x000ffc00;
const AF4TYPE_STOREMASK         = 0x3ff00000;
const AF4TYPE_GSUPPSHIFT        = 0;
const AF4TYPE_BSUPPSHIFT        = 10;
const AF4TYPE_GSTORESHIFT       = 20;

The bits within the AF4TYPE_GSUPPMASK and AF4TYPE_BSUPPMASK values each represent support for a specfic ACE type using the value one left-shifted by the numeric value of the ACE type plus the associated shift for the field. Separate masks are used for types for which the support is accord with the recommendations of this document (AF4TYPE_GSUPPMASK, AF4TYPE_GSUPPSHIFT) and for those that do not so conform, relying on the more relaxed treatment within previous specfications (AF4TYPE_BSUPPMASK, AF4TYPE_BSUPPSHIFT). Similarly, the bits within the AF4TYPE_STOREMASK value each reprsent the ability to store and return a specfic ACE type using the value one left-shifted by a number of bis equal to the numeric v value of the ACE type plus twenty.¶

5.1.3. ACE Type Extensiion

[Consensus needed (Item #105j), through end of section]:¶

Standards-track docments which define NFSv4 protocol extensions, as provided for in [RFC8178], can extend the set of ACE types. The definition of a new extension type needs to provide the following information:¶

• An ACE type name, genenerally of the form ACE4_???_????_ACE_TYPE which is to be used to define ACEs of the specfifed type, when appearing in the type fields of the ACE.¶

• A numeric value between four and nine that has not been previously used as an ACE type value.¶

  While it is theoretically possible to delete a previously defined ACE type as part of a new minor version, the practical difficulties that result from these being stored within existing file systems require that such numeric values not be reused.¶

• An abbreviation to be used when referring to that ACE type.¶

• A decription of the effect of the ACEs of the specified type within ACL. This needs to inlude, for ACE types that can appear within existing ACL-based attributes, how the presence of the ACE affects existing scans of ACL-based attributes such as an authorization scan or a notification scan in response to action successfully or unsuccessfully attempted.¶

• Description of the set of attributes in which the ACE type can appear which can include Acl, Dacl, Sacl, and new attributes added in the same or previous extensions.¶

5.2.1. Changes in Descriptions of Mask Bits

[Author Aside, Through end of section]: The material in this section identiies changes it has been necessary to make in the description of the ACE mask bits. It is ikely that it will be removed before the successor document is published as an RFC¶

The following items should be noted as cases in which a change related to the description of ACE mask bits. In soome cases, there will be corresponding annotations near the actual text change,nut this is not always the case. Nevertheless, there will need to be consensus regarding the following changes:¶

• [Author Aside (Item #3a)]: Because the following sections have been moved to be part of a general description of ACEs, not limited to authorization, the descriptions no longer refer to permissions but rather to actions. This coud be considered a purely editorial change, but, to allow for possible disagreement on the matter, it will be considered, here and in Appendix A, as consensus item #3.¶
• [Author Aside (Item #4d)]: In a large number of places, SHOULD is used inappropriately, since there appear to be no valid reasons to allow a server to ignore what might well be a requirement. Such changes are not always noted individually below. However, they will be considered, here and in Appendix A, as part of consensus item #4.¶

• [Author Aside (Item #5)}: In a significant number of cases the ACCESS operation had not been listed as an operation affected by the mask bit where logic suggests it needs to be. These individuall additions are not noted individually below, although there is, in each affected section, an annotation indicating that section requires consensus on this point. In all cases, they will be considered, here, in the affected sections and in Appendix A, as part of consensus item #5.¶

  When ACCESS is included as an affected operation, the description identifies the returned bits that are to affected.¶

  When ACCESS is listed as affected, this is only with regard to authorization. Non-authorization uses are discussed elsewhere, as part of this consensus item.¶

• [Author Aside, Including entite bulleted item]: In a number of cases, there are additional changes which go beyond editorial or arguably do so. These will be marked as their own consensus items usually with an accompanying author aside but without necessarily citing the previous treatment. These include the following:¶

  [Author Aside (Item #7a)]: Revisions were necessary to clarify the relationship between READ_DATA and EXECUTE.¶

  [Author Aside (Item #8a)]: Revisions were necessary to clarify the relationship between WRITE_DATA and APPEND_DATA. These are part of consensus item #8.¶

  [Author Aside (Item #9a)]: Clarification of the handling of RENAME by ADD_FILE, ADD_SUBDIRECTORY.¶

• Revisions in handling of the masks WRITE_RETENTION and WRITE_RETENTION_HOLD. These are parts of consensus items #10.¶

5.2.2. Role of Sticky Bit in ACL-based Auhorization

[Author Aside (Item #62a)]: Because of the need to address sticky-bit issue as part of of the ACE mask descriptions, it is appropriate to introduce the subject here.¶

[Author Aside (Item #62a)]: Despite the fact that NFSv4 ACLs and mode bits are separate means of authorization, it has been necessary, even if only for the purpose of providing compatibility with earlier implementations, to introduce the issue here, since reference to this mode bit are necessary to resolve issues regard directory entry deletion, as is done in Section 5.2.10.¶

[Consensus Item, Including List (Item #62a): The full description of the role of the sticky-bit appears in Section 5.3.2 of [I-D.dnoveck-nfsv4-security]. In evaluating and understanding the relationship between the handling of this bit when NFSv4 ACLs are used and when they are not, the following points need to be kept in mind:¶

• This is troublesome in that it combines data normally assigned to two different authorization models and breaks the overall architectural arrangement in which the mask bits represent the mode bits but provide a finer granularity of control.¶

• It might have been possible to conform to the existing architectural model if a new mask bit were created to represent the directory sticky bit. It is probably too late to do so now, even though it would be allowed, from the protocol point of view, as an NFSv4.2 extension.¶

• The new treatment in Section 5.2.10 is more restrictive than the previous one appearing in Section 5.2.11. This raises potential compatibility issues since the new treatment, while designed to address the same issues was designed to match existing Unix handling of this bit.¶

• This handling initially addresses REMOVE and does not address directory sticky bit semantics with regard to RENAME. Whether it will do so is still uncertain.¶

• The handling of this mode bit was not documented in previous specifications. However, there is a preliminary attempt to do so in Section 5.3.1 of [I-D.dnoveck-nfsv4-security]. The reason for doing so, is that, given the Unix orientation of the mode attribute, it is likely that servers currently implement this, even though there is no NFSv4 documentation of this semantics¶

  This treatment needs to be checked for compatibility issues and also to establish a model that we might adapt to the case of NFSv4 ACLs.¶

• In the long term, it would make more sense to allow the client rather than the server to have the primary role in determining the semantics for things like this. That does not seem possible right now but it is worth considering.¶

5.2.3. Uses of Core Mask Bits

[Consensus Needed (Items #4e, #5a, #7b, #8b, #106a, #107a, #108a, #109a), Throughout section]¶

ACE4_READ_DATA (for non-directory objects)¶

• Operation(s) affected:

  READ¶

  [Consensus Needed (Item #101a)]: READLINK¶

  OPEN (for read or read-write)¶

  ACCESS (ACCESS4_READ)¶

  Discussion:

  The action of reading the data of the file, or, in some cases, providing necessary preparation to do so.¶

  [Previous Treatment (Items #4e, #7b)]: Servers SHOULD allow a user the ability to read the data of the file when only the ACE4_EXECUTE access mask bit is allowed.¶

  [Author Aside (Item #7b)]: The treatment needs to be clarified to make it appropriate to all ACE types.¶

  [Consensus Needed (Items #4e, #7b)]: When used to handle READ or OPEN operations, the handling MUST be identical whether this bit, ACE4_EXECUTE, or both are present, as the server has no way of determining whether a file is being read for execution are not. The only occasion for different handling is in construction of a corresponding mode or in responding to the ACCESS operation.¶

ACE4_LIST_DIRECTORY (for directories which are not named attribute directories)¶

• Operation(s) affected:

  WRITE¶

  OPEN (for write or read-write)¶

  ACCESS (ACCESS_MODIFY)¶

  ACCESS (ACCESS_EXTEND)¶

  • Only when ACE4_EXTEND_DATA in not supported.¶

  ACCESS (ACCESS_DELETE)¶

  • Only when ACE4_DELETE in not supported.¶

  SETATTR of size (extension)¶

  • Only when ACE4_EXTEND_DATA in not supported.¶

  SETATTR of size (truncation)¶

  Discussion:

  [Author Aside (Item #8b)]: Needs to be revised to deal with issues related to the interaction of WRITE_DATA and APPEND_DATA.¶

  [Consensus Needed (Item #8b)]: The action of modifying existing data bytes within a file's current data. When ACE4_APPEND_DATA is not supported, the action of extending a file's, data (e.g. by a WRITE which extends EOF, is included as well¶

  [Consensus Needed (Item #8b)]: As there is no way for the server to decide, in processing an OPEN or ACCESS request, whether subsequent WRITEs will extend the file or not, the server will, in processing an OPEN treat masks containing only WRITE_DATA, only APPEND_DATA, or both bits, in identical fashion. The result of ACCESS will reflect the individal authorizations to overwrite existing bytes and to extend the file.¶

  [Consensus Needed (Item #8b)]: In processing a WRITE request, the server is presumed to have the ability to determine whether the current request extends the file and whether it modifies bytes already in the file.¶

  [Consensus Needed (Item #8b)]: ACE4_WRITE_DATA is required to process a WRITE which spans pre-existing bytes in the file, whether the file is extended or not.¶

ACE4_LIST_DIRECTORY (for named attribute directories)¶

• Operation(s) affected:

  All operations normally controlled by ACE4_READ_NAMED_ATTRIBUTES are contrlled by ACE4_LIST_DIRECTORY when ACE4_READ_NAMED_ATTRIBUTES is not supported.¶

  Discussion:

  [Consensus Needed (Item #111b)]: Through rest of this entry¶

  In order to adapt authorization of operations on named attribute directories to POSIX permission concepts as refleted in UNIX ACLs which have no support for name attributes, the actual control of authorization for the covered actions depends on this bit ored with ACE4_EXECUTE.¶

  As a result these actions are allowed if either bit is specfied as allowed while they can be disallowed only if neither bit is specfoed as allowed or both bits are specified as denied.¶

ACE4_WRITE_DATA (for directories)¶

• Operation(s) affected (only including named attribute directories when ACE4_WRITE_BAMED_ATTRIBUTES is not supported)

  CREATE¶

  • Will require ACE4_ADD_FILE, ACE4_ADD_SUBDIRECTORY, when these are supported.¶

  LINK¶

  OPEN (which creates file in the directory)¶

  ACCESS (ACCESS4_EXTEND)¶

  REMOVE (may require ACE4_DELETE_CHIILD, when supported¶

  RENAME (on the target drectory)¶

  Discussion:

  Operations which modify a directory¶

  Many of these operations may controlled at a finer granularity, when the appropriate mask bits are supported.¶

ACE4_WRITE_DATA (for all object types)¶

• Operation(s) affected (only when ACE4_WRITE_NAMED-ATTRIBUTES is ot supported):

  OPENATTR (when createdir is true)¶

  Discussion:

  [Consensus Needed (Item #111b)]: Through rest of this entry¶

  This acton is normally controlled by ACE4_WRITE_NAMED_ATTRIBUTES, but need to be controlled by ACE4_WRITE_DATA when the former is not supported (e.g. when UNIC ACLs are provided by the server.¶

ACE4_EXECUTE (for non-diectory objects)¶

• Operation(s) affected:

  READ¶

  OPEN (for read or read-write)¶

  ACCESS (ACCESS4_EXECUTE)¶

  REMOVE¶

  RENAME¶

  LINK¶

  CREATE¶

  Discussion:

  The action of reading a file in order to execute it.¶

  Servers MUST allow a user the ability to read the data of the file when only the ACE4_EXECUTE access mask bit is allowed. This is because there is no way to execute a file without reading the contents. Though a server may treat ACE4_EXECUTE and ACE4_READ_DATA bits identically when deciding to permit a READ or OPEN operation, it MUST still allow the two bits to be set independently in NFSv4 ACLs, and distinguish between them when replying to ACCESS operations. In particular, servers MUST NOT silently turn on one of the two bits when the other is set, as that would make it impossible for the client to correctly enforce the distinction between read and execute permissions.¶

  As an example, following a SETATTR of the following NFSv4 ACL:¶

  • nfsuser:ACE4_EXECUTE:ALLOW¶

  A subsequent GETATTR of acl attribute for that file will return:¶

  • nfsuser:ACE4_EXECUTE:ALLOW¶

  and MUST NOT return:¶

  • nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW¶

ACE4_EXECUTE (for directories which are not named attribute directories)¶

• Operation(s) affected:

  LOOKUP¶

  ACCESS(ACCESS4_LOOKUP)¶

  Discussion:

  The action of traversing directory by searching for a particular named item.¶

ACE4_EXECUTE (for named attribute directories)¶

• Operation(s) affected:

  All operations normally controlled by ACE4_READ_NAMED_ATTRIBUTES are contrlled by ACE4_EXECUTE when ACE4_READ_NAMED_ATTRIBUTES is not supported.¶

  Discussion:

  [Consensus Needed (Item #111b)]: Through rest of this entry¶

  In order to adapt authorization of operations on named attribute directories to POSIX permission concepts as refleted in UNIX ACLs which have no support for name attributes, the actual control of authorization for the covered actions depends on this bit ored with ACE4_LIST_DIRECTORY.¶

  As a result these actions are allowed if either bit is specfied as allowed while they can be disallowed only if neither bit is specified as allowed or both bits are specified as denied.¶

5.2.4. Uses of Finer-grained Mask Bits Derived from Write

[Consensus Needed (Item #103x), Through the end of the following list]: The mask bits presented in this section all control some subset of the actions controlled by the write permission bit when POSIX auhorizattion is in effect. These mask bits, when fully supported, provide for finer-grained control of authorization decisions. The corresponding ACE mask bit, ACE4_WRITE_DATA, still control actions for which no corresponding mask bit defined in this section provides for finer-grained control.¶

Although obect deletion is controlled by ACE4_DELETE for all types of objects, the situation is different for directories and for on-directory objects:¶

• For non-directory objects, once file deletions are excluded, all actions can be divided into those controlled by ACE4_WRITE_DATA and those controlled by ACE4_APPEND_DATA.¶

  While separate control of these two bits is not available on severs implementing UNIX ACLs, it appears that there will also be servers more oriented to the NFSv4 ACL model, that do not distinguish these either. As a result, clients that need control of these to be distinct need to use the facilities described in Section 5.2.7 to ensure that such support is available before relying on different treatment for these two action subsets.¶

• For directories, many actions are subject to finer-grained control when the mask bit defined in this section are implemented. These include ACE4_ADD_FILE, ACE4_ADD_SUBDIRECTORY, ACE4_DELETE_CHILD.¶

  [Author Aside (Item #9b)]: The handling of RENAME in disngushing crosss-directory and within-diretory RENAME options has to be considered tentative. However, even though this is ifferent from previous treatments of the issue needs to be carefully considered by the working group. This is primrily because there seems to be no clear motivation for the previous treatment and because it seems unlikely that restrictions on adding or deleting objects would necessitate corresponding restrictions on renaming them, in case in which the directory was not read-only.¶

  [Consensus Needed (Item #9b)]: Even when all the above bits are fully supported, the action of renaming a file or directory is controlled by ACE4_WRITE_DATA for the enclosing directory.¶

[Consensus Needed (Items #4f, #5a, #7b, #8b, #101a, #106a, #107a, #108a, #109a), Throughout rest of section]¶

ACE4_ADD_FILE (For directories)¶

• Operation(s) affected:

  CREATE¶

  LINK¶

  OPEN (when creating a new file)¶

  RENAME (in the cross-directory case)¶

  Discussion:

  The action of adding a new file in a directory. The CREATE operation is affected when nfs_ftype4 is NF4LNK, NF4BLK, NF4CHR, NF4SOCK, or NF4FIFO. (NF4DIR is not included because it is covered by ACE4_ADD_SUBDIRECTORY.) OPEN is affected when used to create a regular file. LINK is always affected and RENAME is affected when a file/directory is moved betweewn directories, with ACE4_ADD_SUBDIRECTORY covering the case when a directory is renmed betweeen directories.¶

ACE4_APPEND_DATA (For non-directory objects)¶

• Operation(s) affected:

  WRITE¶

  ACCESS¶

  OPEN¶

  SETATTR of size¶

  Discussion:

  [Author Aside]: Also needs to be revised to deal with issues related to the interaction of WRITE_DATA and APPEND_DATA.¶

  The action of modifying a file's data, but only starting at EOF. This allows for the specification of append-only files, by allowing ACE4_APPEND_DATA and denying ACE4_WRITE_DATA to the same user or group.¶

  [Consensus Needed (Item #8c)]: As there is no way for the server to decide, in processing an OPEN or ACCESS request, whether subsequent WRITEs will extend the file or not, the server will treat masks containing only WRITE_DATA, only APPEND_DATA or both, identically.¶

  [Consensus Needed (Item #8c)]: If the server is processing a WRITE request and the area to be written extends beyond the existing EOF of the file then the state of APPEND_DATA mask bit is consulted to determine whether the operation is permitted or whether alarm or audit activities are to be performed. If a file has an NFSv4 ACL allowing only APPEND_DATA (and not WRITE_DATA) and a WRITE request is made at an offset below EOF, the server MUST return NFS4ERR_ACCESS.¶

  [Consensus Needed (Item #8c)]: If the server is processing a WRITE request and the area to be written does not extend beyond the existing EOF of the file then the state of APPEND_DATA mask bit does not need to be consulted to determine whether the operation is permitted or whether alarm or audit activities are to be performed. In this case, only the WRITE_DATA mask bit needs to be checked to determine whether the WRITE is authorized.¶

ACE4_ADD_SUBDIRECTORY (For directories)¶

• Operation(s) affected:

  CREATE¶

  RENAME (in the cross-directory case)¶

  Discussion:

  [Author Aside]: The RENAME cases need to be limited to the renaming of directories, rather than saying, "The RENAME operation is always affected."¶

  [Consensus Needed (Item #9b)]: The action of creating a subdirectory in a directory. The CREATE operation is affected when nfs_ftype4 is NF4DIR. The RENAME operation is always affected when directories are renamed and the target directory NFSv4 ACL contains the mask bit ACE4_ADD_SUBDIRECTORY.¶

ACE4_DELETE_CHILD (For Directories)¶

• Operation(s) affected:

  REMOVE¶

  RENAME (in the cross-directory case)¶

  Discussion:

  The action of deleting a file or directory within a directory. See Section 5.2.10 for information on now ACE4_DELETE and ACE4_DELETE_CHILD are to interact.¶

ACE4_DELETE (For all types of objects)¶

• Operation(s) affected:

  REMOVE¶

  Discussion:

  The action of deleting the associated file or directory. See Section 5.2.10 for information on how ACE4_DELETE and ACE4_DELETE_CHILD are to interact.¶

ACE4_WRITE_NAMED_ATTRS¶

• Operation(s) affected, for all object types:

  OPENATTR (when createdir is true)¶

  Operation(s) affected, for named attribute directories:

  CREATE¶

  LINK¶

  OPEN (which creates file in the directory)¶

  ACCESS (ACCESS4_EXTEND)¶

  REMOVE¶

  RENAME¶

  Discussion:

  The action of writing the named attributes of a file or of creating a named attribute directory. OPENATTR is affected when it is used to create a named attribute directory. This is when createdir is TRUE.¶

  [Author Aside (Item #111c)]: Despite the orgiginal intention for this bit, it appears that the original scheme incoreectly, allowed all sorts of chnges to name attributes as long as the named attribute directory already existed. For this reason, the current version changes that scheme even though no implementtion supporting this mask bit has yet been found. In the event one is found that follows the original scheme, the working group will need to decide how to respond. One possibiliy is to continue to recommened the approach here while allowing that recommendation to be bypassed. When Aclfeatue is supported, the desription of th support would indicate the non- recommended character of the existing support.¶

  The ability to check whether or not a named attribute directory exists depends on the ability to look it up; therefore, users also need the ACE4_READ_NAMED_ATTRS permission in order to create a named attribute directory.¶

  [Author Aside (Item #111a)]: Actually, they need that permission to create a named attribute.¶

5.2.5. Uses of Other Additional Mask Bits

The mask bits discussed in this section all authorize actions, that, in the absence of support for that bit mask bit, are not resolved by one of the three POSIX-derived permission bits.¶

It is important to note this fact because prvious treatments of the bit mask have strongly suggested that each bit is either identical to a POSIX permission bit or controls a subset of one, as prt of a system of controlling actions at a finer level of granularity. This seems to exclude cases like the mask bits defined in this section and in Section 5.2.6.¶

Where these bits are not supported, the authorization decision will be arrived at, in one of the ways listed below, with the specifics presented below as part of the discussion of that particular bit.¶

• The authorization can be controlled by file ownershiip.¶
• The authorization can be controlled by some boolean combination of multiple permission bits or the mask bits that correspond to those permission bits.¶
• The authorization can be controlled by some boolean combination file ownership and permission bits¶

[Consensus Needed (Item #102b)]: The authorization information presented here is based on the only known implementtion of each of the specified bits. Facilties need to be provided to allow the specifics to be derived as part of mask support discovery.¶

ACE4_WRITE_ATTRIBUTES (for all object types)¶

• Operation(s) affected:

  SETATTR of time_access_set, time_backup, time_create, time_modify_set, mimetype, hidden, system.¶

  Discussion:

  The action of changing the tims associated with a file or directory to an arbitrary value. Also controls changing the mimetype, hidden, and system attributes.¶

  Implementation Informtion:

  Acts as a finer-grained correlate of file ownership.¶

  A user having ACE4_WRITE_DATA or ACE4_WRITE_ATTRIBUTES will be allowed to set the times associated with a file to the current server time.¶

ACE4_WRITE_ACL (for all object types)¶

• Operation(s) affected:

  SETATTR of acl and mode¶

  Discussion:

  The action of modifying the acl or mode attributes.¶

  Implementation Informtion:

  Acts as a finer-grained correlate of file ownership.¶

ACE4_WRITE_OWNER (for all object types)¶

• Operation(s) affected:

  SETATTR of owner and owner_group¶

  Discussion:

  The action of modifying the owner or owner_group attributes. On UNIX systems, this done by executing chown() and chgrp().¶

  Implementation Informtion:

  Acts as a finer-grained correlate og file ownership.¶

ACE4_READ_NAMED_ATTRS (for all object types)¶

• Operation(s) affected:

  OPENATTR¶

  OPEN when the current fh is a named attribute directory(for read or read-write)¶

  ACCESS when the current fh is a named attribute directory (ACCESS4_READ, ACCESS4_LOOKUP)¶

  READDIR when the current fh is a named attribute directory¶

  LOOKUP when the current fh is a named attribute cirectory¶

  Discussion:

  The action of reading the named attribute directory of a file or of looking up a named attribute directory.¶

  [Author Aside (Item #111d)]: It appears that this bit is identical to the or of the read and execute privilege bits for the named attribute directory. Unfortunatelly there is no way to set the Mode attribute (or any attribute) of the named attribute directory.¶

  [Consensus needed (Item #111d): When this mask bit is not supported, the actions normally controlled by it are controlled by the or of the two mask bits ACE4_EXECUTE and ACE4_LIST_DIRECTORY.¶

  [Previous treatment (Item 111d)}: OPENATTR is affected when it is not used to create a named attribute directory. This is when 1) createdir is TRUE, but a named attribute directory already exists, or 2) createdir is FALSE.¶

  [Author Aside (Item #111d)]: The implication in the above paragraph, the OPENATTR is not affected when it is used to create a named directory troublesome, since, regardless of the clients intentions, lookup acces in the named directory in probably neessary.¶

ACE4_SYNCHRONIZE¶

• Operation(s) affected:

  NONE¶

  Discussion:

  Permission to use the file object as a synchronization primitive for interprocess communication. This permission is not enforced or interpreted by the NFSv4.1 server on behalf of the client.¶

  Typically, the ACE4_SYNCHRONIZE permission is only meaningful on local file systems, i.e., file systems not accessed via NFSv4.1. The reason that the permission bit exists is that some operating environments, such as Windows, use ACE4_SYNCHRONIZE.¶

  For example, if a client copies a file that has ACE4_SYNCHRONIZE set from a local file system to an NFSv4.1 server, and then later copies the file from the NFSv4.1 server to a local file system, it is likely that if ACE4_SYNCHRONIZE was set in the original file, the client will want it set in the second copy. The first copy will not have the permission set unless the NFSv4.1 server has the means to set the ACE4_SYNCHRONIZE bit. The second copy will not have the permission set unless the NFSv4.1 server has the means to retrieve the ACE4_SYNCHRONIZE bit.¶

  Implementation Informtion:

  In the only known implementation of this mask bit, its effective setting, for ACEs for OWNER@, GROUP@, and EVERYONE@,is derived by oring the three POSIX-derived privilege bits for that who value.¶

5.2.6. Possible Uses of Additional Mask Bits

The mask bits discusssed in this section all have definitions in exising specifications, but, so far, no substantive support for them has been found. As a result, any discussion of these is tentative and the working group will need to adjust approproately when implementations are found or it is concluded that no such implementations exist.¶

Implemetation of these mask bits are not yet pesent for various reasons:¶

• In the case of ACE4_READ_ATTRIBUTES, it is because the implementation investigated, while it does accept this bit in ACLs and returns it as set or not appropriately it never uses this bit to control authorization decisions¶

  [Author Aside (Item #112a)]: It does not seem likely that client-side software would be prepared to deal effectively with a file which could be looked up but whose attributes cannot be obtained. As a result, it appears unlikly that more substantive implementations will exist.¶

• In the cases of ACE4_WRITE_RETENTION and ACE4_WRITE_RETENTION, it is because the implementation investigated does not contain support for the secific OPTIONAL attributes affected.¶

  [Author Aside (Items #10a, #11a)]: It does not appear that the descrptions of the mask bits appearing below were fully thought out before being incorporated as part of Proposed Standards. For specfics, asides below will provide more detail. In any case, the working group will need to think about replacements while avoiding compatbility for any existing implementztions. Any replacement needs to:¶

  1. If separate bits for these are to be maintained and the server is allowed to refer to a coarser-grained bit when when the finer-rained bit is supported, the client needs a way to determine,in advance, whether this will happen.¶
  2. There needs to be some recognition of the fact that a retention hold, by its nature needs to be protected from arbitrary disablement as is likely to happen if the privileges to modify these or to change authorization for their change, is identical to privleges to establish them.¶

ACE4_READ_ATTRIBUTES (for all object types)¶

• Operation(s) affected:

  GETATTR of file system object attributes¶

  VERIFY¶

  NVERIFY¶

  READDIR¶

  Discussion:

  The action of reading basic attributes (non-ACLs) of a file. On a UNIX system, such basic attributes can be thought of as the stat-level attributes. Allowing this access mask bit would mean that the entity can execute "ls -l" and stat.¶

  [Author Aside (Items #11a, #112a)]: It is not clear that existing clients are prepared to deal with denial of authorization for such operations. As a result, if this mask bit is retained, there need to be a way for clients to know, in advance that such behavior is possible before proceding to use the file system.¶

  If a READDIR operation requests attributes, this mask needs to be be allowed for the READDIR to succeed.¶

  [Author Aside (Items #11a, #112a)]: The suggestion above needs to be looked at closely. Even if it is justifiable to prevent access to attribute values, failing the entire READDIR seems unduly harsh. Returning an empty attribute set would be preferable as there seems no justification for making it impossible to get attributes for other files in the directory simply because a single one is so constrained.¶

ACE4_WRITE_RETENTION (for all object types)¶

• Operation(s) affected:

  SETATTR of retention_set, retentevt_set.¶

  Discussion:

  The action of modifying the durations for event and non-event-based retention. Also includes enabling event and non-event-based retention.¶

  [Previous Treatment]: A server MAY behave such that setting ACE4_WRITE_ATTRIBUTES allows ACE4_WRITE_RETENTION.¶

  [Author Aside]: The use of "MAY" here ignores the potential for harm which unexpected modification of the associated attributes might cause for security/compliance.¶

  [Consensus Needed (Items #10a, #11a)]: If this mask bit is not supported, the specfied action would be controlled by ACE4_WRITE_ATTRIBUTES .¶

ACE4_WRITE_RETENTION_HOLD (for all obhect types)¶

• Operation(s) affected:

  SETATTR of retention_hold.¶

  Discussion:

  The action of modifying the administration retention holds.¶

  [Author Aside]: It seems that if multiple bits are to be defined for this and ACE4_WRITE_RETENTION, there would be a need to further restrict authorization for the modification of administrative retetion holds.¶

  [Previous Treatment]: A server MAY map ACE4_WRITE_ATTRIBUTES to ACE_WRITE_RETENTION_HOLD.¶

  [Author Aside]: The use of "MAY" here ignores the potential for harm which unexpected modification of the associated attributes might cause for security/compliance.¶

  [Consensus Needed (Items #10a, #11a)]: If this mask bit is not supported, the specfied action would be controlled by ACE4_WRITE_ATTRIBUTES .¶

5.2.7. ACE Mask Support Discovery

Of the ACE mask bits defined above and those added later by extensions as described in Section 5.2.9, support for most is OPTIONAL. The only exceptions are for those discussed in Section 5.2.3, which need to be supported whenever ACL-related authorization attributes are supported.¶

When the the Aclfeature attribute is present, information about the support of individual ACE mask bits aare provided as described in the rest of this section. This information includes deermining which bits are supported together with information clients ight need about the nature of the support provided. When the Aclfeature attribute is not supported, the client can obtain information about the support for various ACE mask bits as descrbed in Section 5.2.8.¶

Within the Aclfeature attribute, individual af4minfo elements within maskinf array, each specify the support characteristics of a set of mask bits identified my the maskw field. The support characteristics of that set of bits is provided by the corresponding maskw value, which is structured as follows:"¶

const ACLF4_MIM_SUPP            = 0x00000007;
const ACLF4_MISH_SUPP           = 0;
const ACLF4_MIBC_SUPP           = 3;
const ACLF4_MIM_OTYPE           = 0x00000018;
const ACLF4_MISH_OTYPE          = 3;
const ACLF4_MIBC_OTYPE          = 2;
const ACLF4_MIM_USES            = 0x00000060;
const ACLF4_MISH_USES           = 5;
const ACLF4_MIBC_USES           = 2;
const ACLF4_MIM_BASIS           = 0x07ffff80;
const ACLF4_MISH_BASIS          = 7;
const ACLF4_MIBC_BASIS          = 20;
const ACLF4_MIM_CSUPP           = 0X18000000;
const ACLF4_MISH_CSUPP          = 27;
const ACLF4_MIBC_CSUPP          = 2;

This word is divided into the following bit fields, each of which has constnats above defining the bit field mask, the shift count of the field and the bit count of the field.¶

• The support field within ACLF4_MI*_SUPP indicates the level of support provided for the associated mask bits specified in the maskw word.¶

• The object-type-related bits within the field ACLF4_MI*_OTYPE serve to qualify the mask bits witin the maskw word as applying to directories, to non-directory objects, or to all objects.¶

• The uses-related bits within the field ACLF4_MI*_USES serve to qualify the information about the mask bits the maskw word as applying to their use in authorization, the non-authorization functions described in Section 9, or to both sets of uses. objects, or to both.¶

• The basis-related sub-fields within the field ACLF4_MI*_BASIS identify the higher-level entities from which the specfied mask bits' actions are taken and which provide authorizattion and related functions when those mask bits are not supported.¶

  This field is divided into the sub-fields ACLF4_MI*_BTYPE, ACLF4_MI*_NUMB, ACLF4_MI*_BVAL, and ACLF4_MI*_BMASK, all of which are explained below.¶

• The support-compliance-related bits within the field ACLF4_MI*_CSUPP serve to indicate wheher the handling of associated mask bits conforms to the recommendations of this document.¶

The support field uses the values defined below to communicate information about the support for a set of masks as defined by the mask word and the object-type field.¶

const ACLF4_MIF_SLREJECT        = 0;
const ACLF4_MIF_SLIGNORE        = 1;
const ACLF4_MIF_SLSUPP          = 2;
const ACLF4_MIF_SLDEFAULT       = 3;
const ACLF4_MIF_SLJOINED        = 4;

The values which can be specified in the support field are listed below. Each indicae a particular level of suppor for the mask bits in maskw when used with object of type specified by the obect-type field when used in acccord with the uses field.¶

• The value ACLF4_MIF_SLREJECT indicates that the mask bit specified are invalid when used in ACEs of the associated ACE type for objects of the specified types.¶

• The value ACLF4_MIF_SLIGNORE indicates that the mask bits specified are ignored rather than being supported for objects of the specified types.¶

  For authorization-related uses, the covered actions are always considered authorized and their appearance in ALLOW and DENY has no affect¶

  For other uses, the actions covered by the mask bits cannot be specified for the actions indicated by AUDIT and ALARM ACEs, even when those bits are present.¶

• The value ACLF4_MIF_SLSUPP indicates that the mask bits specified are supported for objects of the specified types.¶

  For the authorization of actions covered by the specified mask bits, the appearance of these mask bits in ALLOW and DENY ACEs controls the authorization of the action, which is authorized if it appear in an applicable ALLOW ACE and never in an applicable DENY ACE.¶

  For other uses, the actions covered by the mask bits are dealt with when they appear in AUDIT and ALARM ACEs.¶

  The actions covered by the specified bits as supported is expected to remove those actions from covrage by coarser-grained entities that covers those actions when those mask bits are not supported. See the detailed description of the basis-related sub-fields below.¶

• The value ACLF4_MIF_SLDEFAULT indicates that the mask bits specified are partially supported for objects of the specified types.¶

  This partial support allows the mask buts to be specified in ALLOW, DENY, AUDIT, and ALARM ACEs, just as is the case with ACLF4_MIF_SLSUPP. However, the special deaulting behavior associted with these masks often make their appearance in ALLOW ACEs unnecessary.¶

  Depending on the details of the basis-related field, the actions covered by the specified bits as supported is expected to remove those actions from covrage by coarser-grained entities that covers those actions when those mask bits are not supported. In addition, the basis-related field can specify a set of condition for the default authoization behavior to be used when the specfied mask bits are neither allowed nor denied. See the detailed description of the basis-related sub-fields below.¶

• The value ACLF4_MIF_SLJOINED indicates handling similar to that signified by ACLF4_MIF_SUPP but with one additional constraint.¶

  When the set of selected mask its contains more than a single bit, those setting ACEs containing any of those bits need to be sure that they all have the same value, i.e. that if one of them is set, so are all te rest. If this is not the case, the ACE MUST be rejected.¶

const ACLF4_MIF_DIR             = 0x00000008;
const ACLF4_MIF_NDIR            = 0x00000010;
const ACLF4_MIF_OALL            = 0x00000018;

The individual flags within ACLF4_MIM_OTYPE qualify the mask bits as to whether they apply to directories, to non-directory objects or to all objects. It is often necessary to describe hese separately because the actions covered are different in the case of directories. This can occur whther the same name is used for the mask bit as applied to different objects or not.¶

• When the flag ACLF4_MIF_DIR is set the designated actions are those defined as applying to the mask bits when used with directories.¶

• When the flag ACLF4_MIF_NDIR is set the designated actions are those defined as applying to the mask bits when used with non-directory objects.¶

• When the value ACLF4_MIF_OALL is used, both bits are set and the bits in the specfied mask apply to all type of objects. This is irrespective of whether the birs have the same names when aplied to different types of objects or cover dfferent sets of actions when aplied to different types of objects.¶

const ACLF4_MIF_UAUTH           = 0x00000020;
const ACLF4_MIF_UOTHR           = 0x00000040;
const ACLF4_MIF_UALL            = 0x00000060;

The individual flags within ACLF4_MIM_USES qualify the entries as applying to uses of the specified mask bits as to whther they apply to operation authorization, to the non-authorizatio function described in Section 9, or to all uses.¶

• When the flag ACLF4_MIF_UAUTH is set, the entry applies to the specified mask bits appearing in ALLOW and DENY ACEs.¶

• When the flag ACLF4_MIF_UOTHR is set, the entry applies to the specified mask bits appearing in AUDIT and ALARM ACEs.¶

• When the value ACLF4_MIF_UALL is used, both bits are set and the bits in the specfied mask apply to all type ACEa.¶

The basis field ACLF4_MIM_BASIS is defined into a number of sub-fields as described below. Some things to note:¶

• The definition for ACLF4_MIM_* and ACLF4_MISH_ are relative to the word as a whole, rather than the basis field.¶

• Usage of many of these subfields is controlled by the value within the ACLF4_MI*_BTYPE subfield.¶

const ACLF4_MIM_BTYPE           = 0x00000380;
const ACLF4_MISH_BTYPE          = 7;
const ACLF4_MIBC_BTYPE          = 3;
const ACLF4_MIM_BNUMB           = 0x00007c00;
const ACLF4_MISH_BNUMB          = 10;
const ACLF4_MIBC_BNUMB          = 5;
const ACLF4_MIM_BVAL            = 0x001F8000;
const ACLF4_MISH_BVAL           = 15;
const ACLF4_MIBC_BVAL           = 6;
const ACLF4_MIM_BMASK           = 0x07e00000;
const ACLF4_MISH_MASK           = 21;
const ACLF4_MIBC_BMASK          = 6;

The three POSIX-derived privilege bits together with indication of whether the file is bing accessed by its owner or by a member of the owning group for the set of privilege bits. Each such bits has a numeric value of the form ACLF4_MINP_* and a mask of the form ACLF4_MIFP_*, used when t is necessary to define subset of such privilege bits.¶

const ACLF4_MIFP_READ           = 0x00000001;
const ACLF4_MINP_READ           = 0;
const ACLF4_MIFP_WRITE          = 0x00000002;
const ACLF4_MINP_WRITE          = 1;
const ACLF4_MIFP_EXEC           = 0x00000004;
const ACLF4_MINP_EXEC           = 2;
const ACLF4_MIFP_OWNER          = 0x00000008;
const ACLF4_MINP_OWNER          = 3;
const ACLF4_MIFP_GROUP          = 0x00000010;
const ACLF4_MINP_GROUP          = 4;

The following basis sub-fields are defined. Together they are use to define the hierarchical structure of actions, their classification by mask ACE mask bits, and their derivation from specific privilege bits, included, but not limited to the three POSIX-derived permission bits, i.e. R, W, and X.¶

• The basis-type sub-field within ACLF4_MI*_BTYPE indicates the type of basis specfication applying to the mask bits specified wiithin the current entry.¶

  The value in this sub-field controls how and whether the other sub-fields are used.¶

• The basis-number sub-field within ACLF4_MI*_BNUMB indicates the specific higher-level (i.e coarser-grained) entity of which the sets of actions specfied by the assoated mask bits are a subset, not necessarily proper.¶

  This field can contain a mask bit number (i.e. the shift code of an CE mask bit) or a privilege bit number, in the form of one of the ACLF4_MINP_* constants.¶

• The basis-value sub-field within ACLF4_MI*_BVAL indicates a set of privilege bit values that control whether the action are to be considered allowed by default.¶

  The value is the or of a set of ACLF4_MINF_* constants which to be compared to the corresponding mask for the current request.¶

• The basis-mask sub-field within ACLF4_MI*_BMASK indicates a set of privilege bit values that are to be matched for exquality with the vlue in the basis-value sub-field in determining whether the actions associated with the ACE mask bits are to be considered allowed by default¶

  The value is the or of a set of ACLF4_MINF_* constants which to used as a mask to determine which bists of the basis-value sub-field are to compared tot the corresponding bits for the current request.¶

const ACLF4_MIBT_NONE           = 0;
const ACLF4_MIBT_PBIT           = 1;
const ACLF4_MIBT_AMBIT          = 2;
const ACLF4_MIBT_MCONE          = 3;
const ACLF4_MIBT_MCALL          = 4;

The above values, when appropriately left-shifted, can be used as value of the basis-type subfield:¶

• When the value ACLF4_MIBT_NONE is used, the actions covered by the mask bits specfied are treated as having no ancestor the hierarchy of action which can be authorized.¶

  As a result, there is no coarser-grained entity to use to control authorization if the specified bits are not supported¶

• When the value ACLF4_MIBT_PBIT is used, the specfied ACE mask bits are treated as the direct descendent of one of the five permission bits, either one of the three POSIX privilege bits of some ownership-related condition.¶

  In this case, the specific permission bit is identified by the value in the basis-number sub-field and all the other subfields fields may only have the value zero.¶

• When the value ACLF4_MIBT_AMBIT is used,the specfied ACE mask bits are treated as the direct descendent of one of other ACE mask bits.¶

  In this case, the specific ancestor ACE mask bit is identified by the value in the basis-number sub-field (in the form of a shift count)mand all the other subfields fields may only have the value zero.¶

  It is invlid for the ancestor relation to result in a loop when repeated.¶

• When the value ACLF4_MIBT_MCONE is used, the default for authorization of the associated actions is deermine by use of the basis-value and basis-mask subfields, each of which is a mask with one bit position for each of the possible priviliege bits derived from the mode and file ownership. The privilege mask for the current request and the basis-value subfield are compared resulting in a mask of the bit positions for which the two are equal. that mask is then anded with the bas-mask subfield and if any bits are on, the default status for authorization of the asssocited mask bits is allowded¶

• When the value ACLF4_MIBT_MCALL is used. , the default for authorization of the associated actions is deermine by use of the basis-value and basis-mask subfields, each of which is a mask with one bit position for each of the possible priviliege bits derived from the mode and file ownership. The privilege mask for the current request and the basis-value subfield are compared resulting in a mask of the bit positions for which the two are equal. that mask is then anded with the bas-mask subfield and if all the bits in the bsis-mask subfield are set bits are on, the default status for authorization of the asssocited mask bits is allowded.¶

5.2.8. ACE Mask Bit Support Inference

[Consensus Needed (Item #61X), through end of section}:¶

The inference that can be done to provide information about ACE mask bit support, in the absence of the Aclfeature attribute, depends on the ACL model determined on the basis of the set of supported ACE types. Given the inability of this method to deal with hybrids of the two models, the inferences that can be done, treat server that support the UNIX ACL model in one class, and all other in another class which includes servers that implement the NFSv4 ACL model as well as most hybrids in another.¶

In all cases, it can be assumed that the ACE mask bits defined in Section 5.2.3 are supported.¶

When it is determined that the UNIX ACL model is supported, the follow can be assumed:¶

• [Author Aside]: I'm pretty sure this paragraph is close to correct but we need information about clients to verify that, especially with regard to the handling of non-authorization ACL functions.¶

  All ACE mask bits defined in Section 5.2.4, need to be specified whenever ACE4_WRITE_DATA is specified. This applies to all ACE types. Mask bits that are associaed with unsupported features can be excluded. For example, ACE4_WRITE_NAMED_ATTRIBUTES does not need to be set on file system whch have no support for named attributes.¶

• [Author Aside]: It is hard to determine what to say about mask bits defined in Sections 5.2.5 and 5.2.6. What I have below is pretty much a guess and I expect it will have to be changed as more implementation information becomes available.¶

  For ACE mask bits defined in Sections 5.2.5, it is best to avoid using them in ACEs at all.¶

When the UNIX ACL model is not the one supported, i.e. for implementations of the NFSv4 ACL model or most hybrids, the following guidelines apply:¶

• Clients that only need support for the feature set provided by UNIX ACLs can behave just as they would for a server supporting the UNIX ACL model.¶

• Clients that need access to features that requie use of the finer-grained ACE mask bit structure are in an unfotunate position. Due to an earlier lack of attention to interoperability issues, there is no good way to obtain the necessary support information in minor versions zero and one.¶

  While it might make sense to test for support of individal ACE mask bits by setting ACEs with those mask bits and seeing if NFS4ERR_ATTRNOTSUPP is returned, this is not a viable approach even apart from the general difficulty of making uch checks when cossing into a file system. The normal problems with this sort of approach are magnfied by the need to check bit cominations in addition to single bits and the lack of clear direction in existing secification to return errors in such cass.¶

  As a reult, when the Aclfeature attribute is not present, clients have to rely on their knowledge of the server they are connected to, as they have been doing, with no prospect of interoperable support for these extensions.¶

5.2.9. ACE Mask Bit Extension

Standards-track docments which define NFSv4 protocol extensions, as provided for in [RFC8178], can extend the set of ACE mask bits. The definition of a new mask bit needs to provide the following information:¶

• The set of actions affected by the new mask bit.¶

• The name of the new mask bit together with a previously unused mask bit value.¶

• Information about the way that support (or not) for the new mask bit is to be determined.¶

• Information about how the actions affected by this bit are dealt with when this new bit is not fully supported.¶

  This includes situations in which this mask bit has to have the same state some other mask bit, i.e. it is a finer-grained variant of that other bit.¶

  In addition case in which the new bit is not a finer-grained variant of an existing bit need to be addressed by specifying a boolean combination of existing mask bits or of conditions such as being the owner of the fle or withinthe owning group of the file.¶

5.2.10. Handling of Deletion

[Author Aside]: This section, exclusive of subsections contains a proposal for the revision of the ACL-based handling of requests to delete directory entries. All unannotated material within it is to be considered part of consensus item #12a.¶

[Author Aside]: The associated previous treatment is to be found in Section 5.2.11¶

This section describes the handling requests of that involve deletion of a directory entry. It needs to be noted that:¶

• Modification or transfer of a directory, as happens in RENAME is not covered.¶

• The deletion of the file's data is dealt with separately sincee this action, like a truncation to length zero, requires only ACE4_WRITE_DATA.¶

• The use of ACE4_ADD_FILE, as opposed to ACE4_DELETE_CHILD, while suspicious is being retained at least until we have information about existing implementations.¶

• It is not clear how this all applies to deletions of subdirectories. This also need information about existing implementations before we close on Consensus Item #12.¶

In general, the recognition of such an operation for authorization/auditing/alarm depends on either of two bits mask bits being set: ACE4_MASK_DELETE on the file being deleted and ACE4_MASK_DELETE_CHILD on the directory from which the entry is being deleted.¶

In the case of authorization, the above applies even when one of the bits is allowed and the other is explicitly denied.¶

[Consensus Items, Including List (#6c, #12a): When neither of the mask bits is set, the result is normally negative. That is, permission is denied and no audit or alarm event is recognized. However, in the case of authorization, the server MAY make permission dependent on the setting of MODE4_SVTX, as follows:¶

• If that bit not set, allow the removal if and only if ACE4_ADD_FILE is permitted.¶

• If that bit is set, allow the removal if and only if ACE4_ADD_FILE is permitted and the requester is the owner of the target.¶

5.2.11. Handling of Deletion (Vestigial)

[Author Aside]: This section contains the former content of Section 5.2.10. All unannotated paragraphs within it are to be considered the Previous Treatment associated with consensus item #12b.¶

[Author Aside, Including List]: Listed below are some of the reasons that I have tried to replace the existing treatment rather than address the specific issues mentioned here and in later asides.¶

• The fact that there is no clear message about what servers are to do and about what behavior clients might rely rely on. This derives in turn from the use of "SHOULD" in contexts in which it is clearly not appropriate, combined with non-normative reports of what some systems do, and the statement that the approach suggested as a way of providing "something like traditional UNIX-like semantics".¶

• The complexity of the approach without any indication that there is a need for such complexity makes me doubtful that anything was actually implemented, especially since the text is so wishy-washy about the need for server implementation. The probability that it would be implemented so widely that clients might depend on it is even more remote.¶

• The fact that how audit and alarm issues are to be dealt with is not addressed at all.¶

• The fact that this treatment combines ACL data with mode bit information in a confused way without any consideration of the fact that the mode attribute had been OPTIONAL.¶

Two access mask bits govern the ability to delete a directory entry: ACE4_DELETE on the object itself (the "target") and ACE4_DELETE_CHILD on the containing directory (the "parent").¶

Many systems also take the "sticky bit" (MODE4_SVTX) on a directory to allow unlink only to a user that owns either the target or the parent; on some such systems the decision also depends on whether the target is writable.¶

Servers SHOULD allow unlink if either ACE4_DELETE is permitted on the target, or ACE4_DELETE_CHILD is permitted on the parent. (Note that this is true even if the parent or target explicitly denies one of these permissions.)¶

If the ACLs in question neither explicitly ALLOW nor DENY either of the above, and if MODE4_SVTX is not set on the parent, then the server SHOULD allow the removal if and only if ACE4_ADD_FILE is permitted. In the case where MODE4_SVTX is set, the server may also require the remover to own either the parent or the target, or may require the target to be writable.¶

This allows servers to support something close to traditional UNIX-like semantics, with ACE4_ADD_FILE taking the place of the write bit.¶

5.3.1. Details Regarding ACE Flag Bits

ACE4_FILE_INHERIT_ACE

Any non-directory file in any sub-directory will get this ACE inherited.¶

Support for this flag bit is OPTIONAL.¶

ACE4_DIRECTORY_INHERIT_ACE

Can be placed on a directory and indicates that this ACE is to be added to each new sub-directory created.¶

Support for this flag bit is OPTIONAL.¶

If this flag is set in an ACE in an NFSv4 ACL attribute to be set on a non-directory file system object, the operation attempting to set the ACL SHOULD fail with NFS4ERR_ATTRNOTSUPP.¶

[Author Aside (Items #13b, #4g)]: Since I am unable to guess what might by "valid resaons" to bypass the recommendation in the paragraph, keeping this as a residual "SHOULD" for now. This could change if it is determined that the recommendation was never bypassed in existing server implementations, or if a specfic valid reason to bypass the reommendation is found.¶

ACE4_NO_PROPAGATE_INHERIT_ACE

Can be placed on a directory. This flag tells the server that inheritance of this ACE is to stop at newly created child directories.¶

While Support for this flag bit is formally OPTIONAL, it has no use if ACE4_DIRECTORY_INHERIT_ACE is not supported and is REQUIRED if it is.¶

ACE4_INHERIT_ONLY_ACE

Can be placed on a directory but does not apply to the directory; ALLOW and DENY ACEs with this bit set do not affect access to the directory, and AUDIT and ALARM ACEs with this bit set do not trigger log or alarm events. Such ACEs only take effect once they are applied (with this bit cleared) to newly created files and directories as specified by the ACE4_FILE_INHERIT_ACE and ACE4_DIRECTORY_INHERIT_ACE flags.¶

If this flag is present on an ACE, but neither ACE4_DIRECTORY_INHERIT_ACE nor ACE4_FILE_INHERIT_ACE is present, then an operation attempting to set such an attribute SHOULD fail with NFS4ERR_ATTRNOTSUPP.¶

ACE4_SUCCESSFUL_ACCESS_ACE_FLAG and ACE4_FAILED_ACCESS_ACE_FLAG

The ACE4_SUCCESSFUL_ACCESS_ACE_FLAG (SUCCESS) and ACE4_FAILED_ACCESS_ACE_FLAG (FAILED) flag bits may be set only on ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and ACE4_SYSTEM_ALARM_ACE_TYPE (ALARM) ACE types. If during the processing of the file's NFSv4 ACL, the server encounters an AUDIT or ALARM ACE that matches the principal attempting the OPEN, the server notes that fact, and the presence, if any, of the SUCCESS and FAILED flags encountered in the AUDIT or ALARM ACE. Once the server completes the ACL processing, it then notes if the operation succeeded or failed. If the operation succeeded, and if the SUCCESS flag was set for a matching AUDIT or ALARM ACE, then the appropriate AUDIT or ALARM event occurs. If the operation failed, and if the FAILED flag was set for the matching AUDIT or ALARM ACE, then the appropriate AUDIT or ALARM event occurs. Either or both of the SUCCESS or FAILED can be set, but if neither is set, the AUDIT or ALARM ACE is not useful.¶

The previously described processing applies to ACCESS operations even when they return NFS4_OK. For the purposes of AUDIT and ALARM, we consider an ACCESS operation to be a "failure" if it fails to return a bit that was requested and supported.¶

ACE4_IDENTIFIER_GROUP

Indicates that the "who" refers to a GROUP as defined under UNIX or a GROUP ACCOUNT as defined under Windows. Clients and servers MUST ignore the ACE4_IDENTIFIER_GROUP flag on ACEs with a who value equal to one of the special identifiers outlined in Section 5.4.¶

Support for this flag bit is REQUIRED.¶

ACE4_INHERITED_ACE

Indicates that this ACE is inherited from a parent directory. A server that supports automatic inheritance will place this flag on any ACEs inherited from the parent directory when creating a new object. Client applications will use this to perform automatic inheritance. Clients and servers MUST clear this bit in the acl attribute; it may only be used in the dacl and sacl attributes.¶

5.3.2. ACE Flag Support Discovery

[Consensus Needed (Items #13c, #105k), Entire Section]:¶

Within the Aclfeature value, words of type af4flags are analyzed using the definitions below to determine the sets of flags which are supported or are storeable without necessarily being supported. In addition, information about the conformance of the flag support with recommmendations made in the specification is provided.¶

Bit fields within an af4flags value are defined at two levels:¶

• Individual flag bits are defined in a ten-bit level-of-flag-support field.¶

• The word is divided into multiple level-of-flag-support fields and additional flags.¶

Following are indivdual flags defined within eacg level-of-flag-support field.¶

const AF4FLAG_INHFILE           = 0x00000001;
const AF4FLAG_INDIR             = 0x00000002;
const AF4FLAG_INHCHOICE         = 0x00000004;
const AF4FLAG_INHAUTO           = 0x00000008;

Within a level-of-flag-support field, the followig bits are set or not as specified below. The values of any bits not specfically defined are to be zero.¶

• The flag AF4FLAG_INHFILE is set iff the flag ACE4_FILE_INHERIT_ACE is supported.¶

• The flag AF4FLAG_INDIR is set iff the flag ACE4_DIRECTORY_INHERIT_ACE is supported.¶

• The flag AF4FLAG_INHCHOICE is set iff the two flags ACE4_FILE_INHERIT_ACE and ACE4_DIRECTORY_INHERIT_ACE are supported independently making it possible for the choice as to whether inheitance applies to be made differently for differnt sorts of objects.¶

• The flag AF4FLAG_INHAUTO is set iff the flags related to the automatic inheritance inheritance. This applies to whichever of the dacl and sacl attributes that are supported. If neither of those attributes are supported the value of the flag is to be set to zero.¶

Defined below are te ovrall contents of words of type 4flags, which consists of one overall flag and three level-of-flag-support fields.¶

const AF4FLAG_UNDEF0            = 0x40000000;
const AF4FLAG_ASUPPMASK         = 0x000003ff;
const AF4FLAG_RSUPPMASK         = 0x000ffc00;
const AF4FLAG_STOREMASK         = 0x3ff00000;
const AF4FLAG_ASUPPSHIFT        = 0;
const AF4FLAG_RSUPPSHIFT        = 10;
const AF4FLAG_STORESHIFT        = 20;

The fields within an af4flags word consist of the four fields listed below. The three level-of-flag-support fields are each defined by a mask defining the portion of the word in which he field resides and a shift that specfies the number of bits the flss within the field are to left-shifted to be place within the af4flags word.¶

• The flag AF4FLAG_UNDEF0 is to be set if the server sets all bit within ACE flag feld tht are not defined by the protocol to be zero. The asssurance provided makes it possible to extend the function of the flags word, as described in Section 5.3.3¶

• The level-of-flag-support field specfied by AF4FLAG_ASUPPMASK and AF4FLAG_ASUPPSHIFT is used to determine which flag bits have any support at all, including cases where the support differs from the recommendations in Section 5.3.1¶

• The level-of-flag-support field specfied by AF4FLAG_RSUPPMASK and AF4FLAG_RSUPPSHIFT is used to determine which flag bits are supported as described in Section 5.3.1¶

• The level-of-flag-support field specfied by AF4FLAG_STOREMASK and AF4FLAG_STORESHIFT is used to determine which flag bits are accepted and stored in ACLs without necessarily implying they are actually supported by the server.¶

When the Aclfeature attribute is not suported, possibilities for support discovery are more limited and would depend on the ACL model inferred based on the set of ACE types supported.¶

• When use of the UNIX ACL model is inferred, the client can reasonably assume that no support for the inheritence- related flags exist and that modes are computed in the alternate fashion intended to support UNIX ACLs.¶

• In the unlikely event that there exist clients that depend on the UNIX ACL model in that they do not support ACEs of types other than ALLOW, while still needing some level of inheritence support or which depend on mode being computed by the server as desctibed in Section 8.3, the client can test for support as in other cases in which the server provides a hybrid of the two models, as discussed below.¶

• When use of the NFSv4 ACL model is inferred, the client has no information about potential support but it is very likely that support for inheritance-related ACL flags will be provided and that the mode will be computed by the server as desctibed in Section 8.3. In cases in which different support is provided by the server or in which the clients needs different support, client can test for support as in other cases in which the server provides a hybrid of the two models, as discussed below.¶

For clients whose needs are for features in which there is a discordance between what can be inferred from the set of ACE types supported and the actual support that the af4flags fields would indicate if Aclfeature were supported, the methods described below could be used to test for support of various feature. However, because of the difficulty of doing such tests when a file sytem is first referenced and the lack of clarity in existing specs as to feture discovery, it is likely that these methods would not be used. Instead, such clients, if they exist, would find out about support levels as they do now, by knowledge about particular depending on external knowledge about server choices, without support for interoperability involving other servers.¶

• Support for various flag could be determined by using those in ACLs to be set and seeing if NFS4ERR_ATTRNOTSUPP was returned.¶

  In addition to the complexity of this procefure, the existing specifications are not very direct about how on-support is to be commmunicated, even though that seems to be the intent.¶

• Determiining which of Sections 8.3 or 8.4 is to be used in computing mode value corresponding ACLs can only be done by setting ACLs and seeing which of the expected mode values is present.¶

  In addition to the inherent complexity of this proceure, interpretation of the results might by complicated by difficulties in handling reverse-slope modes derived from problems in the original specfications of thse matters.¶

The testing difficulties cited above is likely to result in their not being used for feature discovery, with real feature discovery work being deferred until Aclfeature is available. Nevertheless these tests are useful to provide information about specific server implemntations that can be used in future drafts of this document¶

5.3.3. ACE Flag Extension

[Consensus Needed (Item #13d), Entire Section]:¶

Although, in general, peviously unused bits within flags words such as the flag field within an ACE can easily be added in extensions, the way that the flag field within is defined creates unusual difficulties, since we cannot be sure that undefined bits in these words are always zero. As a consequence, the definition of additional flags must satisfy one the following constaints:¶

• Use of the extension needs to be conditioned on support for the Aclfeature attribute and the server setting the flag AF4FLAG_UNDEF0 in the af4flags word returned.¶

• Defninition of the extension has to occur in a future minor version that requires that unused bits in an ACE flag word always be sent not set.¶

Assuming the flag can be defined as discussed above are satisfactorily dealt with, definitions of new flags needs the following items to be specified:¶

• An XDR definition of the value of the flag assigning an used flag value to a synbol typically beginning with "ACE4_".¶

• A definition of what the flag indicates.¶

• Discussion of the pattern of use of the flag, including whether it is set by the client and used by the server, the reverse, or both.¶

• For flags set by the client and interpreted by the server, specification of a means by which the client can determine whether the flag is supported.¶

  This can take the form of a new bit with that purpose within the af4flags word, the support for or value returned by an OPTIONAL attribute, or other means that the client can easily determine whether support is present.¶

5.4.1. ACE Who Value Support Discovery

[Consensus Needed (Item #50b, #105l), for entire section]:¶

[Author Aside (Item #50b), to the end of the bulleted list]: Given that we have not yet encountered any implementations of these special values. When we complete our analysis of exising implementations, we might update this in varous ways:¶

• If it is the case that one or more of these special who values is never accepted, the group will need to consider whether it make sense to delete it now.¶

  While there is no time gap that, by itself, would justify unimplemented feature, the working group could reasonably conclude that the absence of implementation for multiple decades could consider that there is no real need for he feature.¶

• If an entire class of special who values (e.g. auth-related or miscellaneous) were never implementented, it would be possible streamline this section to delete it together with the flag bits in af4flags supporting its discovery¶

The special who values for which support discovery is needed are divided into two classes:¶

• The special values "AUTHENTICATED" and "ANONYMOUS" are referred to as "auth-related" special values.¶

• The special values NETWORK", "DIALUP", "INTERACTIVE", "BATCH", and "SERVICE" are referred to as "miscellaneous" pecial values.¶

Flags that provide support information regarding the server's handling of who values are defined within a word of type af4whoinf, which is available as part of the Aclfeature attribute, when that attribute is supported.¶

const AF4WHOI_AUTHSUPP          = 0x00000001;
const AF4WHOI_AUTHSUPPC         = 0x00000002;
const AF4WHOI_AUTHSTORE         = 0x00000004;
const AF4WHOI_MISCSUPPA         = 0x00000008;
const AF4WHOI_MISCSTORE         = 0x00000010;
const AF4WHOI_OTHMODE           = 0x00000020;

The flags whose xdr definition is presented above provide the necessary support information for the current filesystem. These flags' meanings are follows:¶

• AF4WHOI_AUTHSUPP indicates that the server provides support for the special who value "AUTHENTICATED" and "ANONYMOUS", although not necessarily with the definitions provided in Section 5.4.¶

  This bit is not to be set unless request issued using AUTH_NONE are selected (in the case of "ANONYMOUS) and excluded (in the case of "AUTHENTICATED") when these special values appear in the who field of an ACE.¶

• AF4WHOI_AUTHSUPPC indicates that the server provides support for the special who value "AUTHENTICATED" and "ANONYMOUS, using the definitions provided in Section 5.4.¶

• AF4WHOI_AUTHSTORE indicates that the server accepts ACEs with the two special who values "AUTHENTICATED" and "ANONYMOUS", without necessarily taking any action based on such ACEs other than to store them and return them as part of ACLs.¶

• AF4WHOI_MISCSUPPA indicates that the server accepts ACEs with the special who values identified as misccellaneous and makes some effort to classify requests on the basis of the request's provenance depending on the who value.¶

  There are no contraints regrding how the server makes these decisions¶

• AF4WHOI_MISCSTORE indicates that the server accepts ACEs with the special who values identified as misccellaneous while essentially ignoring such ACEs and not considering any request to match these who values.¶

  Such ACEs are stored abd returned as part of ACLs even though they are ever acted on as part of processing NFSv4 requests.¶

• AF4WHOI_OTHMODE indicates how the server computes the mode value to be set when changing the acl or dacl attributes. When set, it specifies that ALLOW ACEs using non-special who values denoting specific user or groups are to be included in the mode value computed (as applying to the "group" permissions) as specified in Section 8.4 rather than using the method specified in Section 8.3.¶

When the Aclfeature attribute is not suported, possibilities for support discovery are more limited and would depend on the ACL model inferred baesed on the set of ACE types supported.¶

• When use of the UNIX ACL model is inferred, the client can reasonably assume that no support for these special who values exists.¶

• In the unlikely event that there exist clients that depend on the UNIX ACL model in that they do not support ACEs of types other than ALLOW, while still needing support for special who values, thenn the client can test for support as it would in the next case.¶

  Such clients, if they exist, would, until support for Aclfeature is available get the needed support as they do now, by depending on exernal knowledge about server choices, without support for interoperability involving other servers.¶

• When use of the NFSv4 ACL model is inferred, the client has no information about potential support but can, if necessary determine whther ACEs with these special values are accepted by using them in ACLs containg ACEs with these special who values and seeing if NFS4ERR_BADOWNER results.¶

  In the case of auth-related special who values, requests with specfic security paramters could be tested to determine whether the use of those special values meets the client's needs.¶

  In the case of miscellaneous special who values, it would hard to use these values in ACEs and depending on their would remain as it has been, without support for interoperbility involving other servers.¶

5.4.2. ACE Who Value Extensiion

[Consensus Needed (Item #50c), for entire section]:¶

Because use of unknown who values is defined as returning NFS4ERR_BADOWNER, standard track documents defining extensions to extensible minor versions can define new special who values. Definitions of such new values need to include the following:¶

• The string(s) to serve with each together with an appended "@" as the new special who value. The specfication should be in term of the Unicode characters. If it is desired that case-insensitive or normalization-form-insensitive string matching is desired, then multiple strings should be specified rather than specifying the type of code- insensitivity desired.¶

• A description of how it is to be determined whether a given NFSv4 request matches the new special who value. In this context, "never", indicating such ACEs are to be ignored, is acceptable.¶

  How these affect handling of non-NFSv4 requests can be treated as out of scope.¶

• A description of how support for this new value is to be ascertained. This can take the form of the specification of the new value as auth-related, miscellaneous, or the idenification of a new bit within af4whoinf values that indicates whether support is present.¶

8.7.1. Setting Mode and not ACL (vestigial)

[Author Aside]: All unannotated paragraphs are to be considered the Previous treatment of Consensus Item #30b.¶

When any of the nine low-order mode bits are subject to change, either because the mode attribute was set or because the mode_set_masked attribute was set and the mask included one or more bits from the nine low-order mode bits, and no ACL attribute is explicitly set, the acl and dacl attributes must be modified in accordance with the updated value of those bits. This must happen even if the value of the low-order bits is the same after the mode is set as before.¶

Note that any AUDIT or ALARM ACEs (hence any ACEs in the sacl attribute) are unaffected by changes to the mode.¶

In cases in which the permissions bits are subject to change, the acl and dacl attributes MUST be modified such that the mode computed via the method in Section 8.3 yields the low-order nine bits (MODE4_R*, MODE4_W*, MODE4_X*) of the mode attribute as modified by the attribute change. The ACL attributes SHOULD also be modified such that:¶

1. If MODE4_RGRP is not set, entities explicitly listed in the ACL other than OWNER@ and EVERYONE@ SHOULD NOT be granted ACE4_READ_DATA.¶
2. If MODE4_WGRP is not set, entities explicitly listed in the ACL other than OWNER@ and EVERYONE@ SHOULD NOT be granted ACE4_WRITE_DATA or ACE4_APPEND_DATA.¶
3. If MODE4_XGRP is not set, entities explicitly listed in the ACL other than OWNER@ and EVERYONE@ SHOULD NOT be granted ACE4_EXECUTE.¶

Access mask bits other than those listed above, appearing in ALLOW ACEs, MAY also be disabled.¶

Note that ACEs with the flag ACE4_INHERIT_ONLY_ACE set do not affect the permissions of the ACL itself, nor do ACEs of the type AUDIT and ALARM. As such, it is desirable to leave these ACEs unmodified when modifying the ACL attributes.¶

Also note that the requirement may be met by discarding the acl and dacl, in favor of an ACL that represents the mode and only the mode. This is permitted, but it is preferable for a server to preserve as much of the ACL as possible without violating the above requirements. Discarding the ACL makes it effectively impossible for a file created with a mode attribute to inherit an ACL (see Section 8.11).¶

8.7.2. Setting Mode and not ACL (Discussion)

[Author Aside]: All unannotated paragraphs are to be considered Author Asides relating to Consensus Item #30c.¶

Existing documents are unclear about the changes to be made to an existing ACL when the nine low-order bits of the mode attribute are subject to modification using SETATTR.¶

A new treatment needs to apply to all minor versions. It will be necessary to specify that, for all minor versions, setting of the mode attribute, subjects the low-order nine bits to modification.¶

One important source of this lack of clarity is the following paragraph from Section 8.7.1, which we refer to later as the trivial-implementation-remark".¶

• Also note that the requirement may be met by discarding the acl and dacl, in favor of an ACL that represents the mode and only the mode. This is permitted, but it is preferable for a server to preserve as much of the ACL as possible without violating the above requirements. Discarding the ACL makes it effectively impossible for a file created with a mode attribute to inherit an ACL (see Section 8.11).¶

The only "requirement" which might be met by the procedure mentioned above is the text quoted below.¶

• In cases in which the permissions bits are subject to change, the acl and dacl attributes MUST be modified such that the mode computed via the method in Section 8.3 yields the low-order nine bits (MODE4_R*, MODE4_W*, MODE4_X*) of the mode attribute as modified by the attribute change.¶

While it is true that this requirement could be met by the specified treatment, this fact does not, in itself, affect the numerous recommendations that appear between the above requirement and the trivial-implementation-remark.¶

It may well be that there are are implementations that have treated the trivial-implementation-remark as essentially allowing them to essentially ignore all of those recommendations, resulting in a situation in which were treated as if it were a trivial-implementation-ok indication. How that issue will be dealt with in a replacement for Section 8.7.1 will be affected by the working group's examination of compatibility issues.¶

The following specific issues need to be addressed:¶

• Handling of inheritance.¶

  Beyond the possible issues that arise from the trivial-implementation-ok interpretation, the treatment in Section 8.7.1, by pointing specifically to existing INHERIT_ONLY ACEs obscures the corresponding need to convert ACE's that specify both inheritance and access permissions to be converted to INHERIT_ONLY ACEs.¶

• Reverse-slope modes¶

  The effect of ignoring this case is often so pervasive that the algoritms offered cnnot be patched to avoid the issue but neeed to be rethought.¶

• Named users and groups.¶

  The particular handling of these in computing mode, could conceivably affect other aspects of mode handling as well.¶

  We will need to consider the behavior of clients and servers to get a better handle on thse issues.¶

• The exact bounds of what within the ACL is covered by the low-order bits of the mode.¶

  A particular concern is the handling of ACE mask bits that are neither derived directly from a POSIX permission bit nor control a subset of the actions controlled by a POSIX permission bit. It is often assumed in previous specification that no such bits exist but that is not the case.¶

  We have wound up accomodting a large set of bits, but might need to revisit this issue if and when we decide to standardize the handling of mask bits that are not finer-grained version of one of the three POSIX permission bits.¶

It appears that for many of the issues, there are many possible readings of the existing specs, leading to the possibility of multiple inconsistent server behaviors. Furthermore, there are cases in which none of the possible behaviors described in existing specifications meets the needs.¶

As a result of these issues, the existing specifications do not provide a reliable basis for client-side implementations of the ACL feature which a Proposed Standard is normally expected to provide.¶

8.7.3. Setting Mode and not ACL (Proposed)

[Author Aside]: This proposed section is part of Consensus Item #30d and all unannotated paragraphs within it are to be considered part of that Item. Since the proposed text includes support for reverse-slope modes, treats all minor versions together and assumes decisions about handling of ACEs for named users and groups, the relevance of consensus items #26, #28, and #29 needs to be noted.¶

[Author Aside]: As with all such Consensus Items, it is expected that the eventual text in a published RFC might be substantially different based on working group discussion of client and server needs and possible compatibility issues. In this particular case, that divergence can be expected to be larger, because the author was forced to guess about compatibility issues and because earlier material, on which it is based left such a wide range of matters to the discretion of server implementers. It is the author's hope that, as the working group discusses matters, sufficient attention is placed on the need for client-side implementations to have reliable information about expected server-side actions.¶

[Author Aside, through end of bulleted list]: In this and subsequent sections I have tried to come up with overall recommendations that are as consistent with the previous treatment as I can come up with, as I have done in other areas. In this particular case, I have had more difficulty than in others since this is the existing text treatment is so unclear, making it hard to determine what hard-to- accomodate aspects are intentional. In particular, as the working group discusses this area and accommodate actual implementation, the following difficult issues will need to be focused on:¶

• The retention or not of ACEs using special who values. Some of the previous text suggests these are to be retained but I have specfied they are to be invalidated.¶

  In part, I am motivated by the fact that retaining these would force a wholesale rewriting of the ACL, even in those cases in which it can normally be avoided by using DENY ACEs to prevent file authorization scanning from proceding beyond the portion of the new ACE that is derived from the from the mode.¶

  Requiring that these be retained would partially erode the conrol of file authorization unless the ACL were rewritten to put these first, whic might have unforeseen effects.¶

• The statement in existing specfication about avoiding conflicts with the mode derived from the acl is not all that clear about which method is intended.¶

  I have stuck with Section 8.3 because I find the complexity of dealing with multiple methods of mode computation hard to deal with. When we have more information about implementations that use alternate methods of mode computation, we will have to look at this again, although we ight find that the context in which this is one (i.e. UNIX ACLs) simple enough that we could adapt while stll retaining our sanity.¶

• The handling of many of the ACE mask bits is not addressed, or is addressed in flawed way because of mistaken that new mask bits only change the granlarity of the set of action controlled and nothing else.¶

  We have tried to accommodate mask bits derivable from sets of mask bits or from file ownership. While the result seems to make sense, it might not do so once we look at detailed implentatio characeristics and try to standardize the mappings between mask bits and permission bits.¶

This section describes how ACLs are to be updated in response to actual or potential changes in the mode attribute, when the attributes needed by both of the file access authorization models are supported. It supersedes the discussions of the subject in [RFC7530] and [RFC8881], each of which appeared in Section 6.4.1.1 of the corresponding document.¶

Despite this supersession, it needs to be understood that previous implementations addressed the issues using relying often on now-superseded statements about the requirements to be satified and how these requrements might be met. In light of the existence of these implementations, in defining what would normally be requirements, we use the term "SHOULD" with the understanding that reliance on material in these earlier specifications is a valid reason to bypass the new recommendation.¶

It is necessary to approach the matter differently than in the past because:¶

• Organizational changes are necessary to address all minor versions together.¶

• Those previous discussions are often internally inconsistent leaving it unclear what specification-mandated actions are to be performed.¶

• In many cases, servers were granted an extraordinary degree of freedom to choose the action to take, either explicitly or via an apparently unmotivated use of "SHOULD", leaving it unclear what might be considered "valid" reasons to ignore the recommendation.¶

• There appears to have been no concern for the problems that clients and applications might encounter dealing ACLs in such an uncertain environment.¶

• Cases involving reverse-slope modes were not adequately addressed.¶

• The security-related effects of SVTX were not addressed.¶

While that earlier approach might have been consdered workable at the time, it made it difficult to devise client-side ACL implementations that incorporated the extensions within NFSv4 ACLs, even if there had been any interest in doing so. In order to enable this situation to eventually be rectified, we will define the preferred implementation here, but in order to provide temporary compatibility with existing implementations based on reasonable interpretations of [RFC7530] [RFC8881]. To enable such compatibility the term "SHOULD" will be used, with the understanding that valid reasons to bypass the recommendation, are limited to implementers' previous reliance on these earlier specifications and the difficulty of changing them now.¶

When the recommendation is bypassed in this way, it is necessary to understand, that, until the divergence is rectified, or the client is given a way to determine the detail of the server's non-standard behavior, client-side implementations may find it difficult to implement a client-side implementation that correctly interoperates with existing servers that based their implementations on various pieces of the existing text, now superseded.¶

The fundamental requirement that needs to be addressed is that when mode bits involved in determining file access authorization are subject to modification, the server MUST, when ACL-related attributes have been set, modify the associated ACEs so as not to conflict with the new value of the mode attribute.¶

The occasions to which this requirement applies, vary with the attribute being set and the type of object being dealt with:¶

• For all minor versions, any change to the mode attribute, triggers this requirement¶

• When the set_mode_masked attribute is being set on an object which is not a directory, whether this requirement is triggered depends on whether any of the nine low-order bits of the mode is included in the mask.¶

• When the set_mode_masked attribute is being set on a directory, whether this requirement is triggered depends on whether any of the nine low-order bits of the mode or the SVTX bit is included in the mask of bit whose values are to be set.¶

When the requirement is triggered, ACLs need to be updated to be consistent with the new mode attribute. The necessary action depends on specific of the ACEs involved.¶

• In the case of AUDIT and ALARM ACEs, which are used outside of file access authorization, no change needs to be made.¶

• For ALLOW and DENY ACEs, which are marked as inherit-only, no change needs to be made since such ACEs have no effect on file accces authorization for the current file.¶

• For ALLOW and DENY ACEs, which are marked as providing ACE inheritance without being marked as inherit-only, the effect of these ACEs on inheritance needs to be retained while their direct effect on file access authorization needs to be disabled.¶

  This can be effected by modifying the ACE to be inherit-only or ensuring that such ACEs are never reached when scanning an ACL for file access authorization. For eaxample, a DENY ACE for EVERYONE@ early in the ACL would have this effect¶

• The handling of remaining ACEs with a who-value of OWNER@, GROUP@, or EVERYONE@ needs to be adapted to the new mode.¶

  This could take the form of rewriting them in place or or of generating new ACEs at the start of the ACL.¶

• The effect on file authorizaion of remaining ACEs whose who-value is a named user needs to be avoided.¶

  This can be accmplished by rewriting the ACL, eliminating such ACEs or by or ensuring that such ACEs are never reached when scanning an ACL for file access authorization. For eaxample, a DENY ACE for EVERYONE@ early in the ACL would have this effect.¶

• The effect on file authorization of ACEs whose who-value is one of the other special values defined in Section 5.4 are to be left unmodified.¶

  This can be accmplished by rewriting the ACL, eliminating such ACEs or by or ensuring that such ACEs are never reached when scanning an ACL for file access authorization. For eaxample, a DENY ACE for EVERYONE@ early in the ACL would have this effect.¶

How these needs are best effected depends on the ACL model implemented. Of particular importance is the existence of DENY ACEs which allow one to force scanning for file access to be stopped at some point while retaining later ACEs to be retained without any possibility that they will affect file access authorization. We discuss three classes of ACl implementations as discussed below.¶

• For implementation of NFSv4 ACLs and hybrids thatcontain support for DENY ACEs, implememtation suggestions appearing in Section 8.7.5 are provided.¶

• For implementation of UNIX ACL, implememtation c suggestions appearing in Section 8.7.4 are provided.¶

• For implementation of various bybrid ACLs that do not provide support for DENY ACEs, implememtation suggestions appearing in Section 8.7.6 are provided.¶

All of the abovementioned suggestions share common logic regarding the formation of ACE masks used and how the mode bits are mapped ACE mask designating allowed actions:¶

The set of ACE mask bits to be dealt with includes all of the mask bits defined in Section 5.2 that are supported by server ACL implementations.¶

[Author Aside]: Although the definintion above include ACE4_WRITE_RETENTION and ACE4_WRITE_RETENTION_HOLD, we have not yet determined how to arrive these values. If we ever find an implementation of these, we will base that determination on that implemention. See below.¶

The subsets of those mask bit to be allowed to the owning user (OWNER@), members of the owning group (GROUP@) and EVERYONE@ are determined as follows:¶

• For GROUP@ and EVERONE@, the appropriate set of three permission is mapped, as described below, to a corresponding set of allowed mask bits.¶

• For OWNER@, that same mapping is applied using the owner permission but the resulting mask supplemented by adding, as allowed mask bits, mask bits defiing action normally allowed to the owner of the file rather than depending on the setting of particular permission bits.¶

  These include the ACE mask bits ACE4_WRITE_ATTRIBUTES, ACE4_WRITE_ACL, and ACE4_WRITE_OWNER,¶

For each set of three permission bits the corresponding set of allowed ACE mask bits is defined as follows:¶

• For mask bits defined in Section 5.2.3, each of the three permission bits is mapped to the coreesponding ACE mask bits. Although the names of those bit might be different depending on whether the object is a directory or not, the same mapping is used for all object types.¶

• For mask bits defined in Section 5.2.4, they are included or not depending on setting of the write permission bit. Note that the set of mask bits is different for directories and for non-directory objects.¶

• [Author Aside]: The following is a resonable guess but we need implementation information to be confident about it.¶

  The mask bit ACE4_READ_ATTRIBUTES is to be set unconditionally.¶

• [Author Aside]: The following what should happen but we need implementation information to be confident about it.¶

  The mask bit ACE4_READ_NAMED_ATTRIBUTES is to be set iff the read permission bit or the execute permission bit is set.¶

• [Author Aside]: The following is based on the only i mplementation tht we have locked but we need more implementation information to be confident about it.¶

  The mask bit ACE4_SYNCHRONIZE is to be set iff any of the three permission bits is set.¶

• [Author Aside]: The mask bits ACE4_WRITE_RETENTION and ACE4_WRITE_REYENTION_HOLD do not have any treatment specified above. In the event that these are retained, we will need to address that most probablt based on what is done by existing implementations which support these. That could be easily dealt with if these are to be controlled, in the absence of ACL support by ownership combined with some set of privilege bits. If, on the other hand, allowing these actions depends on some privilge outsode of the scope the, it might make sense to exclude them from treatment when a mode is set.¶

8.7.4. Setting Mode and not ACL in the Unix ACL Case (Proposed)

[Author Aside]: This proposed section is part of Consensus Item #30e and all unannotated paragraphs within it are to be considered part of that Item. Since the proposed text includes support for reverse-slope modes, treats all minor versions together and assumes decisions about handling of ACEs for named users and groups, the relevance of consensus items #26, #28, and #29 needs to be noted.¶

[Author Aside]: The inability of ACLs without DENY ACEs to present certain modes in a newly discovered issue and a troublesome one which will need extensive working group discussion. This issue applies to Section 8.7.6 as well. It appears that this issue is not fixable before NFSv4.2 but that it could be addressed by defining OTHERS@ and GROUPEXCEPTOWNER@ as NFSv4.2 extensioniions.¶

When UNIX ACLs are implemented, the absence of support for DENY ACEs forces the ACL to be rewritten in its entirety, rather than have a mode-related section prepended to a mostly unchanged ACL. In addition, the absence of support for DENY ACEs requires special attention to the possible presence of reverse slope mode becase OWNER@ is a subset of GROUP@ and both OWNER@ and GROUP@ are subsets of EVERYONE@.¶

It should be noted however, that the complexity of the rewriting process is reduced because of features not part of the UNIX ACL model:¶

• The absence of support for ACEs other than ALLOW means only a single ACE type neeeds to be dealt with.¶

• The absence of ACE inheritance means that ACEs marked to be inherited or inherit-oly, do not exist.¶

• The absence of support for ACEs with OPTIONAL secial who allow thes to be ignoed as well.¶

The replacement ACL begins with three ALLOW ACEs for the who values OWNER@, GROUP@, and EVERYONE@. The order in which these are placed in te resultant ACL needs to be adjusted based on the mode value avoid prolems with reverse-slope modes. Such problems can arise when a who value processed later contains permission bits not present in previous one so that the later who value, covering a superset of the principals of the earlier one, receives permissions that should not, for eaxmple, be granted to the owning user according to the POSIX definition of privileges for the owning group¶

In order to address this issue the three entries need to be sorted in order of descending privilege, using the incluson relationship for the privilege bits of each one.¶

It is possible that twp entries will have privilege sets not orderable by inclusion, i.e., neither is a subset of the other. Given the absence of DENY ACEs, the resulting permissions cannot be representing by an ACL, so that the ACL needs to be deleted in this case.¶

These preliminary ACEs are followed by a series of ACEs derived from the existing ACL with entries copied over or not as described below:¶

• ACEs with who value of OWNER@, GROUP@, or EVERYONE@ are not copied over.¶

• ACEs with other who values are copied to the ACL, unmodified.¶

8.7.5. Setting Mode and not ACL in the NFSv4 ACL Case (Proposed)

[Author Aside]: This proposed section is part of Consensus Item #30f and all unannotated paragraphs within it are to be considered part of that Item. Since the proposed text includes support for reverse-slope modes, treats all minor versions together and assumes decisions about handling of ACEs for named users and groups, the relevance of consensus items #26, #28, and #29 needs to be noted.¶

This covers in addition to NFSv4 ACLs per se, all cases in which support for DENY ACEs is present. The availability of support for DENY ACEs affects the generation of a new ACL as follows:¶

• Reverse slope modes do not force a re-ordering of the initial ACEs. To avoid this, each initial ALLOW ACE is paired with a corresponding DENY ACE¶

• Detailed analysis of the existing ACEs is not necessary since the new ACL will prevent those from ever being referenced in connection with file access authorization. This allows the existing ACL to be appended to the three initial ACE pairs.¶

The replacement ACL begins with three pairs oACEs for the who values OWNER@, GROUP@, and EVERYONE@. Each pair consists of an ALLOW ACE for that who value followed by a corresponding DENY ACE with the same who value. The ACE mask for the ALLOW ACE is derived from the corresonding permission bits as described above. The mask for the DENY ACE is the set of mode-related mask bits with the allows mask bits turned off.¶

These preliminary ACEs are followed by copies of the ACEs within the existing ACL. It is possible, although not necessary, to eliminate, as part of this copy, all ALLOW and DENY ACEs with who values of OWNER@, GROUP@, and EVERYONE@.¶

8.7.6. Setting Mode and not ACL in Certain Hybrid ACL Cases (Proposed)

[Author Aside]: This proposed section is part of Consensus Item #30g and all unannotated paragraphs within it are to be considered part of that Item. Since the proposed text includes support for reverse-slope modes, treats all minor versions together and assumes decisions about handling of ACEs for named users and groups, the relevance of consensus items #26, #28, and #29 needs to be noted.¶

This section covers ACL implementations that do not have support for DENY ACEs. In such cases, the absence of support for DENY ACEs forces the ACL to be rewritten in its entirety, rather than have a mode-related section prepended to a mostly unchanged ACL. In addition, the absence of support for DENY ACEs requires special attention to the possible presence of reverse slope modes becase OWNER@ is a subset of GROUP@ and both OWNER@ and GROUP@ are subsets of EVERYONE@.¶

The replacement ACL begins with three ALLOW ACEs for the who values OWNER@, GROUP@, and EVERYONE@. The order in which these are placed in te resultant ACL needs to be adjusted based on the mode value avoid problems with reverse-slope modes. Such problems can arise when a who value processed later contains permission bits not present in previous one so that the later who value, covering a superset of the principals of the earlier one, receives permissions that should not, for eaxmple, be granted to the owning user according to the POSIX definition of privileges for the owning group¶

In order to address this issue the three entries need to be sorted in order of descending privilege, as described in Section 8.7.4. As in that case the existence of sets of privilege bits not coprable according to inclusions migh force the ACL to be deleted, rather than being replaced by an ACl equivalent to the mode, which in this case cannot exist.¶

These preliminary ACEs are followed by a series of ACEs derived from the existing ACL with entries copied over or not as described below:¶

• AUDIT and ALARMS ACEs are copied over.¶

• ALLOW and DENY ACEs that are marked inherit-only are copied over.¶

• ALLOW and DENY ACEs that are marked as inheritable without being inherit-only are copied over in a modified form. They need to be marked as inherit only.¶

• Other ALLOW and DENY ACEs are not copied ober. This applies irrespective of the who value, although the reasons for doing this are different for different sorts of who values.¶

  ACEs with who values of OWNER@, GROUP@, and EVERYONE@ are to be eliminated because they are dealt with in the prepended ACEs.¶

  ACEs with a who value denoting a specfic user or group are to be eliminated because their presence is incompatable with the POSIX file access authorization model.¶

  ACEs with a special who value (auth-related or miscellaneous) are to be eliminated in order to assue that the file access authorization after settig the mode reflects the mode alone.¶