ACLs within the NFSv4 Protocols

ACLs within the NFSv4 Protocols NetApp

201 Jones Road, Suite 16 Waltham MA 02451 United States of America +1-781-572-8038 davenoveck@gmail.com

Transport NFSv4 example This document describes the structure of NFSv4 ACLs and their role in the NFSv4 security architecture. While the focus of this document is on the role of ACLs in providing a more flexible approach to file access authorization than is made available by the POSIX-derived authorization-related attributes, the potential provision of other security-related functionality is covered as well. While the goals of the description are similar to that used in previous specifications, the approach taken is substantally different, in that the relationship of the multiple ACL models supported has changed. A core set of functionality, derived form the the now-withdrawn POSIX draft ACLs is presented as the conceptual base of the feature set. Additional features used to provide the functionality within the NFSv4 ACL model are presented as OPTIONAL extensions to that core. The current version of the document is intended, in large part, to result in working group discussion regarding repairing problems with previous specifications of ACL-related features and to enable work to provide a greater degree of interoperability than has been available heretofore. The drafts a framework for addressing these issues and obtaining working group consensus regarding necessary changes. When the resulting document is eventually published as an RFC, it will supersede the descriptions of ACL structure and semantics appearing in existing minor version specification documents for NFSv4.0 and NFSv4.1, thereby updating RFC7530 and RFC8881.

Introduction This document describes the ACL-related features of the NFsv4 protocol, all of which are accessed through the use of a set of OPTIONAL attributes described in . These attributes provide:

Additional means of specifying file access authorization constraints that are more flexible than those provided by the authorization model inherited from POSIX, based on the attributes mode, owner, and owner_group.
A number of security-related facilities separate from authorization that use ACLs to identify sets of actions that might be subject to various forms of monitoring as described in .

Relationship to the Overall Security Document This document is best understood when it is read together with which dicusses security features provided that are not connected with ACLs, and which is a complete description in cases in which the OPTIONAL ACL-related attributes are not implemented. In many cases, the overall security document will have abbreviated descriptions that serve as an introduction to material in this document and reference sections within this document. Similarly, there will be occasions where it is necessary for this document to reference general features of NFSv4 security documented in . For the most part, these two documents are indepenendent, except for the inter-document references discussed above. However, the following execptions should be noted:

Section 1 of , in its entirety, applies to both documents, even in the absence of explicit inter-document references.
The terminology defined in Section 4.1 of can be used in either document, without an explcit inter-document reference.
The sections dealing with Security Considerations and IANA Considerations appearing in , i.e., Sections 18 and 19 of that document apply to the security-related changes being made in the current update as a whole, i.e., to both documents.
Appendix A of , in describing the security-related changes made from previous specifications, includes changes made in both this document and the overall security document.
The Appendices devoted to tracking Consensus Items, i.e., Appendix A of this document and Apppendex B of , need to be considered together, even though each appendix applies only to the document in which it appears. This is because there are related consensus items in the several documents whose resolution might affect one another, including some that result from consensus items affecting material now in muliple documents.

Dealing with the Previous Uncertinty regading ACL Semantics In the case of ACLs, previous specifications have left us with a difficult situation that now needs to be resolved. Inevitably, this will involve changing exxisting text while trying to avoid compatibility issues. In this particular case, instead of having a small set of individual mistakes which can now be recognized as such, we need to address a complex set of issues together. We now have a situation in which the existing specifications have created an unacceptable interoperability situation in relation to ACL implementations. Existing specifications have not paid proper attention to the need to make decisions in the face of disagreements regarding proper server behavior and have in various ways avoided the need to compromise and reach a reasonable consensus but instead have made it the job of the specifications to consider valid any remotely similar server implementations as valid, leaving clients little that they could do other than to accept a wide range of server behavior as valid, simply because it was chosen by some particular server. The working group did not provide any definition of a restricted level of ACL support that Unix servers could provide and that would address the needs of Unix clients. Instead, the only definition of ACL support was one that met the needs of Windows clients while providing a large set of facilities that did not fit within ACL needs of Unix systems, not all of of which were expected to be implemented by UNIX systems. As it became clear that considerable pieces of the ACL functionality were only of value to Windows clients and were difficult to provide on Unix servers, the working group declined to draw that line but instead haphazardly opened the spec to a wide variety of possible server behaviors by the following methods:

Essentially made each ACL mask bit its own optional feature with each server free to choose to implement that bit or not. Unfortunately, unlike most cases in which an optional feature is provided for, there was no means for the client to find out whether the server provided support a for particular mask bit or, if it did not, how it was to deal with authorizations normally controlled by the unsupportd mask bit.
Similarly, all ACL flags were essentially made optional. This was done, as in the case above, without using the terms "OPTIONAL" or "MAY" which might have suggested the need to provide a means for clients to find out about the choices that servers were allowed to make.
Used "SHOULD" in situations in which it was not clear why the term was used or was it possible to determine what might be considered valid reasons to bypass the recommendation. Since clients have no means to find out whether these unspecified reasons apply, they find themselves in a position similar the one that would exist if "MAY" were used. Again a range of server behavior was allowed without any analysis of the question of whether allowing such variability was necessary, its effect on client interoperability, or how the client might find out about the server's choices.
While building many aspects of the interactions of the mode attribute and ACLs around a mapping from ACLs to modes, the existing specifications allowed at least two different such mappings to be used, creating a difficult interoperability situation for clients. The preferred mapping is introduced using "SHOULD", again being unclear about possible reasons to bypass the recommendation, if that is what it is. It is sometimes stated that the use of "SHOULD" is "intentional", leaving one to wonder how to deal with the presumably unintentional other uses of "SHOULD". Although, it is claimed that the intention was "to avoid invalidating existing implementations that compute the mode according to the withdrawn POSIX ACL draft (1003.1e draft 17)", it is unclear how this choice relates to the working group's decision to base NFSv4 ACL on Windows ACLs rather than on the withdrawn POSIX draft ACLs. It is possible that there were different opinions on the proper mapping and that, instead of resolving the issue, the working group avoided the need to resolve this disagreement, by simply allowing both methods, ignoring the effect on interoperability. The effect of "invalidating " such implementations would be to make it clear that they are implementations of a different sort of ACL, rather then of the NFSv4 ACL model, adopted by the working group. Instead, the specification allowed these implementations as well as many possible hybrids of both models. A case can be made that clients, who often support only ACL-related APIs based on the Unix ACL model are entitled to matching ACL support, but the hybrid approach adopted makes no provision for client choice and does not even allow the client to find out the characteristics of the particular hybrid implementation, chosen by the server.
The updating of ACLs in response to changes in the mode attribute is another area in which previous specifications have chosen, for reasons which remain unclear, to allow a wide range of server behavior. Only a single part of the necessary ACL change is clearly specified as compliant with the spec. On the other hand, use of this approach is discouraged using non-normative terms

The combination of all the above has created a difficult interoperability situation. While it is often noted that clients are working in this environment, without complaining about the situation, we have to understand the reasons why this might be so:

Unix clients have good reason to stay away from ACLs that use features, such as ACLs defining extend-only files, or ACLs whose set of users with permission to modify ACLs is different from the single owning user. This leaves them no occasion to discover that the handling of these is not clearly specified. Some clients have ACL-related APIs (e.g. those appropriate to UNIX ACLs) while for clients that have APIs oriented to NFSv4 ACLs, any incompatibilities will be perceived by the applications, leading to a situation in which problems cannot be brought to the attention on the working group in any context in which a reasonably prompt resolution can be expected.
By discouraging direct client access to the ACLs, the need for clear specification of ACL semantics was obviated to a degree. On the other hand, clients were given no corresponding way to avoid clear specification of ACL semantics when deciding on the ACL to effect a given pattern of authorization for a file.
There has been no interoperability testing of this feature.
There are very low expectations in the ACL support area, as a result of choices made and not made decades ago.

Given the importance of security, this unfortunate situation cannot be allowed to persist indefinitely even if it might not be possible to fully resolve it for some existing minor versions. For a discussion of how we intend to improve the situation, both for earlier unchangeable minor versions and others, see .

Changes to the Description of ACLs in this Document This document has the same goals as previous descriptions of ACLs in earlier specifications and earlier drafts of the security document , in that it seeks to support two different ACL modela and reasonable hybrid of the two. Previously the NFSv4 ACL model had been presented as canonical, while the inability of many servers to provide such support was dealt with by a pervasive laxness about descriptions of the intended semantics. This laxness included the following unfortunate elements, which have been removed:

In many cases, it was suggested that the fact that servers behave in a particular way necessarily implies that clients have to accept this behavior. These have all been removed.
In many cases, "SHOULD" was used used without any clear indications of valid reasons to ignore a recommendation. In such cases "MAY" or an equivalent is desirable but, to avoid existing implementtions being retrospectively defined as non-compliant, we continue to use "SHOULD" with the clear understanding that reliance on Proposed Standards (even those subsequently obsoleted) is valid reason to bypass the recommendation in such cases.
Eliminate, to the degree possible, situation in which, multiple behaviors are allowed, with no clear understanding why allowing such freedom is needed.

This approach did not give clients any way to determine which ACL model was supported by a given server, sharply limiting the actual value of the additional elements added to UNIX ACLs to establish the semantics of full NFSv4 ACLs. The ways in which the current description differs frompevious ones are as follows:

The way in which alternatives are presented has been revised is described in . This change in the description framework is useful for all minor versions.
The changed framework provides a basis for limiting permissible hybrids as described in . This limitation will use knowledge of existing implementations to limit acceptable hybrids to those which actually implemented or otherwise need to be accommodated. The effect may be different for different minor versions but is expected to provide significant clarifiction for all.
We describe reliable means by which the client can determine which ACL model is spported or the nature of the hybrid support provided as decribed in .

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 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.

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 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 , as we find out whether the lack of deails in existing specfications resulted in substantally different implementations.

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.

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 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.

Requirements Language

Keyword Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as specified in BCP 14 when, and only when, they appear in all capitals, as shown here.

Special Considerations Because this document needs to revise previous treatments of its subject, it will need to cite previous treatments of issues that now need to be dealt with in a different way. This will take the form of quotations from documents whose treatment of the subject is being obsoleted, most often direct but sometimes indirect as well. Paragraphs headed "[Previous Treatment] or otherwise annotated as having that status, as described in Section 1 of , can be considered quotations in this context. Such treatments in quotations will involve use of these BCP14-defined terms in two noteworthy ways:

The term may have been used inappropriately (i.e not in accord with ), as has been the case for the "RECOMMENDED" attributes, which are in fact OPTIONAL. In such cases, the surrounding text will make clear that the quoted text does not have a normative effect.
The term may been used in accord with , although the resulting normative statement is now felt to be inappropriate. In such cases, the surrounding text will need to make clear that the text quoted is no longer to be considered normative, often by providing new text that conflicts with the quoted, previously normative, text.

Use of the Term "SHOULD [Consensus Needed (Item #4a), Through end of Section]: The use of the BCP14-defined term "SHOULD" merits particular attention beause of its mistaken common use in earlier discussions of matters addressed in this document and because of its central role in defining interoperability for client and server implementations. In particular, we will use the BCP14-defined term "SHOULD" in order to designate recommended implementation characteritics without retrospectively defining existing implementations as non-compliant. In previous treatments of ACLs this term was used extensively in contexts in which it was not made clear what might be valid reasons to bypass the implied recommendation, as required by .

In some cases, specific uses of the term were described as "intentional", with the apparent implication that the reasone for the use of this term was to allow implementations to ignore the recommended ation simply bcause it was felt to be inconvenient. The effect was that such uses of "SHOULD" were intepreted as "MAY" with the added expectation that implemtations bypassing the recommendation should be expected. This left uncertain the question of how an "unintentional" use should be interpreted but it made quite clear that this term was not being used in accordance with BCP14.
The majority of uses of this term, presumably unintentional ones, do not seem to be in accord with either in that it is not made clear what might be valid reasons to bypass the recommendation. The only conclusion that can be reached at this point is that the author felt that there might be valid reasons to bypass the recommendation but was unsure if any existed. However, it appears likely that, in most cases the threshhold for considering a reason valid in this context were quite low, most likely because it was often assumed that the possible existence of existing software components (e.g. file systems designed without regard to NFSv4's needs) which made it difficult ro conform to the recommendation would sonstiute a valid reason to bypass the recommendation, the feect on feature interoprability notwithstaning.

As might be expected, this pattern and other cases of excessive deference to server implementation choices created a difficult interoperability situation, which it is now the job of the working group to correct. As part of doing so, we will, as was done in the companion security document , when using "SHOULD" without reference to specific valid reasons to bypass the recommendation, the understanding is that, in this context, reliance on an earlier specification which allowed behavior now recommended against is a valid reason to continue to behave in that manner even if the allowance was communicated through the mistaken use of RFC2119-define keywords, Also, with regard to such residual uses of "SHOULD", it needs to be understood that:

With regard to new server implementations, there are no furtther valid reasons to bypass the recommndation unless those are explicitly mentioned.
That when reporting implementation characterisics (e.g. by use of the Aclfeature attribute) the right to bypass a recommendation is not to be accepted does not allow an implementer to report the recommendation as adhered to.
That clients are under an obligation to accept such variances from these recommendations and MAY, as the implementors judge prudent, to not use the ACL feature or to restrict its use to avoid reliance on particular troublesome instance of recommendations being bypassed.

ACL-based Authorization-related Attributes [Author Aside: (Items #14a, #15a... ), Applies to entire top-level section]: The treatment of the various ACL-based attributes in the included subsections replaces the corresponding sections in earlier documents, in which the attribute descriptions were not consolidated in one place and were disbursed among a number of top-level sections. Where it has been necessary to make significant changes, the annotations for those changes, including author asides and proposed text, appear here while vestigial text that is now superseded has not been brought forward. The per-object attributes Acl, Dacl, and Sacl all contain an ACL object as described in Sections and and their subsections.

Definition to Support ACL-related attributes The definition of the acemask4, which appears immediately below, needs to be done earlier than others since it is used directly in the definition of ACL-related attributes as well as within the definition of the ACE structure in . typedef uint32_t acemask4; The definition of the individual bits within these mask words appears in

Table of ACL-related Attributes The following table summarizess all the ACL-related attributes, including:

Attributes to support ACL-based authentication: Acl, Dacl.
Attributes to provide other security-related services: Sacl.
Attributes to provide information regarding the level of ACL support provided: Aclfeature, Aclsupport.

Name	Id	Ver	Data Type	Acc
Acl	12	4.0	nfsace4<>	R W
Aclfeature	[TBD-ACLF]	4.2x	nfsaclf4	R
Aclsupport	13	4.0	uint32_t	R
Dacl	58	4.1	nfsacl41	R W
Sacl	59	4.1	nfsacl41	R W

Types of ACLs The ACL allows authorization schemes outside those conforming to the POSIX approach to be specified and applied to file objects. This provides additional flexibility in a number of ways:

There may be multiple users or sets of users assigned different privileges to address cases in which the appropriate privilege assignments do not conform to the POSIX model in that they are different for users in the same group or different for two groups outside the owning group. ACLs support this additional flexibility by allowing an array of Access Control Entries, each of which specifies handling for a user or user group.
For partcular users or sets of users, the set of operations to be allowed might not be expressible using the three bits provided by POSIX as supplemented by special privileges for operations reserved to file owner.

NFSv4 ACLs, as described in , addresss both issues by defining, within the Access Control Entry, a large set of distinct privilege bits, modeled on those provided by Windows ACLs. ACLs based on the withdrawn POSIX ACL draft, (i.e. UNIX ACLs) make a more limited change to the POSIX authorization model and are represented by the same sorts of structures as NFSv4 ACLs, altough there are restrictions imposed by the UNIX ACL model. Although these two have some common goals and are prsented in a common XDR framwork, they are substantially different, in that:

The draft POSIX ACLs address only the first of the motivations for extension, while the NFSv4 ACL model is intended to address both of them, by defining a large range of bits in the ACE mask, rather than the three POSIX bits.
NFSv4 ACLs, by supporting DENY entries allow specfic privileges to be allowed for most members of a group and be denied to some particular users.
NFSv4 ACLs provide additional security-related facilities in addition to authorization control, through the use of AUDIT and alarm ACEs.

{Author Aside (Item #61a)]: In order to justify an eventual shift of the Acl and Dacl attributes back to be truly OPTIONAL, it is necessary to define for each file system, the type of ACL semantics provided, using information such as that provided by the Aclsupport attribute. In so doing, we will have to make provision for various hybrids if such implementations actually exist, while not necessarily seeking to preserve the ability to generate other such potential hybrids, in all cases. [Consensus Needed, Including List (Item #61a)]: The determination of the type of ACL semantics proceeds as follows:

If the aclsupport attribute indicates that either AUDIT or ALARM ACEs are supported, then it can be assumed that, in general, NFSv4 ACL semantics are provided, although some OPTIONAL ACE mask might not supported.
If the Aclsupport attribute is not supported, then if the Sacl attribute is supported then it also can be assumed, as above, that NFSv4 ACL semantics are provided.
Otherwise, If the Aclsupport attribute is not supported then the presence of support for DENY ACEs determines whether support for NFSv4 ACL semantics is provided. However, it is required that clients determine whether support for DENY ACEs is provide by attenpting to set ACLs ontaining such ACEs
In the case in which neither the aclspport attribute nor the SACL attribute is supported, then it can also be assumed that support for NFSv4 ACL semantics is provided. As a conequence, server implementations providing support for UNIX ACLs only, need to support the aclsupport attribute. This is because, if they do not, the client could legitamately assume that support for the NFSv4 ACL model in present.

The Acl Attribute (v4.0) This per-object attribute consists of an array of Access Control Entries which apply to operations performed on the current object, controlling authorization and monitoring of attempted operations. This attribute, as opposed to the sacl and dacl attributes, consists only of an ACE array and does not support automatic inheritance, although some inheritance features might be supported, altough not when the UNIX ACL model is the one supported. The acl attribute is OPTIONAL and there is no requirement that a server support it. However, when the dacl attribute is supported, it is a good idea to provide support for the acl attribute as well, in order to accommodate clients that have not been modified to use the dacl attribute. {Consenses needed, Including List (Item #65a)]: While the original intention was to define a usable OPTIONAL attribute based on the NFSv4 ACLs defined previous specfications, it is now more appropriate to designate this under-specified attribute as experiemental although still formally OPTIONAL, until the items below have been addressed.

The intention to support, as values of this attribute two different ACL approaches, each with its own semantics. These include both the NFSv4 ACLs based on the Windows ACL model and a subset based on the more restricted semantics provided by the withdrawn POSIX ACL document with a straightforward mapping of those into the format of NFSv4 ACLs. The association of two such different semantic models without giving the client a way to determine which semantic model is in effect makes interoperability ssentially impossible to provide.
The potential interoperability problems are vastly expanded by the specific method by which these two models are supported. Instead of allowing servers to choose between these two approaches, e.g. by using the term "MAY", most statements regarding ACL semactics use the term "SHOULD", described in the text as "intentional", apparently assuming that the result is essentially equivalent to the use of "MAY". Even apart from the misuse of the terms defined in [RFC2119], this has the effect of replacing a single choice by allowing a large number of unco- ordinated choices, exponentially raising the number of possibly valid semantic models that clients and users have to accmmodate.
It is not clear how far this pick-and-choose approach extends. In the case of the ace mask bits which are finer-grained than the three bits in the mode and in POSIX ACLs, there is no explicit text indicating how the coarser-grained approach would be supported by a server built to support POSIX ACLs, leaving the actual requirements uncertain.
Although some efforts have been made to limit the damage caused by this specification uncertainty by urging clients to determine authorization decisions using ACCESS rather than by examining the ACL itself, this only addresses half of the problem and the question of what ACL to set to effect a particular authorization regime remains unaddressesd, limiting the usefulness of the ACL-related features. Although significant efforts have been made to widen the information returned by ACCESS beyond the three-bit POSIX model, there are still cases in which it is insufficiently fine-grained. For example, adding a new file and a new sub-directory which have different ACE mask bits are both represented by a single bit in ACCESS.

[Author Aside]: Although it has generally been assumed that changes to sacl and dacl attributes are to be visible in the acl and vice versa, NFSv4.1 specification do not appear to document this fact. [Consensus Item, Including List (Item #16a)]: For NFSv4.1 servers that support Both the acl attribute and one or more of the sacl and dacl attributes, changes to the ACE's need to be immediately reflected in the other supported attributes:

The result of reading the dacl attribute MUST consist of a set of ACEs that are exactly the same as the ACEs ALLOW and DENY ACEs within the the acl attribute, in the same order.
The result of reading the sacl attribute MUST consist of a set of ACEs that are exactly the same as the AUDIT and ALARM ACEs within the the acl attribute, in the same order.
The result of reading the acl attribute MUST consist of a set of ACEs that are exactly the same as the union of ACEs within the sacl and dacl attributes. Two ACEs that both appear in one of the sacl or dacl attributes will appear in the same order in the acl attribute.

The Aclsupport Attribute (v4.0) A server need not support all of the ACE types described in Section 6.1. This attribute indicates which ACE types are supported for the current file system by any of the acl, sacl, or dacl attributes. [Consensus Needed (Item #61b)]: Although this attribute is OPTIONAL, there are important reasons, in certain cases, to provide support, as described in . The bitmask constants used to represent the abovementioned definitions within the aclsupport attribute are as follows: const ACL4_SUPPORT_ALLOW_ACL = 0x00000001; const ACL4_SUPPORT_DENY_ACL = 0x00000002; const ACL4_SUPPORT_AUDIT_ACL = 0x00000004; const ACL4_SUPPORT_ALARM_ACL = 0x00000008; [Author Aside (Item #14b)]: Even though support aclsupport is OPTIONAL, there has been no mention of the possibility of it not being supported. [Consensus Needed (Item #14b)]: If this attribute is not supported for a server or filesystem, the client is entitled to assume that, if the acl attribute is supported, support for ALLOW ACEs is present. Thus, if such a server supports the the sacl attribute, clients are not likely to use it if aclsupport is not supported by the server. [Previous Treatment (Item #110a)]: Servers that support either the ALLOW or DENY ACE type SHOULD support both ALLOW and DENY ACE types. [Author Aside, Including List: (Item #110a)]: The use of "SHOULD" in the preceding is unhelpful for the following reasons:

While it is unclear what the intention is, it is certainly is not in accord with RFC2119 since there is no indication of potential harm or what might be valid reasons to do otherwise.
While it might be one of "intentional" SHOULDs, that would make the paragraph meaningless since such SHHOULds are essentially equal to MAYs.
The most likely source of divergence,the fact that UNIX ACLs do not suport DENY ACEs is not mentioned at all.

[Consensus Needed (Item #110a)]: Servers that support the DENY ACE type MUST support the ALLOW ACE type as well. [Consensus Needed, Including bulleted list (Item #110a)]: Clients should not attempt to set an ACE unless the server claims support for that ACE type. The server MUST reject requests with NFS4ERR_ATTRNOTSUPP if any of the following apply:

If the server receives a request to set an ACE type that is not allowed as part of the acl attribute being set.
If the server receives a request to set an ACE, it cannot store.

Support for any of the ACL attributes is OPTIONAL. However, certain restrictions apply regarding the interaction of support for these attributes, A server that supports either of the newer ACL attributes (dacl or sacl) MUST support use of the new ACL attributes to access all of the ACE types that it supports. In other words, if such a server supports ALLOW or DENY ACEs and the sacl attribute, then it MUST support the dacl attribute and any ALLOW or DENY ACE tyopes supported by the tha acl attribute MUST be supported in the dacl attribute as well. Similarly, if it supports AUDIT or ALARM ACEs and the dacl attribute, then it MUST support the sacl attribute any AUDIT or ALARM ACE types supported by the tha acl attribute MUST be supported in the dacl attribute as well.

The Aclfeature Attribute (v4.2 extension) [Consensus Needed (Item #105c), for entire section] The contents of the Aclfeature attribute, which provides per-fs ACL feature support information, are described in the XDR below. typedef uint32_t af4miword; struct af4minfo { af4miword flagw; acemask4 maskw; }; typedef uint32_t af4typemask; typedef uint32_t af4flags; typedef uint32_t af4whoinf; struct afeat4 { af4typemask tmask; af4flags flword; af4whoinf whoword; af4minfo maskinf<>; } The field tmask provides information regarding the ACE types that are supported (as does the Aclsupport attribute) and also those that can be stored and retrieved while not being supported. See for details The field flword provides information regarding the ACE flags and auto-inheritance flags that are supported. See for details The af4minfo elements within the maskinf array provides information to the existence of support for the individual ACE mask bits appearing in ACEs. See for details [Consensus Needed (Item #4b)]: Previous specfications have given server implementations wide latitude in terms of the ACL semantics implemented. The prime motiation of the Aclfeature attribute is to provide information about semantic choices validly made by the server. However, there may also be implementations that made choices now no longer valid that are allowed to retain the existing implementation, its non-recommended character notwithstanding. In such cases, the server MUST indicate such non-standard semantics whenever Aclfeature is implemented and the definition of the attribute provides means to do so. See Sections , , and . Their are a number of situations in which responses that conform to the XDR are considred invalid nonetheless. These situations are similar to those in which NFS4ERR_INVAL would be returned on a request. In the case of this attribute value there is no predefined way to inform the server of perceived attribute invalidity. The following rules apply:

The server MUST NOT send an invalid value as the Aclfeature attribute.
When a client detects an invalid field that is not limited to a single maskinf[] entry, the client MUST NOT not act on the invalid Aclfeature attribute. This include cases in which multiple maskinf[] entries, while each valid in itself, contradict one another.
When a client detects an invalid field that is limited to a single maskinf[] entry, the client MAY ignore that entry instead of considering the entire Aclfeature attribute to be invalid

In a case in which the attribute is invalid, the client has several choices:

Ignoring the invalid AclFeature attribute, and proceding as if the attribute were not implemented. In this case, support descisions are limited to inferences that can be arrived at based on the set of ACE type supported.
Treating the Acl, Sacl, and Dacl attributes as unsupported. For clients that require acl support, this can result in an inability to use the file system.

In choosing between these, client implementations need to balance the potential incovenience of refusing to use a feature whose semantics is unclear against the likelyhood that ignoring the invalid attribute might result in the problem never being fixed. Given this choice, implemetations can often avoid the strictest treatment by reporting such issues prominently, making it clear that the problems exist.

The Dacl Attribute (v4.1) The dacl attribute was added in NFSv4.1 in order to divide ACLs so that the authorization-related entries (i.e. ALLOW and DENY entries were no longer combined in the same attribute as AUDIT and ALARM entries. {Consensus needed, Thru rest of Section (Item #65b)]: While the original intention was to define a usable OPTIONAL attribute based on the NFSv4 ACLs defined previous specifications, it is now more appropriate to designate this under-specified attribute as experimental although still formally OPTIONAL until the issues discussed in are addressed Athough the issues applying to the acl attribute apply equally to the dacl attribute, given the description in earlier specifications, it might be easier to resolve them in the case of the dacl attribute for the following reasons:

Implementaions of POSIX ACLs might not have been updated to support the sacl attriute, since doing so would add no value.
Even if such POSIX-ACL-oriented implentations of the sacl attribute did exist, it might be easier to get agreement on regularizing the sacl attribute since, if acl were left as it is, the POSIX ACL support would still be available.

The Sacl Attribute (v4.1) The sacl attribute is like the acl attribute, but sacl allows only AUDIT and ALARM ACEs. The sacl attribute supports automatic (see ). {Consensus needed, Thru rest of Section (Item #65c)]: While the original intention was to define a usable OPTIONAL attribute based on the NFSv4 ACLs definedin previous specifications, it is now more appropriate to designate this under-specified attribute as exprimental although still formally OPTIONAL until the issues discussed in are addressed The Sacl attribute was added in NFSv4.1 in order to divide ACLs so that the non-authorization-related entries (i.e. AUDIT and ALARM entries) would no longer be combinded in the same attribute with the ALLOW and DENY entries. [Author Aside, Including List (Items #61c, #105d, #110b)]: Athough the existing discussion of ACE structure results in the same sort of lack of clarity affecting the Acl and Dacl attributes, it us more likely that these will resolved in the case of the Sacl attribute as compared to the Acl or Dacl attributes, even though the problems with the existing text are essentially the same.

There are no AUDIT or ALARM entries, in POSIX ACLs, so there would be no need accommodate existing implementations of these that embody a more POSIX-oriented semantic model. As a result, it is likely to be easier to get WG approval for changes that clearly state that the ACE mask bits are to followed strictly for the these types of ACEs.
Since such entries have no role in compute a corresponding mode attribute, the effect of this issue for the sacl attribute is not problematic.

Structure and Function of NFSv4 Access Control Lists NFSv4 Access Control Lists consisting of multiple Access Control Elements. While originally designed to support a more flexible authorization model, these lists have multiple uses within NFSv4, with the use of each element depending on its type, as defined in .

ACLs may be used to provide a more flexible authorization model as described in Section 8.4 of . This involves use of Access Control Entries of the ALLOW and DENY types.
They may be used to provide the security-related services described in . This involves use of Access Control Entries of the AUDIT and ALARM types.

[Consensus Needed (Items #61d, #105e, #110c)]: Subsections of this section and of define the structure of and semantics of NFSv4 ACLs, whether they are used to represent UNIX ACLs or various extensions thereof, up to the full set of extensions provided by NFSv4 ACL semantics. Matters that relate only to extensions provided to support NFSv4 ACLs including the definition of the NFSv4.1-specific attribute Sacl, are discussed in and smmarized in Section 8.4 of .

Need to More Clearly Address ACL Semantics Choices Author Aside (Items #105f, #110d), Through end of section]: This entire section is an explanation of the motivation for making the extensive changes in the approach taken to the description of ACL semantics in Sections through and in many subections of . Although those sections, as now written, explain the reasons for the approach adopted, the explanatory approach taken is appropiate to a protocol choice already made, which will be appropriate if the working group decides to adopt this new approach. The explanation in this section is of a different nature, in that it explains the fundamental design choice we now face, and why such extensive changes to the approach taken in multiple previouly publisjed Proposed Standards are now necessary, despite the incongruity of adding an extension not previously discussed to the extensible minor version NFSv4.2. This step is, in the author's view, necessary to correct problems that having been part of the NFSv4 protocols for over two decades. It is anticipated that this section, like much other material in the form of Author Asides, will not be published as part of the RFC resulting from the progressive refinement of successive drafts of this document. In explaining the motivation this new approach, we will have to understand the nature of the mistake that was made when ACL support was incorporated, as part of NFsv4.0, in . Although, in explaining the choices actually made, we will have some suggestions as to why it was made and approved, that is not the focus of our investigation. Instead, we need to understand the mistake that was made before we can understand the problems that it gave rise to and examine the choices now available, as we work to address the problem. As we look at the problems we now have and possible solutions, it will become clear why the author believes that The approach taken here, of providing a new attribute to inform the client of server implemenation choices is the least of available evils if the goal is still, as it always has been, to take advantage of the more easily implementable UNIX ACL subset, while allowing development, over time, of more flexible alternatives. In the process, we will look at potential alternate approaches to deal with support for two ACL models, including some that could have been implemented earlier to prevet this situation, but have become unavailable as the NFSv4 protools have evolved. The basic problem that the working group faced in defining an ACL feature for NFSv4 arose from the lack of existing semantic descriptions of how ACLs were to work together with a set of assumptions, derived from previous NFS versions, that maade it hard to appropriately plan for the necessary work. Given this background, there were two semantic models available which might be co-opted to provide an ACL semantic model.

The ACLs defined by a POSIX draft, later withdrawn. Here, and elsewhere in this document and related documents, we describe these as "UNIX ACLs". Factors arguing for this as an appropriate choice were its close connection with POSIX semantics, the existence of UNIX-based APIs to establish and modify such ACLs and its commmon implementation, within many file systems runnin within UNIX server implementations, despite its withdrawn status. On the other hand, that close connection to POSIX could be considred limiting, in that model the adherered quite closely to the POSIX approach with its coarse-grained approach to the specification of authorized operations.
Windows ACLs or the subset of it that could be fit into the NFSv4 protocol. This provided a more flexible semantic model capable of finer-grained control of the actions to be authorized or blocked together with a number of elements that had no correlates within the POSIX framework and could only be accepted by NFSv4 together with the understanding that enforcement would be provided by mechanisms ouside NFSv4. As a result, initial impplementation of this model were not common and any that were developed would likely to avoid some the Windows-only material incoporation in the NFSv4 ACL model.

Given this background, the working group faced a difficult choice in that adopting either pf these approaches posed significant difficulties:

Adoption of the UNIX ACL approach, while likely to proceed quickly did not address the goal of moving decsively beyond NFSv4 in terms of ACL functionality.
Adopton of the NFSv4 ACL model as the sole approach to ACL semantics, would, most likely, have sharply limited adoption of the ACL features to a small set of servers, with the expected result that client would not be motivated to provide support either.

Given the need to, in some fashion, support both of these semantic models, the following two approaches listed below suggest themselves as ways to take advantage of the immediate limited improvements provided by UNIX ACL model, while allowing development over time of implementations of the more flexible model.

Defining support for the two types of ACLs by means of two separate attributes.
Providing the client other means (e.g. a per-fs read-only OPTIONAL attribute) by which the client can determine which semantic model was implemented.

As things turned out, neither of these approaches were taken, for reasons that will not be discussed here. Instead, the two models were embadded in a common XDR based on the NFSv4 model. Since the embedding was such that UNIX ACLs, once put in this common form, could not be recognized as such, the need for the two co-existence options discussed above remained as it was, although later developments had important effects limiting how the problem needed to be addressed. The resulting specification text, based on the XDR adopted, treated the NFSv4 ACL model as canonical. The support for the UNIX ACL model is limited to allowing, by various means, its implementation on the server without really addressing the need to inform the client of the semantic differences between the two models. In the following, we list those semantic differences, which are, not conincidentally, the specific issues that we have chosen to address in the Aclfeature attribute. Together with each item, we discuss possible alternatives to providing the information as an element in an attribute like AclFeature.

Existing specifications provide multiple ways of computing the mode corresponding to an ACL, each described in its own section, either Section or . Although the existing specs do cite reasons why the first of is to be preferred, it clearly allows server to choose either and provides no way for the client to find out which aproach is implemented, which makes interoperability testing hard to accomplish. While it would higly desirable to eliminate this variation, by mandating one of these variations as REQUIRED, that has to be considred quite unlikely at this point given the use, in the existing specfications, of term SHOULD identified as an "intentional use" with the clear implication that allowing this behvior is necessary. Given the likely existence of servers implementing the approach described in , it appears that we would have difficulty getting to a "SHOULD" that was valid according to . Given that we are going to be faced with decidedly diffferent approaches, it is essential that we provide a way to determine th approach used. Without that, interoperbility testing cannot test for the expected behavior since the expected behavior may differ in unexpected ways, undercutting the entire effort.
While UNIX ACLs use three permission bits, there are sixteen distinct ACE mask bits, creating difficult issues in supporting both models in the same protocol. Part of this is due to the finer-grained nature of the ACE mask bits, exacerbated by the mutiple use of each of the mask bits defined in . For example, ACE4_WRITE_DATA can be interpreted either as controlling all of the acions controlled by the write privilege bit or the subset of such actions not controlled by additional finer-grained mask bits. The existing specfications are not very explicit about how to address differences between the client and server as to diferent approaches the mapping of authorization-requiring actions and the corresponding mask bits. However, it is possible to infer an expected approach which we can confirm (or not) once more knowledge is made available regarding when client that support use of ACLs actually do. It seems that the expected approach to this problem was predicated on the assumption that all of the ACE mask bits beyond those described in could be treated as finer-grained versions of those three, as the ones described are, essentially ignoring the corresponding issue with regard to Sections and . With this limitation in mind, it seems that existing specifications, essentialy require clients written to use the three privilege bits of the UNIX ACL model, map the write bit to the set of mask bits defined in which all need to authorized or not together. This makes the extensions to a finer-grained authorization model essentially useless. For example, if a client wants to specify an ACL for a directory which presvents ubdirectories from being added (the reason for defining ACE4_ADD_SUBDIRECTORY) it has a way to specify an ACL that would do that if the server supports such a thing but that is all. There is no way for the client to determine whether such an ACL wold be accepted or whther it would do the desired thing if it were accepted.
There are special who values defined in which are not explicitly defined as OPTIONAL but which, by their nature appear to be higly unlikely to be implemented by servers and for which, so far, no implementations are known. These special values need to be explcitly presented as OPTIONAL, if they are retained in the protocol. Given the absence of known implementations so far, their elimination should not be considered impossible. If these values are to be retained, there needs to be some eays determine to determine if server support is provided. Without that, client cannot use them, even on the the server subset providing this support.
There is support, via the acsupport attribute, for determining the set of supported ACE types but the existing specifications do not really address the issues of ACE types that can be stored without being supported a it attempt to do with rspect to other similar issues with potentially unsupported protcol elements.

To summarize, we have a situation in which some of the items discussed above might be avoided without undoing the work done to provide the extensions within the NFSv4 ACL model, but there are others in which this work has to be considered essential. As a result, there needs to be an Aclfeature attribute or somethings similar. Given that fact, as the proposal now stands, all of the above are dealt within that single framework. As a result of the lack of attention to the task of providing the client information regarding the specific ACL extensions supported, we now have a situation inferior to that which would have arisen if either of the original choices has ben pursued staightforwardly or if both had been defned as separate OPTIONAL features.

There is no way clients can take advantage of the greater flexibility provided by the NFSv4 ACL model because specifications have been written to allow the greater flexibility not to be implemented. As a result, only the UNIX ACL subset can be used with some assurance that the necessary facilities are implemented.
It is hard to provide support for and to use the UNIX ACL subset, because of the degree to which implementors need to involve themelves with details that they hane no chance of ever dealing with.
Given the existing sitution, server implementers have no motivation to provide support for the extensions, since, even if they did, there would be no ways that software could be written to take advantage of that work.
In addition, It is difficult for implementers to get resource to invest in feature development, when it has been made so unclear that there is a set of features to implement. As a result of the lack of recognition of the NFSv4 ACL as OPTIONAL features, the lack of tese features appear as a quality-of-implementtion issues which it is hard to get allocate resource to address, since user expectation in this area continue to be limited.

ACL Semantics Choices [Consensus Needed, Including List (Items #61e, #105g, #110d)]: There are a range of potential authorization models that can be supported using the Acl and Dacl attributes:

UNIX ACLs, based on the withdrawn POSIX ACL draft. This approach retains the three bits typical of POSIX semantics and maps them, with a number of implied restrictions, to a subset of the more expansive set of ACE mask bits defined in .
Full NFSv4 ACLs, with expanded semantics derived from Windows ACLs. This includes a finer-grained permissions model, the inclusion of DENY ACEs, and the use of ACLs for non-authorization functions, via the use of AUDIT and ALARM ACEs, and a number of features related to ACL inheritance.
Various hybrids of the two models, supporting some, but mot all of the extensions to UNIX ACLs introduced in earlier minor version specifications. The new Aclfeature attribute, available as an extension in NFSv4.2, allows the client to determine which extensions are implemented for a particular file system. See xref target="ACL-sem-discovery"/> for further discussion. Where this feature is not available, including NFSv4.0 and NFSv4.1, information on the extensions supported can be inferred based on the value of the Aclsupport attribute. See xref target="ACL-sem-inference"/> for details. In all of these cases the client can rely on the fact that the core features derived from UNIX ACLs are always available when the Acl or Dacl attributes are supported.

[Author Aside, Including List (Items #30a, #61e, #105g, #110d)]: Earlier specifications of the ACL feature allowed servers to provide any of these semantic models. Unfortunately, the server was not given an explicit choice and the client has no way of determing the semantics associated with the ACL and adapting accordingly. Instead the approach was to widen the range of permissible server behavior to be implemented for ACLs, so it included both sorts of ACL semantics, various hybrids unlikely to be implemented, as welll as a lot of miscellaneous variants, many probably unintended, as well.

The keyword SHOULD was used for just about every element of ACL semantics, without proper attention to the meaning of that term as defined in . The resulting text often stated that these uses of "SHOULD" were "intentional" without explicitly providing any reason that would justify not performing the recommended action or discussion of the consequences of doing so. The result was to effectively replace a single MAY by a lare number instances of SHOULD each treated essentially as MAY with an exponential expansion of the number behaviors a client would have to be prepared for.
In many cases, the use of SHOULD with the implied meaning MAY, leaves open more than two possiilities since it is not always clear what restictions apply to the case in which the recommendation is bypassed. As a result, the number of notionally valid server behaviors can expand even beyond the exponential increase discuused above.
In the handling of the mapping of ACLs to modes, important when ACLs are supported and used, there are further sources of confusion that need to be resolved. What is almost surely the preferred method in introduced in Section 6.3.2 of without a MUST or even a SHOULD but instead says it "can be used", even though Section 6.4 of states that these methods are covered by an "intentional" SHOULD. In many cases, An alternate method is introduced by stating that "Some server implementations" do a particular thing, without any discussion of the effect on interoperability, although it does say that "implementations are discouraged" from doing this. Although Section 6.4 of indicates the motivation of this alternate method is to provide support for servers supporting the withdrawn POSIX draft ACLs, there is no indication of a normative connection betweeen these two choices.

Discovery of ACL Semantics [Consensus Needed (Items #105h, #110e)]: The OPTIONAL attribute Aclfeature defined as an NFSv4.2 extension (see provides a way for the client to determine what extensions to the UNIX ACL model are supported on a given file system. The specific extensions that may be supported include the following:

The support for ACE mask bits (see in addition to the three that represent the POSIX-derived privilege bits: Read, Write, and Execute, which are always supported. In addition to these coarse-grained mask bits, which are discussed in , there are flags withing the Aclfeature attribute that indicates whether the additional mask bits defined in Sections , , and are supported as well. Additional mask bits will be definable as later extensions as described in to support new features and improve granulrity. To enable smoother transitions to use of newer bits the set of supported mask bits and those that can be stored abd retriedved but not supported are separately specifiable.
The inclusion of support for ACE types in addition to ACE4_ACCESS_ALLOWED_ACE_TYPE is deteminabe using the Aclsupport attribute. In addition, the AclFeature attribute allows the client to determine the set of ACE types that, while not supported, can be stored and retrieved. When the AclFeature attribute is available additional ACE may be defined, as described in .
Although it is clear that the ACE flags are intended to be OPTIONAL, that term is not used and there is not any way of determining whethe support for each of these is present as there should be for such features. Instead the optionality is conveyed by simply saying server "need not" support any of these flags. To further complicate the feature discovery process, previous discussion of these flags contain the following statement:
- If the server supports flags that are similar to, but not exactly the same as, these flags, the implementation may define a mapping between the protocol-defined flags and the implementation-defined flags.
There is no way for the client to be aware of such an implementation-defined mapping, even if there were a reasonable definition flag being "similar". When the AclFeature attribute is available the client can determine the set of supported flags from information provided by the server including informing the client of case in which acl inheritence for file and directorties is supported but the two options are not separable.
Regarding the flags in the sacl and dacl attributes, the existing v4.1 specification is not altogether clear about whether these are OPTIONAL or not. However, one can conclude that the protocol needs to allow non-support of these features if only to allow their use, which is recommended for all, in the ccase of servers supporting the UNIX ACL model, which has no inheritance provisions at all. When the AclFeature attribute is available the client can determine whether support is present by checking the AF4FLAG_INHAUTO flag within the flword field of the Aclfeature atrribute.
defines a number of specual who values, in addition to OWNER@, GROUP@, and EVERYON@, that can reasonably be assumed to be OPTIONAL. So far, no server implementations of these have been found, and one cannot be sure any exist. Additionally, it is likely that cliets using these do not exist. When the Aclfeature attribute is available, the presence of support for these "special" who values is indicated by flags bits within whoword field of the attribute. Similarly, there are also flags that indicate whether such special values, when not supported, can be stored and then returned when interrogated.

The details of support discovery are defined in subsections of . Items one and two are dealt with in Sections respectively, three and four delt with inn while items five and six are dealt wiith in .

Inferring ACL Semantics In cases in which the Aclfeature attribute is not supported, including use of minor versions for which it is not defined (i.e. minor versions below two), there are ways to determine the extensions supported. It is important to note that these methods, while sometime helpful, have important limitations that make imlementation of Aclfeature desirable, where this option is available:

Testing for support of mask bits by attempting to set vaious masks bit is a lengthy process, which might not be reasonably done on crossing fs booundaries.
In many cases, testing for support of particular features has been made unreliable because of a laxness of specification language, most often by use of "SHOULD" in calling for an error return.
Similarly, in many cases, an error return cannot be relied upon becayse the server is allowed to accept ACEs that it cannot suppport, simply because it can store them and return them.

In any case, each of the following areas of support discovery provided has some correlate in which inferences can be drawn given available information. In some cases, these infernce ar sufficient to provide the needed information while in others they are limited in various ways, so that they can only be used in limited cirsumsances or supplemented by other sorts of knowledge about server characteristics. The following list the area of support discovery, most desirably provided by the Aclfeature attribute.

There are only limited facilities to determine te set of mask bits supported. However, given the REQUIRED character of the mask bits defined in and knowledge of the choice of ACL model we have something that will probably support the needs of existing clients. In the case in which it it can be inferred that support for the UNIX ACL model is provided, it is reasonable to suppose that ACE mask bits other than those defined in are not supported. [Author Aside (Item #113a)]: We neeed to clarify what clients neeed to do in this case. Intend to wait until we see results from experiments. For servers supporting the NFSv4 ACL model, and certain hybrids support could only be determined by testing various ACE mask combinations in ACLs to be set. As this is unlikely to be ppractical, clients only needing facilities provided by the UNIX ACL model could handle things as is done with servers supporting the UNIX ACL model. Those needing could only operate as they do today, by depending on externally obtained knowledge about the server bein used, i.e., non-interoperably.
Information about support for various ACE types is provided by the aclsupport attribute. Unfortunately, the aclsupport attribute is OPTIONAL and will remain so at least until NFSv3. This is of particular concern since all attempts to infer the ACL model supported depend on the set of ACE types supported and asking client to try particular ACLs containing particlar ACE types when entering a file system is probably not viable.
Support for flags within the ACE can only be determined by attempting to use those flags and seeing if NFS4ERR_ATTRNOTSUP is returned. The same applies to the flags for the automatic inheritence features in the dacl andsacl attributes As that is unlikely to be practical, clients are likely to use the inferred ACl model to simplify the process, It can be asssumed that a server supporting the UNIX ACL model does not support any of the ACE flags or any of the automatic ACL inheritance flags, Clients that do not need any of these featues including those that only need UNIX ACL features do not need the information. For those that do need that information, their only option is to depend on externally derived information about server support of flags to enble use, albeit non-onteroperably.
There are no means by which the presene of support for various special who values other than by attempting to set aACEs using them and seeing if NFS4ERR_BADOWNER is returned. As this is likely to be impractical it is unlikely to be done. In practical terms however, tis is unlikely to be importnt since clients using these might not exist and any that did would be relying on externally obtained knowledge about the server to obtain the function in a non-onteroperale fashion.

Structure of Access Control Entries The attributes acl, sacl (v4.1 only) and dacl (v4.1 only) each contain an array of Access Control Entries (ACEs) that are associated with the file system object. The client can set and get these attributes while the server is responsible for using the ACL-related attributes to perform access control. The client can use the OPEN or ACCESS operations to check access without modifying or explicitly reading data or metadata. The NFS ACE structure is defined as follows: typedef uint32_t acetype4; typedef uint32_t aceflag4; struct nfsace4 { acetype4 type; aceflag4 flag; acemask4 access_mask; utf8str_mixed who; };

ACE Type

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.

Value	Abbreviation	Description
ACE4_ACCESS_ALLOWED_ACE_TYPE	ALLOW	Explicitly grants the ability to perform the set of actions specified in acemask4 to the file or directory. When all such actions to be done by a given operation are explicitly allowed, the operation is authorized and scanning of the ACL to dtermine authorization stops.
ACE4_ACCESS_DENIED_ACE_TYPE	DENY	Explicitly denies the ability to perform the set of actions specified in acemask4 to the file or directory. When any of the actions to be done by a given operation are explcitly denied, the operation is unauthorized and scanning ofthe ACL to determine authoriztion stops.
ACE4_SYSTEM_AUDIT_ACE_TYPE	AUDIT	Logs (in a system-dependent way) any attempt to perform, for the file or directory, any of the actions specified in acemask4.
ACE4_SYSTEM_ALARM_ACE_TYPE	ALARM	Generates (in a system-dependent way) an alarm upon any attempt to perform, for the file or directory, any of the actions specified in acemask4.

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

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 and 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 as well as those defined in .

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 , 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.

ACE Type Extensiion [Consensus needed (Item #105j), through end of section]: Standards-track docments which define NFSv4 protocol extensions, as provided for in , 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.

ACE Access Mask The following bitmask constants can be used within the access mask field of the ACE. const ACE4_READ_DATA = 0x00000001; const ACE4_LIST_DIRECTORY = 0x00000001; const ACE4_WRITE_DATA = 0x00000002; const ACE4_ADD_FILE = 0x00000002; const ACE4_APPEND_DATA = 0x00000004; const ACE4_ADD_SUBDIRECTORY = 0x00000004; const ACE4_READ_NAMED_ATTRS = 0x00000008; const ACE4_WRITE_NAMED_ATTRS = 0x00000010; const ACE4_EXECUTE = 0x00000020; const ACE4_DELETE_CHILD = 0x00000040; const ACE4_READ_ATTRIBUTES = 0x00000080; const ACE4_WRITE_ATTRIBUTES = 0x00000100; const ACE4_WRITE_RETENTION = 0x00000200; const ACE4_WRITE_RETENTION_HOLD = 0x00000400; const ACE4_DELETE = 0x00010000; const ACE4_READ_ACL = 0x00020000; const ACE4_WRITE_ACL = 0x00040000; const ACE4_WRITE_OWNER = 0x00080000; const ACE4_SYNCHRONIZE = 0x00100000; Note that some masks have coincident values, or are treated differently when used with different types of objects. For example, ACE4_READ_DATA and ACE4_LIST_DIRECTORY designate the same mask bit which is treated differently depeding on whether the object is a directory or other type of object. Note that,

The mask value names ACE4_ADD_FILE, ACE4_ADD_SUBDIRECTORY, and ACE4_DELETE_CHILD are intended to be used with directory objects that are not named attribute directories and are not supported when used with objects of other types.
The mask value came ACE4_APPEND_DATA is intended to be used with non-directory objects.
The mask values used for ACE4_READ_DATA and ACE4_LIST_DIRECTORY designate the same mask bit is which treated differently depeding on whether the object is a named attribute directory a sirectory which is not a named attribute directory, or other type of object. The mask values for ACE4_WRITE_DATA and ACE4_ADD_FILE behave similarly as do the mask values for ACE4_APPEND_DATA and ACE4_ADD_SUBDIRECTORY.
The mask bit designated by ACE4_EXECUTE controls two different sets of action depending on whether the underlying object is a directory.

[Consensus Needed (Items #102a, #103a), through end of list]: These mask bit are explained in more detail in the sections mentioned below based on their relationshup to the three POSIX-derived permission bits: Read, Write, and Execute. Changes include material in multiple subsections of .

Mask bits whose set of authorized actions corresponds to a single POSIX-drived permission bit are explained in . These mask bits are always to be supported although the set of authorized actions is expected to be smaller when other mask bits covering a smaller set of actions are supported.
Mask bits whose set of authorized actions is a subset of those normally controlled by a single POSIX-drived permission bit are explained in . These mask bits are not always supported, but depend on ACL extensions supported by the server. For detailed guidance regarding how the client can determine which mask bits are supported, see Sections and .
Most Mask bits whose set of authorized actions is neither identical to nor a subset of those controlled by a single POSIX-drived permission bit are explained in . This section includes mask bits for which we have found existing implementations. These mask bits are not always supported, but clients need to be prepared for support actually present depending on the set of ACL extensions supported. [Author aside (Item #111a)]: The following parapgraph has to be considered tentiative for now, at least until some implementation of this bit isfound or it is determined that none exist. In at least one case, that of ACE4_READ_NAMED_ATTRIBUTES, we include a mask bit for which no implementation has yet been found. Although, the specific details differ from those in existing specifications, change has been necessary to appropriately co-ordinate handling of actions controlled by this bit, with the corresponding handling when POSIX authorization is in effect or when UNIX ACLs are supported.
Mask bits defined in existing specfication but for which no corresponding imlementation has yet been found are explained in .

[Consensus Needed (Item #5a) The descriptions in the section below are relevant to both authoriztion and for recognizing operations whose success or failure are to be recorded when ACL are used for the non-authorization functions described in . With regard to ACCESS whose returned bits are affected, it is not necessarily the case that the occurrence of ACCESS in these lists implies that such operations are recordable events. [Consensus Needed (Item #4c)]: While it s recommended that The sets of actions to be authorized or otherwise noted in connecton with these mask bits be those cited in the sections below, it is possible that existng implementations might behave differently, based on their earlier reliance on earlier specfications and a common understanding within the working group that it was the job of the specification to conform to the implementation, rather than the other way around. See for information about how the client is to be made aware of such discordant implementations.

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 , 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 , 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 , 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.

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 . [Consensus Item, Including List (Item #62a): The full description of the role of the sticky-bit appears in Section 5.3.2 of . 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 is more restrictive than the previous one appearing in . 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 . 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.

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.

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 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 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 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.

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 . 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.

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 .

ACE Mask Support Discovery Of the ACE mask bits defined above and those added later by extensions as described in , support for most is OPTIONAL. The only exceptions are for those discussed in , 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 . 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 , 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 , 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.

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 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 , 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 and . 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 , 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.

ACE Mask Bit Extension Standards-track docments which define NFSv4 protocol extensions, as provided for in , 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.

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 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.

Handling of Deletion (Vestigial) [Author Aside]: This section contains the former content of . 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.

ACE flag bits The bitmask constants used for the flag field are as follows: const ACE4_FILE_INHERIT_ACE = 0x00000001; const ACE4_DIRECTORY_INHERIT_ACE = 0x00000002; const ACE4_NO_PROPAGATE_INHERIT_ACE = 0x00000004; const ACE4_INHERIT_ONLY_ACE = 0x00000008; const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010; const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020; const ACE4_IDENTIFIER_GROUP = 0x00000040; const ACE4_INHERITED_ACE = 0x00000080; [Author Aside]: Although there are multiple distinct issues that might need to be changed, in the interest of simplifying the review, all such issues within this section will be considered part of Consensus Item #13a with a single revised treatment addressing all the issues noted. [Previous Treatment]: A server need not support any of these flags. [Author Aside]: It is hard to understand why such broad license is granted to the server, leaving the client to deal, without an explicit non-support indication, with 256 possible combinations of supported and unsupported flags. If there were specific issues with some flags that makes it reasonable for a server not to support them, then these need to be specifically noted. Some additional problems with the existing treatment are that many of the flags in this list are not, by their nature, capable of support by the server (e.g., ACE4_INHERITED_ACE) and that some cannot reasonably be made OPTIONAL in general (e.g. ACE4_IDENTIFIER_GROUP for all ACEs and both ACE4_SUCCESSFUL_ACCESS_ACE_FLAG and ACE4_FAILED_ACCESS_ACE_FLAG for AUDIT and ALARM ACES). Also troubling is the lack of any statement regarding the use of unassigned bits and the consequent effect on protocol extensibility. [Previous Treatment]: If the server supports flags that are similar to, but not exactly the same as, these flags, the implementation may define a mapping between the protocol-defined flags and the implementation-defined flags. [Author Aside]: The above regarding, the possibility of defining a mapping betweeen the protocol-defined flags and hypothetical implementation-defined flags might store the bits it supports, while valid, is out-of-scope and need to be deleted. [Previous Treatment]: For example, suppose a client tries to set an ACE with ACE4_FILE_INHERIT_ACE set but not ACE4_DIRECTORY_INHERIT_ACE. If the server does not support any form of ACL inheritance, the server should reject the request with NFS4ERR_ATTRNOTSUPP. If the server supports a single "inherit ACE" flag that applies to both files and directories, the server may reject the request (i.e., requiring the client to set both the file and directory inheritance flags). The server may also accept the request and silently turn on the ACE4_DIRECTORY_INHERIT_ACE flag. [Author Aside]: What is the possible justification for accepting a request asking you do something and then, without notice to the client, do something else. I believe there is none. Consensus Needed (Item #13a)]: Server support for many of the flags defined above is OPTIONAL, although there are constraints in some cases so that certiain combination of support and non-support are not allowed, as described in Consensus Needed (Item #13a)]: When a server which does not support all the flags bits receives a request to set an NFSv4 ACL containing an ACE with an unsupported flag bit set the server MUST reject the request with NFS4ERR_ATTRNOTSUPP. Consensus Needed (Item #13a)]: The case of servers which do not provide support for particular flag combinations is to be treated similarly. If a server supports a single "inherit ACE" flag that applies to both files and directories, receives a request set an NFSv4 ACL with ACE ACE4_FILE_INHERIT_ACE set but ACE4_DIRECTORY_INHERIT_ACE not set, it MUST reject the request with NFS4ERR_ATTRNOTSUPP.

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 . 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.

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
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
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
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 , 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 . 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 or 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

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.

ACE Who The "who" field of an ACE is an identifier that specifies the principal or principals to whom the ACE applies. It may refer to a user or a group, with the flag bit ACE4_IDENTIFIER_GROUP specifying which of the two is referred to. There are several special identifiers that need to be understood universally, rather than in the context of a particular DNS domain. [Author Aside, including list]: The above paragrph is OK, but the following issues regarding these special identifiers need to be addressed:

Lack of clarity about the question of which of these special identifiers have to be supported and for which support is OPTIONAL.
Lack of clarity about which special identifiers can be understood by NFSv4.
Confusion of "authentication" and "identification".

[Previous treatment (Item #50a)]: Some of these identifiers cannot be understood when an NFS client accesses the server, but have meaning when a local process accesses the file. The ability to display and modify these permissions is permitted over NFS, even if none of the access methods on the server understands the identifiers. [Consensus Needed (Item #50a)]: Server support for the special identifiers "OWNER", "GROUP", and "EVERYONE" is REQUIRED. For others support is OPTIONAL with information regarding support discovery appearing in [Consensus Needed (Item #50a)]: Some of these identifiers, such as "NETWORK", "DIALUP", "INTERACTIVE", "BATCH", and "SERVICE" cannot be reliably understood when an NFS client accesses the server, but might have meaning when a local process accesses the file or when protocols other than NFSv4 are used As a result, when ACEs containing these who values are encountered, a server that supports these values when NFSv4 request are processed is free to make its own judgment as to whether any particular request will be treated as matching. [Consensus Needed (Item #50a)]: The ability to display and modify these OPTIONAL permissions is provided for by NFSv4, even though they are not, in most cases, useful when processing NFSv4 requests,

Who	Description
OWNER	The owner of the file.
GROUP	The group associated with the file. Note that the mode bits for the group do not apply to the owner of the file while the ownerof the file is a member of GROOUP@
EVERYONE	[Previous treatment (Item #50a)]: The world, including the owner and owning group. [Consensus Needed (Item #50a)]: All requesters, including the owner, members of the owning group, and requests for which no user information is available.
INTERACTIVE	Accessed from an interactive terminal.
NETWORK	Accessed via the network.
DIALUP	Accessed as a dialup user to the server.
BATCH	Accessed from a batch job.
ANONYMOUS	[Author Aside]: Although AUTH_NONE requests, are included here it is not clear whether AUTH_SYS requests, particularly those issued without client peer authentication should be included. Although I feel that they are not truly authenticated, it is hard to be sure of the intention given the way term "authenticated" has been used in earlier specifications. Also hard to resolve is the status of "nobody@domain" which is inteneded to be anonymous but may well be authentcated, as some other user. [Author Aside]: For now, am doing the best I can, given that no implementations of these have been found. When they are, will need to consider revision. If none are found, could consider deleting these. In any case, think we will wind up treating thse as opposites, unless forced to do otherwise by existing mplementations. [Consensus Needed (Item #50a)]: Accessed without any authentication of the user principal (e.g via AUTH_NONE). Also can include user defined as anonybous such as those which result from root-squashing, regardless of the quality of authentication
AUTHENTICATED	[Author Aside]: As for the previous case, am doing the best I can given that no implementation of these have been found. [Consensus Needed (Item #50a)]: Any authenticated user except those to be treated as anonymous (opposite of ANONYMOUS).
SERVICE	Accessed from a system service.

To avoid conflict, these special identifiers are distinguished by an appended "@" and will appear in the form "xxxx@" (with no domain name after the "@"), for example, ANONYMOUS@. {Previous treatment (Item #51a)]: The ACE4_IDENTIFIER_GROUP flag MUST be ignored on entries with these special identifiers. When encoding entries with these special identifiers, the ACE4_IDENTIFIER_GROUP flag SHOULD be set to zero. [Author Aside]: I don't understand what might be valid reasons to ignore this or how a server would respond in the case the that it was ignored. [Consensus Needed (Item #51a)]: The ACE4_IDENTIFIER_GROUP flag MUST be ignored on entries with these special identifiers. When encoding entries with these special identifiers, the ACE4_IDENTIFIER_GROUP flag should be set to zero. It is important to note that "EVERYONE@" is not equivalent to the UNIX "other" entity. This is the case because, by definition, UNIX "other" does not include the owner or owning group of a file. "EVERYONE@" means literally everyone, including the owner or owning group.

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 . 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 .
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 rather than using the method specified in .

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.

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.

Automatic Inheritance Features The acl attribute consists only of an array of ACEs, but the sacl and dacl attributes also include an additional flag field. struct nfsacl41 { aclflag4 na41_flag; nfsace4 na41_aces<>; }; The flag field applies to the entire sacl or dacl; three flag values are defined: const ACL4_AUTO_INHERIT = 0x00000001; const ACL4_PROTECTED = 0x00000002; const ACL4_DEFAULTED = 0x00000004; and all other bits are to be cleared. The ACE4_INHERITED_ACE flag can be set in the ACEs of the sacl or dacl (whereas it always needs to be cleared in the acl). Together these features allow a server to support automatic inheritance, which we now explain in more detail. Inheritable ACEs are normally inherited by child objects only at the time that the child objects are created; later modifications to inheritable ACEs do not result in modifications to inherited ACEs on descendants. However, the dacl and sacl provide an OPTIONAL mechanism that allows a client application to propagate changes to inheritable ACEs to an entire directory hierarchy. A server that supports this feature performs inheritance at object creation time in the normal way, and SHOULD set the ACE4_INHERITED_ACE flag on any inherited ACEs as they are added to the new object. A client application such as an ACL editor may then propagate changes to inheritable ACEs on a directory by recursively traversing that directory's descendants and modifying each NFSv4 ACL encountered to remove any ACEs with the ACE4_INHERITED_ACE flag and to replace them by the new inheritable ACEs (also with the ACE4_INHERITED_ACE flag set). It uses the existing ACE inheritance flags in the obvious way to decide which ACEs to propagate. (Note that it may encounter further inheritable ACEs when descending the directory hierarchy and that those will also need to be taken into account when propagating inheritable ACEs to further descendants.) The reach of this propagation may be limited in two ways: first, automatic inheritance is not performed from any directory ACL that has the ACL4_AUTO_INHERIT flag cleared; and second, automatic inheritance stops wherever an ACL with the ACL4_PROTECTED flag is set, preventing modification of that ACL and also (if the ACL is set on a directory) of the ACL on any of the object's descendants. This propagation is performed independently for the sacl and the dacl attributes; thus, the ACL4_AUTO_INHERIT and ACL4_PROTECTED flags may be independently set for the sacl and the dacl, and propagation of one type of acl may continue down a hierarchy even where propagation of the other acl has stopped. New objects are to be created with a dacl and a sacl that both have the ACL4_PROTECTED flag cleared and the ACL4_AUTO_INHERIT flag set to the same value as that on, respectively, the sacl or dacl of the parent object. Both the dacl and sacl attributes are Recommended, and a server MAY support one without supporting the other. A server that supports both the old acl attribute and one or both of the new dacl or sacl attributes MUST do so in such a way as to keep all three attributes consistent with each other. Thus, the ACEs reported in the acl attribute will be the union of the ACEs reported in the dacl and sacl attributes, except that the ACE4_INHERITED_ACE flag will be cleared from the ACEs in the acl. And of course a client that queries only the acl will be unable to determine the values of the sacl or dacl flag fields. When a client performs a SETATTR for the acl attribute, the server SHOULD set the ACL4_PROTECTED flag to true on both the sacl and the dacl. By using the acl attribute, as opposed to the dacl or sacl attributes, the client signals that it may not understand automatic inheritance, and thus cannot be trusted to set an ACL for which automatic inheritance would make sense. When a client application queries an NFSv4 ACL, modifies it, and sets it again, it needs to leave any ACEs marked with ACE4_INHERITED_ACE unchanged, in their original order, at the end of the NFSv4 ACL. If the application is unable to do this, it needs to set the ACL4_PROTECTED flag. This behavior is not enforced by servers, but violations of this rule may lead to unexpected results when applications perform automatic inheritance. If a server also supports the mode attribute, it SHOULD set the mode in such a way that leaves inherited ACEs unchanged, in their original order, at the end of the ACL. If it is unable to do so, it SHOULD set the ACL4_PROTECTED flag on the file's dacl. Finally, in the case where the request that creates a new file or directory does not also set permissions for that file or directory, and there are also no ACEs to inherit from the parent's directory, then the server's choice of ACL for the new object is implementation-dependent. In this case, the server SHOULD set the ACL4_DEFAULTED flag on the ACL it chooses for the new object. An application performing automatic inheritance takes the ACL4_DEFAULTED flag as a sign that the ACL is to be completely replaced by one generated using the automatic inheritance rules.

Processing Access Control Entries To determine if a request succeeds, the server processes each nfsace4 entry of type ALLOW or DENY in turn as ordered in the array. Only ACEs that have a "who" that matches the requester are considered. An ACE is considered to match a given requester if at least one of the following is true:

The "who' designates a specific user which is the user making the request.
The "who" specifies "OWNER@" and the user making the request is the owner of the file.
The "who" designates a specific group and the user making the request is a member of that group.
The "who" specifies "GROUP@" and the user making the request is a member of the group owning the file.
The "who" specifies "EVERYONE@".
The "who" specifies "INTERACTIVE@", "NETWORK@", "DIALUP@", "BATCH@", or "SERVICE@" and the requester, in the judgment of the server, feels that designation appropriately describes the requester.
The "who" specifies "ANONYMOUS@" or "AUTHENTICATED@" and the requestor's authentication status matches the who, using the definitions in

Each ACE is processed until all of the bits of the requester's access have been ALLOWED. Once a bit (see below) has been ALLOWED by an ACCESS_ALLOWED_ACE, it is no longer considered in the processing of later ACEs. If an ACCESS_DENIED_ACE is encountered where the requester's access still has unALLOWED bits in common with the "access_mask" of the ACE, the request is denied. When the ACL is fully processed, if there are bits in the requester's mask that have not been ALLOWED or DENIED, access is denied. Unlike the ALLOW and DENY ACE types, the ALARM and AUDIT ACE types do not affect a requester's access, and instead are for triggering events as a result of a requester's access attempt. AUDIT and ALARM ACEs are processed only after processing ALLOW and DENY ACEs if any exist. This is necessary since the handling of AUDIT and ALARM ACEs are affected by whether the access attempt is successful. [Previous Treatment]: The NFSv4.1 ACL model is quite rich. Some server platforms may provide access-control functionality that goes beyond the UNIX-style mode attribute, but that is not as rich as the NFS ACL model. So that users can take advantage of this more limited functionality, the server may support the acl attributes by mapping between its ACL model and the NFSv4.1 ACL model. Servers must ensure that the ACL they actually store or enforce is at least as strict as the NFSv4 ACL that was set. It is tempting to accomplish this by rejecting any ACL that falls outside the small set that can be represented accurately. However, such an approach can render ACLs unusable without special client-side knowledge of the server's mapping, which defeats the purpose of having a common NFSv4 ACL protocol. Therefore, servers should accept every ACL that they can without compromising security. To help accomplish this, servers may make a special exception, in the case of unsupported permission bits, to the rule that bits not ALLOWED or DENIED by an ACL must be denied. For example, a UNIX-style server might choose to silently allow read attribute permissions even though an ACL does not explicitly allow those permissions. (An ACL that explicitly denies permission to read attributes should still be rejected.) [Author Aside]: While the NFSv4.1 provides features that many might not need or use, it is the one that the working group adopted by the working group, and I have to assume that alternatives, such as the withdrawn POSIX ACL proposal were considered but not adopted. The phrase "unsupported permission bits" with no definition of the bit whose support might be dispensed with, implies that the server is free to support whatever subset of these bits it chooses. As a result, clients would not be able to rely on a functioning server implementation of this OPTIONAL attribute. If there are specific compatibility issues that make it necessary to allow non-support of specific mask bits, then these need to be limited and the client needs guidance about determining the set of unsupported mask bits. [Previous Treatment]: The situation is complicated by the fact that a server may have multiple modules that enforce ACLs. For example, the enforcement for NFSv4.1 access may be different from, but not weaker than, the enforcement for local access, and both may be different from the enforcement for access through other protocols such as SMB (Server Message Block). So it may be useful for a server to accept an ACL even if not all of its modules are able to support it. [Author Aside]: The following paragraph does not provide helpful guidance and takes no account of the need of the the client to be able to rely on the server implementing protocol-specifying semantics and giving notice in those cases in which it is unable to so [Previous Treatment]: The guiding principle with regard to NFSv4 access is that the server must not accept ACLs that appear to make access to the file more restrictive than it really is.

Combining Authorization Models

Background for Combined Authorization Model Both and contain material relating to the need, when both mode and ACL attributes are supported, to make sure that the values are appropriately co-ordinated. Despite the fact that these discussions are different, they are compatible and differ in only a small number of areas relating to the existence absence of the set-mode-masked attribute. Such co-ordination is necessary is necessary since it is expected that servers providing both sets of attributes will encounter users who have no or very limited knowledge of one and need to work effectively when other users changes that attribute. As a result, these attributes cannot each be applied independently since that would create an untenable situation in which some users who have the right to control file access would find themselves unable to do so. [Author Aside]: From this point on, all paragraphs in this section, not other annotated are to be considered part of Consensus Item #63a. The description in this section of changes to be made reflects the author's proposal to address this issue and related issues. It might have to be adjusted based on working group decisions. As a result, in this document, we will have a single treatment of this issue, in Sections through . In addition, an NFSv4.2-based extension related to attribute co-ordination will be described in . The current NFSv4.0 and NFSv4.1 descriptions of this co-ordination share an unfortunate characteristic in that they are both written to give server implementations a broad latitude in implementation choices while neglecting entirely the need for clients and users to have a reliable description of what servers are to do in this area. As a result, one of the goals of this new combined treatment will be to limit the uncertainty that the previous approach created for clients, while still taking proper account of the possibility of compatibility issues that a more tightly drawn specification might give rise to. The various ways in which these kinds of issues have been dealt with are listed below together with a description of the needed changes proposed to address each issue.

In some cases, the term "MAY" is used in contexts where it is inappropriate, since the allowed variation has the potential to cause harm in that it leaves the client unsure exactly what security-related action will be performed by the server. The new treatment will limit use use of MAY to cases in which it is truly necessary, in order to give clients proper notice of cases in which server behavior cannot be determined and limit the work necessary to deal with a large array of possible behaviors.
There are also cases in which no RFC2119-defined keywords are used but it is stated that certain server implementations do a particular thing, leaving the impression that that action is to be allowed, just as if "MAY" had been used. If the flexibility is necessary, MAY will be used. In other cases, SHOULD will be used with the understanding that maintaining compatibility with clients that have adapted to a particular approach to this issue is a valid reason to bypass the recommendation. However, in no case will it be implied, as it is in the current specifications, that the server MAY do whatever it chooses, with the client having no option but to adapt to that choice.
There was a case, in , in which the term "SHOULD" was explicitly used intentionally, without it being made clear what the valid reasons to ignore the guidance might be, although there was a reference to servers built to support the now-withdrawn draft definition of POSIX ACLs, which are referred to in this document as "UNIX ACLs", as described in Section 4.1 of . A discussion of the issues for support of for these ACLs appears in . [Author Aside]: Despite the statement, now cited in , that this was to accommodate implementations "POSIX" ACLs, it now appears that this was not complete. I've been given to understand that this was the result of two groups disagreeing on the appropriate mapping from ACLs, and specifying both, using the "intentional" "SHOULD" essentially as a MAY, with the text now in discouraging such use as potentially confusing, not intended to be taken seriously. Since the above information might not be appropriate in a standards-track RFC, we intend to retain this as an Author Aside which the working group might consider as it discusses how to navigate our way out of this situation. The new approach will use the term "RECOMMENDED" without use of the confusing term "intentional". The valid reasons to bypass the recommendation will be clearly explained as will be the consequences of choosing to do other than what is recommended.
There are many case in which the terms "SHOULD" and "SHOULD NOT" are used without any clear indication why they were used. In this situation it is possible that the "SHOULD" was essentially treated as a "MAY" but also possible that servers chose to follow the recommendation. In order to deal with the many uses of these terms in and included subsections, which have no clear motivation, it is to be assumed that the valid reasons to act contrary to the recommendation given are the difficulty of changing implementations based on previous analogous guidance, which may have given the impression that the server was free to ignore the guidance for any reason the implementer chose. This allows the possibility of more individualized treatment of these instances once compatibility issues have been adequately discussed. [Author Aside]: In each subsection in which the the interpretation of these term in the previous paragraph applies there will be an explicit reference to Consensus Item #63, to draw attention to this change, even in the absence of modified text.

Needed Attribute Coordination On servers that support acl or dacl attributes, to gether with the mode attribute, the server needs to keep the two attributes consistent with one another. The value of the mode attribute (with the exception of the high-order bits reserved for client use as described in Section 5.3.2 of , are to be determined entirely by the value of the ACL, so that use of the mode is never required by ACL-aware clients for anything other than setting and interrogating the three high-order bits. See Sections through for detailed discussion. [Previous Treatment (Item #63b)]: When a mode attribute is set on an object, the ACL attributes may need to be modified in order to not conflict with the new mode. In such cases, it is desirable that the ACL keep as much information as possible. This includes information about inheritance, AUDIT and ALARM ACEs, and permissions granted and denied that do not conflict with the new mode. [Author Aside]: one the things that this formulation leaves uncertain, is whether, if the ACL specifies permission for a named user group or group, it "conflicts" with the node. Ordinarily, one might think it does not, unless the specified user is the owner of the file or a member of the owning group, or the specified group is the owning group. However, while some parts of the existing treatment seem to agree with this, other parts, while unclear, seem to suggest otherwise, while the treatment in is directly in conflict. [Previous Treatment (Item #26a)]: The server that supports both mode and ACL must take care to synchronize the MODE4_*USR, MODE4_*GRP, and MODE4_*OTH bits with the ACEs that have respective who fields of "OWNER@", "GROUP@", and "EVERYONE@". [Author Aside]: This sentence ignores named owners and group, giving the impressions that there is no need to change them. [Previous Treatment (Item #26a)]: This way, the client can see if semantically equivalent access permissions exist whether the client asks for the owner, owner_group, and mode attributes or for just the ACL. [Author Aside, Including List:] The above sentence, while hard to interpret for a number a reasons, is worth looking at in detail because it might suggest an approach different from the one in the previous sentence from the initial paragraph for The Previous Treatment of Item #26a.

The introductory phrase "this way" adds confusion because it suggests that there are other valid ways of doing this, while not giving any hint about what these might be.
It is hard to understand the intention of "client can see if semantically equivalent access permissions" especially as the client is told elsewhere that he is not to interpret the ACL himself.
If this sentence is to have any effect at all it, it would be to suggest that the result be the same "whether the client asks for the owner, owner_group, and mode attributes or for just the ACL." If these are to be semantically equivalent it would be necessary to delete ACEs for named users, which requires a different approach form the first sentence of the original paragraph.

{Consensus Needed, Including List (Items #26a, #28a)]: A server that supports both mode and ACL attributes needs to take care to synchronize the MODE4_*USR, MODE4_*GRP, and MODE4_*OTH bits with the ACEs that have respective who fields of "OWNER@", "GROUP@", and "EVERYONE@". This requires:

When the mode is changed, in most cases, the ACL attributes will need to be modified as described in .
When the ACL is changed, the corresponding mode is determined and used to set the nine low-oder bits of the mode attribute. This is relatively straightforward in the case of forward-slope modes, but the case of reverse-slope modes needs to be addressed as well. It is RECOMMENDED that the procedure presented in be used or another one that provides the same results. The valid reasons to bypass this recommendation together with a alternate procedures to be used are discussed in .

{Consensus Needed (Item #26a)]: How other ACEs are dealt with when setting mode is described in . This includes ACEs with other who values, all AUDIT and ALARM ACEs, and all ACES that affect ACL inheritance. [Previous Treatment (Item #27a)]: In this section, much depends on the method in specified . Many requirements refer to this section. It needs to be noted that the methods have behaviors specified with "SHOULD" and that alternate approaches are discussed in . This is intentional, to avoid invalidating existing implementations that compute the mode according to the withdrawn POSIX ACL draft (1003.1e draft 17), rather than by actual permissions on owner, group, and other. [Consensus (Item #27a)]: In performing the co-ordinarion discussed in this section, the method used to compute the mode from the ACL has an important role. While the approach specified in is RECOMMENDED, it needs to be noted that the alternate approaches discussed in are valid in some cases. As discussed in that section, an important reason for allowing multiple ways of doing this is to accommodate server implementations that compute the mode according to the withdrawn POSIX ACL draft (1003.1e draft 17), rather than by actual permissions on owner, group, and other. While, this means that a client, having no way of determining the method the server uses may face interoperability difficulties in moving between servers which approach this matter differently, these problems need to be accepted for the time being. A more complete discussion of handling of the UNIX ACLs is to be found in . [Consensus Needed, Including List (Items #27a, #28a)]: All valid methods of computing the mode from an ACL use the following procedure to derive a set of mode bits from a set of three ACL masks, with the only difference being in how the set of ACL masks is constructed. The calculated mask for for each set of bits in mode are derived from the ACL mask for owner, group, other are derived as follows:

Set the read bit (MODE4_RUSR, MODE4_RGRP, or MODE4_ROTH) if and only if ACE4_READ_DATA is set in the corresponding mask.
Set the write bit (MODE4_WUSR, MODE4_WGRP, or MODE4_WOTH) if and only if ACE4_WRITE_DATA and ACE4_APPEND_DATA are both set in the corresponding mask.
Set the execute bit (MODE4_XUSR, MODE4_XGRP, or MODE4_XOTH), if and only if ACE4_EXECUTE is set in the corresponding mask.

Computing a Mode Attribute from an ACL [Previous Treatment (Item #27b)]: The following method can be used to calculate the MODE4_R*, MODE4_W*, and MODE4_X* bits of a mode attribute, based upon an ACL. [Author Aside]: "can be used" says essentially "do whatever you choose" and would make essentially pointless. Would prefer "is to be used" or "MUST", with "SHOULD" available if valid reasons to do otherwise can be found. [Consensus Needed (Items #27b, #28b, #61f, #105m, #110f)}: The following method (or another one providing exactly the same results) SHOULD be used to calculate the MODE4_R*, MODE4_W*, and MODE4_X* bits of a mode attribute, when it can be dermined that the ACL in question is where it can determined one providing NFSv4 semantics in are to be provided in this respect. In this case, the only valid reason to bypass the recommendation is implementor reliance on previous specifications which left this to implementor or ignored the cases of the owner having less access than the owning group or the owning group having less access than others. Further, in implementing or the maintaining an implementation previously believed to be valid, the implementor needs to be aware that this will result in invalid values in some uncommon cases. Other reasons to do other than recommended are discussed in , along with the case of ACLs providing UNIX ACL semantics in this respect. [Author Aside, Including List]: The algorithm specified below, now considered the Previous Treatment associated with Item #24a, has an important flaw in does not deal with the (admittedly uncommon) case in which the owner_group has less access than the owner or others have less access than the owner-group. In essence, this algorithm ignores the following facts:

That GROUP@ includes the owning user while group bits in the mode do not affect the owning user.
That EVERYONE includes the owning group while other bits in the mode do not affect users within the owning group.

[Previous Treatment (Item #28b)]: First, for each of the special identifiers OWNER@, GROUP@, and EVERYONE@, evaluate the ACL in order, considering only ALLOW and DENY ACEs for the identifier EVERYONE@ and for the identifier under consideration. The result of the evaluation will be an NFSv4 ACL mask showing exactly which bits are permitted to that identifier. [Previous Treatment (Item #28b)]: Then translate the calculated mask for OWNER@, GROUP@, and EVERYONE@ into mode bits for, respectively, the user, group, and other, as follows: [Consensus Needed, including List(Item #28b)]: First, for each of the sets of mode bits (i.e., user, group other, evaluate the ACL in order, with a specific evaluation procedure depending on the specific set of mode bits being determined. For each set there will be one or more special identifiers considered in a positive sense so that ALLOW and DENY ACE's are considered in arriving at the mode bit. In addition, for some sets of bits, there will be one or more special identifiers to be considered only in a negative sense, so that only DENY ACE's are considered in arriving at the mode it. The users to be considered are as follows:

For the owner bits, "OWNER@" and "EVERYONE@" are to be considered, both in a positive sense.
For the group bits, "GROUP@" and "EVERYONE@" are to be considered, both in a positive sense, while "OWNER@" is to be considered in a negative sense.
For the other bit, "EVERYONE@" is to be considered in a positive sense, while "OWNER@" and "GROUP@" are to be considered in a negative sense.

[Consensus Needed (Item #28b)]: Once these ACL masks are constructed, the mode bits for, user, group, and other can be obtained as described in above.

Alternatives in Computing Mode Bits [Author Aside]: All unannotated paragraphs within this section are to be considered the Previous Treatment corresponding to Consensus Item #27c. Some server implementations also add bits permitted to named users and groups to the group bits (MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP). Implementations are discouraged from doing this, because it has been found to cause confusion for users who see members of a file's group denied access that the mode bits appear to allow. (The presence of DENY ACEs may also lead to such behavior, but DENY ACEs are expected to be more rarely used.) [Author Aside]: The text does not seem to really discourage this practice and makes no reference to the need to standardize behavior so the clients know what to expect or any other reason for providing standardization of server behavior. The same user confusion seen when fetching the mode also results if setting the mode does not effectively control permissions for the owner, group, and other users; this motivates some of the requirements that follow. [Author Aside]: The part before the semicolon appears to be relevant to Consensus Item #23 but does not point us to a clear conclusion. The statement certainly suggests that the 512-ACL approach is more desirable but the absence of a more direct statement to that effect suggest that this is a server implementer choice. [Author Aside]: The part after the semicolon is hard to interpret in that it is not clear what "this" refers to or which which requirements are referred to by "some of the requirements that follow". The author would appreciate hearing from anyone who has insight about what might have been intended here. [Consensus Needed, Including List (Items #27c, #61g, #105n, #110g)]: In cases in which the mode is not computed as described in , one of the following analogous procedures or their equivalents, MUST be used. This includes cases in which the ACL in question is one providing UNIX ACL semantics or explicitly noted as using this alternate procedure.

First, for each of the special identifiers OWNER@ and EVERYONE@, evaluate the ACL in order, considering only ALLOW and DENY ACEs for the identifier EVERYONE@ and for the identifier under consideration. For the special identifier GROUP@, ALLOW and DENY ACEs for GROUP@ and EVERYONE@ are to be considered, together with ALLOW ACEs for named users and groups. This represents the approach previously recommended to compute mode in previous specification, as modified to reflect the UNIX ACL practice of reflecting permissions for named users and groups. It does not deal properly with reverse-slope modes.
Compute a set of ACL mask according to the procedure in and then, for the mask associated with GROUP@, or in the masks for all ALLOW ACEs for named users and groups. This represents the approach currently recommended to compute mode in as modified to reflect the UNIX ACL practice of reflecting permissions for named users and groups.

[Consensus Needed, Including List (Item #27c)]: In both cases, The results of the evaluation will be a set of NFSv4 ACL masks which can be converted to the set on nine low-order mode bits using the procedure appearing in above. [Consensus Needed, Including List (Item #27c)]: When the recommendation to use is bypassed, it needs to be understood, that the modes derived will differ from the expected values and might cause interoperability issues. This is particularly the case when clients have no way to determine that the server's behavior is other than standard.

Handling of UNIX ACLs [Author Aside]: All paragraphs in this section are consider part of Consensus Item #63c. Although the working group did not adopt the acls in the withdrawn POSIX draft, their continued existence in UNIX contexts has created protocol difficulties that need to be resolved. In many cases these ACLS and their associated semantics are the basis for ACL support in UNIX client APIs and in UNIX file systems supported by NFSv4 Although the semantic range of UNIX ACLs is a subset of that for NFSv4 ACLs, expecting clients to perform that mapping on their own has not worked well, leading to the following issues which will, at some point, need to be addressed:

There is a considerable uncertainty about the proper mapping from ACLs to modes.
The corresponding mapping from modes to ACLs is dealt with different ways by different sections of the spec.
These individual uncertainties are compounded since it is difficult, in this environment, to ensure that these independently chosen mappings are inverses of one another, as they are intended to be.

Setting Multiple ACL Attributes In the case where a server supports the sacl or dacl attribute, in addition to the acl attribute, the server MUST fail a request to set the acl attribute simultaneously with a dacl or sacl attribute. The error to be given is NFS4ERR_ATTRNOTSUPP.

Setting Mode and not ACL (overall)

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 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:

If MODE4_RGRP is not set, entities explicitly listed in the ACL other than OWNER@ and EVERYONE@ SHOULD NOT be granted ACE4_READ_DATA.
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.
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 ).

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 , 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 ).

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 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 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 , 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.

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 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 and , 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 . 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 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 are provided.
For implementation of UNIX ACL, implememtation c suggestions appearing in are provided.
For implementation of various bybrid ACLs that do not provide support for DENY ACEs, implememtation suggestions appearing in 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 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 , 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 , 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.

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 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.

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@.

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 . 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.

Setting ACL and Not Mode [Author Aside]: The handling of SHOULD in this section is considered as part of Consensus Item #63d. When setting the acl or dacl and not setting the mode or mode_set_masked attributes, the permission bits of the mode need to be derived from the ACL. In this case, the ACL attribute SHOULD be set as given. The nine low-order bits of the mode attribute (MODE4_R*, MODE4_W*, MODE4_X*) MUST be modified to match the result of the method in . The three high-order bits of the mode (MODE4_SUID, MODE4_SGID, MODE4_SVTX) SHOULD remain unchanged.

Setting Both ACL and Mode When setting both the mode (includes use of either the mode attribute or the mode_set_masked attribute) and the acl or dacl attributes in the same operation, the attributes MUST be applied in the following order order: mode (or mode_set_masked), then ACL. The mode-related attribute is set as given, then the ACL attribute is set as given, possibly changing the final mode, as described above in .

Retrieving the Mode and/or ACL Attributes [Author Aside]: The handling of SHOULD in this section is considered as part of Consensus Item #63e. If a server supports any ACL attributes, it may use the ACL attributes on the parent directory to compute an initial ACL attribute for a newly created object. This will be referred to as the inherited ACL within this section. The act of adding one or more ACEs to the inherited ACL that are based upon ACEs in the parent directory's ACL will be referred to as inheriting an ACE within this section. Implementors need to base the behavior of CREATE and OPEN depending on the presence or absence of the mode and ACL attributes by following the directions below:

If just the mode is given in the call: In this case, inheritance SHOULD take place, but the mode MUST be applied to the inherited ACL as described in , thereby modifying the ACL.
If just the ACL is given in the call: In this case, inheritance SHOULD NOT take place, and the ACL as defined in the CREATE or OPEN will be set without modification, and the mode modified as in .
If both mode and ACL are given in the call: In this case, inheritance SHOULD NOT take place, and both attributes will be set as described in .
If neither mode nor ACL is given in the call: In the case where an object is being created without any initial attributes at all, e.g., an OPEN operation with an opentype4 of OPEN4_CREATE and a createmode4 of EXCLUSIVE4, inheritance SHOULD NOT take place (note that EXCLUSIVE4_1 is a better choice of createmode4, since it does permit initial attributes). Instead, the server SHOULD set permissions to deny all access to the newly created object. It is expected that the appropriate client will set the desired attributes in a subsequent SETATTR operation, and the server SHOULD allow that operation to succeed, regardless of what permissions the object is created with. For example, an empty ACL denies all permissions, but the server need to allow the owner's SETATTR to succeed even though WRITE_ACL is implicitly denied. In other cases, inheritance SHOULD take place, and no modifications to the ACL will happen. The mode attribute, if supported, MUST be as computed in , with the MODE4_SUID, MODE4_SGID, and MODE4_SVTX bits clear. If no inheritable ACEs exist on the parent directory, the rules for creating acl, dacl, or sacl attributes are implementation defined. If either the dacl or sacl attribute is supported, then the ACL4_DEFAULTED flag SHOULD be set on the newly created attributes.

Use of Inherited ACL When Creating Objects [Author Aside]: The handling of SHOULD in this section is considered as part of Consensus Item #63f. If the object being created is not a directory, the inherited ACL SHOULD NOT inherit ACEs from the parent directory ACL unless the ACE4_FILE_INHERIT_ACE flag is set. If the object being created is a directory, the inherited ACL is to inherit all inheritable ACEs from the parent directory, that is, those that have the ACE4_FILE_INHERIT_ACE or ACE4_DIRECTORY_INHERIT_ACE flag set. If the inheritable ACE has ACE4_FILE_INHERIT_ACE set but ACE4_DIRECTORY_INHERIT_ACE is clear, the inherited ACE on the newly created directory MUST have the ACE4_INHERIT_ONLY_ACE flag set to prevent the directory from being affected by ACEs meant for non-directories. When a new directory is created, the server MAY split any inherited ACE that is both inheritable and effective (in other words, that has neither ACE4_INHERIT_ONLY_ACE nor ACE4_NO_PROPAGATE_INHERIT_ACE set), into two ACEs, one with no inheritance flags and one with ACE4_INHERIT_ONLY_ACE set. (In the case of a dacl or sacl attribute, both of those ACEs SHOULD also have the ACE4_INHERITED_ACE flag set.) This makes it simpler to modify the effective permissions on the directory without modifying the ACE that is to be inherited to the new directory's children.

Combined Authorization Models for NFSv4.2 The NFSv4 server implementation requirements described in the subsections above apply to NFSv4.2 as well and NFSv4.2 clients can assume that the server follows them. NFSv4.2 contains an OPTIONAL extension, defined in , which is intended to reduce the interference of modes, restricted by the umask mechanism, with the acl inheritance mechanism. The extension allows the client to specify the umask separately from the mask attribute.

Other Uses of Access Control Lists Whether the Acl or Sacl attributes are used, AUDIT and ALARM ACEs provide security-related facilities separate from the the file access authorization provided by ALLOW and DENY ACEs

AUDIT ACEs provide a means to audit attempts to access a specified file by specified sets of principals.
ALARM ACEs provide a means to draw special attention to attempts to access specified files by specified sets of principals.

XDR to Support an NFSv4.2 Aclfeature Extension

Extraction of XDR This document contains the external data representation (XDR) description of the new open flags for delegating the file to the client. The XDR description is embedded in this document in a way that makes it simple for the reader to extract into a ready-to-compile form. The reader can feed this document into the following shell script to produce the machine readable XDR description of the new flags: That is, if the above script is stored in a file called "extract.sh", and this document is in a file called "spec.txt", then the reader can do: layout_wcc.x ]]> The effect of the script is to remove leading white space from each line, plus a sentinel sequence of "///". XDR descriptions with the sentinel sequence are embedded throughout the document. Note that the XDR code contained in this document depends on types from the NFSv4.2 nfs4_prot.x file (generated from ). This includes both nfs types that end with a 4, such as offset4, length4, etc., as well as more generic types such as uint32_t and uint64_t. While the XDR can be appended to that from , the various code snippets belong in their respective areas of the that XDR.

Code Components Licensing Notice Both the XDR description and the scripts used for extracting the XDR description are Code Components as described in Section 4 of "Legal Provisions Relating to IETF Documents". These Code Components are licensed according to the terms of that document. /// /* /// * Copyright (c) 2017 IETF Trust and the persons identified /// * as authors of the code. All rights reserved. /// * /// * Redistribution and use in source and binary forms, with /// * or without modification, are permitted provided that the /// * following conditions are met: /// * /// * o Redistributions of source code must retain the above /// * copyright notice, this list of conditions and the /// * following disclaimer. /// * /// * o Redistributions in binary form must reproduce the above /// * copyright notice, this list of conditions and the /// * following disclaimer in the documentation and/or other /// * materials provided with the distribution. /// * /// * o Neither the name of Internet Society, IETF or IETF /// * Trust, nor the names of specific contributors, may be /// * used to endorse or promote products derived from this /// * software without specific prior written permission. /// * /// * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS /// * AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED /// * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE /// * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS /// * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO /// * EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE /// * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, /// * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT /// * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR /// * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS /// * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF /// * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, /// * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING /// * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF /// * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. /// * /// * This code was derived from RFC 8276. /// * Please reproduce this note if possible. /// */

]]>



  
    XDR For Aclfeature Extesion

    

     /// /*
     ///  * aclfeat_prot.x
     ///  */

     /// /*
     ///  * The following includes statements that are for example only.
     ///  * The actual XDR definition files are generated separately
     ///  * and independently and are likely to have a different name.
     ///  * %#include 
     ///  * %#include 
     ///  */

     /// /*
     ///  * Core type definitions needed for new feature.
     ///  */
     
     /// typedef uint32_t        af4miword;
	    
     /// struct af4minfo {
     ///    af4miword       flagw;
     ///    acemask4        maskw;
     /// };

     /// typedef  uint32_t       af4typemask;
     /// typedef  uint32_t       af4flags;
     /// typedef  uint32_t       af4whoinf;

     /// /*
     ///  * Definition of the Aclfeature attribute.
     ///  */
     
     /// struct afeat4 {
     ///    af4typemask     tmask;
     ///    af4flags        flword;
     ///    af4whoinf       whoword;
     ///    af4minfo        maskinf<>;
     /// };

     /// /*
     ///  * Definitions to be used in interpreting words of type
     ///  * af4typemask.
     ///  */

     /// const AF4TYPE_GSUPPMASK         = 0x000003ff;
     /// const AF4TYPE_BSUPPMASK         = 0x000ffc00;
     /// const AF4TYPE_STOREMASK         = 0x3ff00000;
     /// const AF4TYPE_GSUPPSHIFT        = 0;
     /// const AF4TYPE_BSUPPSHIFT        = 10;
     /// const AF4TYPE_GSTORESHIFT       = 20;
     
     /// /*
     ///  * Definitions used in interpreting the maskw value within
     ///  * each af4minfo element within the maskinf array.
     ///  */
		
     /// 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;

     /// /*
     ///  * Definitions of the values used in  the support field
     ///  * within the masksw value.
     ///  */
     
     /// 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;
     
     /// /*
     ///  * Definitions of the values used in the object-type
     ///  * field within the masksw value.
     ///  */
     
     /// const ACLF4_MIF_DIR             = 0x00000008;
     /// const ACLF4_MIF_NDIR            = 0x00000010;
     /// const ACLF4_MIF_OALL            = 0x00000018;
     
     /// /*
     ///  * Definitions of the values used in the uses field
     ///  * within the masksw value. 
     ///  */
     
     /// const ACLF4_MIF_UAUTH           = 0x00000020;
     /// const ACLF4_MIF_UOTHR           = 0x00000040;
     /// const ACLF4_MIF_UALL            = 0x00000060;

     /// /*
     ///  * Definitions of the sub-fields placed within the basis field
     ///  * of the masksw value.
     ///  */

     /// 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;

     /// /*
     ///  * Values used withinn the basis number subfield of
     ///  * maskw value.
     ///  */

     /// 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;
     
     /// /*
     ///  * Values used withinn the basis type subfield of
     ///  * maskw value.
     ///  */
     
     /// 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;
     
     /// /*
     ///  * Definitions of flags used in each of the fields within words
     ///  * of type af4flags. 
     ///  */
     /// const AF4FLAG_INHFILE           = 0x00000001;
     /// const AF4FLAG_INDIR             = 0x00000002;
     /// const AF4FLAG_INHCHOICE         = 0x00000004;
     /// const AF4FLAG_INHAUTO           = 0x00000008;

     /// /*
     ///  * Definitions of the fields within words of type
     ///  * af4flags. 
     ///  */
     
     /// 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;

     /// /*
     ///  * Definition of flags within words of type af4whoinf.
     ///  */
     
     /// const AF4WHOI_AUTHSUPP          = 0x00000001;
     /// const AF4WHOI_AUTHSUPPC         = 0x00000002;
     /// const AF4WHOI_AUTHSTORE         = 0x00000004;
     /// const AF4WHOI_MISCSUPPA         = 0x00000008;
     /// const AF4WHOI_MISCSTORE         = 0x00000010;
     /// const AF4WHOI_OTHMODE           = 0x00000020;

     
      ]]>

      
      
	Security Considerations
	
	  There are no Security considerations specific to this
	  document.  Security considerations for NFSv4 as a whole are
	  dealt with in the Security Considerations section of
	  .
	
      

      
	IANA Considerations
	
	  This document requires no actions from IANA>


  
  
    References
    
      Normative References
       
       
       
       
       
       
       
       
    
    
      Informative References
       
       
    
  
  
    Issues for which Consensus Needs to be Ascertained
    
      This section helps to keep track of specific changes which the
      author has made or intends to make to deal with issues found
      in RFCs 7530 and 8881.  The changes listed here exclude those which
      are clearly editorial but includes some that the author believes are
      editorial but for which the issues are sufficiently complicated that
      working group consensus on the issue is probably necessary.
    
    
      These changes are presented in the table below, organized into a set
      of "Consensus Items" identified by the numeric code appearing  in
      annotations in the proposed document text.  For each such item,
      a type
      code is assigned with separate sets of code define for pending items
      and for those which are no longer pending.
    
    
      The following codes are defined for pending consensus items:
    
    
      
	"NM" denotes a change which is new material that is not purely
	editorial and thus requires Working Group consensus for
	eventual publication.
      
      
	"BE" denotes a change which the author believes is editorial but
	for which the change is sufficiently complex that the judgment
	is best
	confirmed by the Working Group.
      
      
	"BC" denotes a change which is a substantive change that the author
	believes is correct.  This does not exclude the possibility of
	compatibility issues becoming an issue but is used to indicate that
	the author believes any such issues are unlikely to prevent
	its eventual acceptance.
      
      
	"CI" denotes a change for which the potential for
	compatibility issues
	is a major concern with the expected result that working group
	discussion of change will focus on clarifying our knowledge of how
	existing clients and server deal with the issue and how they might
	be affected by the change or the change modified to
	accommodate them.
      
      
	"NS" denotes a change which represents the author's best effort to
	resolve a difficulty but for which the author is not yet
	confident that it will be adopted in its present form,
	principally because of the possibility of
	troublesome compatibility issues.
      
      
	"NE" denotes change based on an existing issue in
	the spec
	but for which the replacement text is incomplete and needs further
	elaboration.
      
      
	"WI" denotes a potential change based on an existing issue in
	the spec
	but for which replacement text is not yet available because
	further working group input is necessary before drafting.
	It is expected that replacement text
	will be available in a later draft once that discussion is done. 
      
      
	"LD" denotes a potential change based on an existing issue in the
	spec but for which replacement text is not yet available due to
	the press of time.   It is expected that replacement text
	will be available in a later draft.
      
      
	"EV" denote a potential change which is tentative or incomplete
	because further details need to be provide or because the author
	is unsure that he has a correct explanation of the issue.
	It is expected that replacement text
	will be available in a later draft.
      
    
    
      The following codes are defined for consensus items which are no
      longer pending.
    
    
      
	"RT" designates a former item which has been retired, because it
	has been merged with another one or otherwise organized out of
	existence. 
      
        Such items no longer are referred to the document source although
        the item id is never reassigned.  They are no longer counted
	among the set of total items.
      
      
	"CA" designates a former item for which consensus has been
	achieved in the judgment of the author, although not
	by any official process. 
      
        Items reaching this state are effected in the document source
        including the deletion of annotations and the elimination of
	obsoleted previous treatments.
      
        Items in this state are still counted among the total of item
        but are no longer considered pending        	
      
      
	"CV" designates a former item for which consensus has been
	achieved and officially verified. 
      
        Even though the author is a Working Group co-chair,it is
        probably best
	if he is not involved in this process and intends to leave it
	to the
	other co-chairs, the Document Shepherd and the Area Director. 
      
        Items in this state are not counted among the item totals.
        They may be kept in the table but only to indicate that the item id
	is still reserved.
      
      
	"DR" designates a former item which has been dropped, because it
	appears that working group acceptance of it, even with some
	modification, is unlikely.
      
        Such items no longer are referred to the document source although
        the item id is never reassigned.  They are no longer counted
	among the set of total items.	
      
    
    
      When asterisk is appended to a state of "NM", "BC" or "BE" it
      that there has been adequate working group discussion leading
      one to reasonably expect it will be adopted, without major change,
      in a subsequent document revision.
    
    
      Such general acceptance is not equivalent to a formal
      working group consensus and it not expected to result in major
      changes to the draft document,
    
    
      On the other hand, once there is a working group consensus with
      regard to a particular issue, the document will be modified to remove
      associated annotations, with the previously conditional text
      appearing just as other document text does.  The issue will remain
      in this table as a non-pending item. It will be mentioned in
      Appendix A of ,
      to summarize the
      changes that have been made.
    
    
      It is to be expected that these designations will change
      as discussion proceeds and new document versions are published.
      It is hoped that most such shifts will be upward in the above list or
      result in the deletion of a pending item, by reaching a consensus to
      accept or reject it.  This would enable, once all items are dealt with,
      an eventual request for publication as an RFC, with this appendix
      having been deleted.
    
    
      The consensus item in the followig table can be divided into three
      groups, based on the ssociated numeric id.
    
    
      
	Those with ids less than 62 were created as part of the security and
	documeny and transferred to this one as part of the doument split.
      
      
	Those with ids between 62 and 65 are the result of splitting
	item created as part of the security that now adress issues in bo
	both documents
      
      
	Those with id 100 and above were created after the document split.
	In most case, there is no connection to material within the
	security document.
      
    
    
      
	
	  #
	  Type
	  ...References...
	  Substance
	
      
      
	
          3
	  BE
	  
	    
	      #3a in S 
	    
	  
	  
	    
	      Conversion of mask bit descriptions from being about
	      "permissions" to being about the action permitted,
	      denied, or specified as being audited or generating
	      alarms.
	    
	  
	
	
          4
	  CI
	  
	    
	      #4a in S 
	    
	    
	      #4b in S 
	    
	    
	      #4c in S 
	    
	    
	      #4d in S 
	    
	    
	      #4e in S 
	    
	    
	      #4f in S 
	    
	    
	      #4g in S 
	    

	  

	  
	    
              Elimination of uses of SHOULD believed
	      inappropriate in the descriptions of ACEs and clarification
	      of ongoing use of SHOULD.
	    
	  
	
        
          5
	  NE
	  
	    
	      #5a in S 
	    
	    
	      #5b in S 
	    

	  
	  
	    
	      Changes needes in treatment of ACCESS, including the
	      following:
	    
	    
	      
		ACCESS is listed as an operation in all cases in which
		one of the bits returned by the operation ould be affected.
	      
	      
		There is now explcit indication of which bit(s) returned
		by ACCESS might be affected.
	      
	      
		There is now a discussion of differences between the
		effect on authorization and that on other uses of the
		associated mask biks for ACEs not conncted with authorization.
	      
	        Given the inability of the server to determine which bits
 	        are being tested by the client, determiing when success or
		failure has occurred is impossible.  As a result it appears
		best to given the server freedom, in any particular case,
		to decide whether an ACCESS has succeeed or failed in 
                determining whether it constitutes a recordable event.
	      
	      
	      
	    
	  
	
	
          7
	  BE
	  
	    
	      #7a in S 
	    
	    
	      #7b in S 
	    
	  
            
	  
	    
              Clarification of relationship between READ_DATA and EXECUTE.
	    
	  
	
	
          8
	  CI
	  
	    
	      #8a in S 
	    
	    
	      #8b in S 
	    
	    
	      #8c in S 
	    
	  

	  
	    
              Revised discussion of relationship between WRITE_DATA and
	      APPEND_DATA.

	    
	  
	
	
          9
	  CI
	  
	    
	      #9a in S 
	    
	    
	      #9b in S 
	    
	  

	  
	    
              Clarification of how ADD_DIRECTORY relates to RENAME. 
	    
	    
	      We are assuming that the cros-directory and within-directory
	      cases need to be treated differently.
	    
	  
	
        
          10
	  WI
	  
	    
	      #10a in S 
	    
	  

	  
	    
	      Possible revisions in handling of the masks WRITE_RETENTION and
	      WRITE_RETENTION_HOLD.
	    
	  
	
        
          11
	  CI
	  
	    
	      #11a in S 
	    
	  

	  
	    
              Explicit recommendation and requirements for mask	
	      granularity, replacing the previous treatment which gave
	      the server license to ignore most of the previous section,
	      placing clients in an unfortunate situation.
	    
	  
	
        
          12
	  BC
	  
	    
	      #12a in S 
	    
	    
	      #12b in S 
	    
	  

	  
	    
              Revised treatment of directory entry deletion.
	    
	  
	
	
          13
	  BC
	  
	    
	      #13a in 
	    
	    
	      #13b in 
	    
	    
	      #13c in 
	    
	    
	      #13d in 
	    
	  

	  
	    
              Attempt to put some reasonable limits on possible non-support
	      (or variations in the support provided) for the ACE flags.
	      This is to replace a situation in which the client has no real
	      way to deal with the freedom granted to server implementations.
	    
	  
				
	      
        
          14
	  BC
	  
	    
	      #14a in S 
	    
	    
	      #14b in S 
	    
	  

	  
	    
              Explicit discussion of the case in which aclsupport is
	      not supported.  
	    
	  
	
        
          15
	  BC
	  
	    
	      #15a in S 
	    
	  

	  
	    
              Handling of the proper relationship between support for
	      ALLOW and DENY ACEs. 
	    
	  
	
	
          16
	  NM
	  
	    
	      #16a in S 
	    
	  

	  
	    
              Discussion of coherence of acl, sacl, and dacl
	      attributes.
	    
	  
	
	
          26
	  CI
	  
	    
	      #26a in S 
	    
	    
	      #26 in S 
	    
	  

	  
	    
              Decide how ACEs with who values other than OWNER@,
	      Group, or EVERYONE@ are be dealt with when setting mode.

	    
	  
	
	
          27
	  CI
	  
	    
	      #27a in S 
	    
	    
	      #27b in S 
	    
	    
	      #27c in S 
	    
	  

	  
	    
              Concerns the possible existence of multiple methods of
	      computing a mode from an acl that clients can depend on,
	      and the proper relationship among these methods.
	    
	  
	
	
          28
	  WI
	  
	    	 
              #28a in S 
	    
	    
	      #28b in S 
	    
	    
	      #28 in S 
	    
	  
	  
	    
              Decide how to address flags in mapping to/from reverse-
	      slope modes.
	    
	  
	
	
          29
	  BC
	  
	    
	      #29 in S 
	    
	  

	  
	    
              Address the coordination of mode and ACL-based attributes
	      in a unified way for all minor versions.
	    
	  
	
	
          30
	  CI
	  
	    
	      #30a in S 
	    
	    
	      #30b in S 
	    
	    
	      #30c in S 
	    
	    
	      #30d in S 
	    
	    
	      #30e in S 
	    
	    
	      #30f in S 
	    
	    
	      #30g in S 
	    
	  
	  
	    
              New proposed treatment of setting mode incorporating
	      some consequences of anticipated decisions regarding
	      other consensus items (#26, #28, #29)
	    
	  
        
	
          31
	  WI
	  
	    
	      #31a in S 
	    
	  

	  
	    
              Need to deal with mask bits ACE4_READ_ATTRIBUTES,
	      ACE4_WRITE_RETENTION, ACE4_WRITE_RETENTION_HOLD,
	      ACE4_READ_ACL to reflect the semantics of the mode
	      attribute.
	    
	  
	
	
          50
	  BC
	  
	    
	      #50a in S 
	    
	    
	      #50b in S 
	    
	    
	      #50c in S 
	    
	  

	  
	    
	      Revise handling of "special" who values, making it clear
	      for which ones "special" is a euphemism for
	      "semantics-challenged".
   	    
	  
	
	
          51
	  BC
	  
	    
	      #51a in S 
	    
	  

	  
	    
	      Clarify the handling of the group bit for the special who
	      values.
   	    
	  
	
	
	  61
	  RT
	  
	    
	      #61a in S 
	    
	    
	      #61b in S 
	    
	    
	      #61c in S 
	    
	    
	      #61d in S 
	    
	    
	      #61e in S 
	    
	    
	      #61f in S 
	    
	    
	      #61g in S 
	    
	  

	  
	    
	      Proposal to distinguish support for UNIX and NFSv4 ACLS,
	      depending on the results returned by the Aclsupport attribute.
	    
	    
	      Modified to e conditional on the absence of Aclfeature
	      attribute because of the need to effectively handle hybrids.
	    
	    
	      Many previous instances of this item now include 
	      Item #105 as
	      well, since Aclfeature, when supported, replaces the attempt
              to infer the semantic model more simply.
	    
	  
	
	
	  62
	  NE
	  
	    
	      #62a in S 
	    
	  

	  
	    
	      New/revised description of the role of the "sticky bit"
	      for directories, with respect to ACL/ACE handling.
	    
	    
	      Needs to be considered together with Item #6 in the security
	      document proper.
	    
	  
	
	
          63
	  CI
	  
	    
	      #63a in S 
	    
	    
	      #63b in S 
	    
	    
	      #63c in S 
	    
	    
	      #63d in S 
	    
	    
	      #63e in S 
	    
	    
	      #63f in S 
	    
	  

	  
	    
              Revised description of co-ordination of acl and mode
	      attributes to apply to NFSv4 as a whole. While this includes
	      many aspects of the shift
	      to be more specific about the co-ordination
	      requirements including addressing apparently
	      unmotivated uses of the terms
	      "SHOULD" and "SHOULD NOT",
	      it excludes some arguably related
	      matters dealt with as Consensus Items #26 and #27.
	    
	    
	      Needs to be considered together with Item #25 in the security
	      document proper.
	    
	  
	
	
          64
	  WI
	  
	    
	      #64a in S 
	    
	  
	  
	    
	      Discussion of issues related to the handling of allowed
	      variants of the NFSv4 ACL model, including subsets based on
	      the Unix ACL model.
	    
	    
	      Needs to be considered together with Item #56 in the security
	      document proper.
	    
	  
	
	
	  65
	  NS
	  
	    
	      #65a 
	    
	    
	      #65b 
	    
	    
	      #65c 
	    
	  
	  
	    
	      Designation of the Acl, Dacl, and Sacl 
	      attributes as Experimental in previous specifications
              even though still formally
	      OPTIONAL.
	    
	    
	      Note that this is separate from the possibility of
	      sufficiently clarifying the description of the acl, dacl,
	      and sacl attributes to make the Experimental designation
	      unnecessary, or providing other means of semantic model 
	      discovery, which will be covered as Item #110.
	    
	    
	      Needs to be considered together with Item #58 in the security
	      document proper.
	    
	    
	  	  
	
	
	  100
	  NE
	  
	    
	    
	  
	  
	    
	      Needs to be considered together with Item #66 in the security
	      document wich deal with parallel issues regarding POSIX-based
	      authorization.
	    
	    
	      Address issues regarding ACE4_{READ,WRITE}_NAMED_ATTRIBUTES.
	    
	  
	
	
	  101
	  NM
	  
	     
	      #101a in S 
	    
	  

	  
	    
	      Inclusion of the action of READLINK as authorized by
	      ACE4_READ_DATA
	    
	  
	
	
	  102
	  NE
	  
	     
	      #102a in S 
	    
	     
	      #102b in S 
	    
	  

	  
	    
	      Mask bits have to be dealt with that are not simply
	      finer-grained correlates of the three POSIX privilege bits.
	    
	  
	
	
	  103
	  NM
	  
	     
	      #103a in S 
	    
	  

	  
	    
	      Classification of masks bits based on relationship to
	      permission bits and existence of implementations.
	    
	  
	
	
	  104
	  NE
	  
	     
	      #104a in S 
	    
	  

	  
	    
	      Presentation of UNIX ACLs as the basis of the feature, rather than
	      the possibly aspirational NFSv4 ACLs
	    
	    
	      Includes work to mention of deletion of Extension features
	      that were never
	      implemented, where the WG agrees.
	    
	  
	
	
	  105
	  NE
	  
	     
	      #105a in S 
	    
	     
	      #105b in S 
	    
	     
	      #105c in S 
	    
	    
	      #105d in S 
	    
	    
	      #105e in S 
	    
	    
	      #105f in S 
	    
	    
	      #105g in S 
	    
	    
	      #105h in S 
	    
	    
	      #105i in S 
	    
	    
	      #105j in S 
	    
	    
	      #105k in S 
	    
	    
	      #105l in S 
	    
	    
	      #105m in S 
	    
	    
	      #105n in S 
	    
	    
	  

	  
	    
	      Support for discovery of ACL extensions using the Aclfeature
	      attribute or by using inference rules, to help in those case
	      in which it is not supported.
	    
	    
	      Presumes Item #104 has been implemented as well.
	    
	  
	
	
	  106
	  BC
	  
	     
	      #106a in S 
	    
	     
	      #106b in S 
	    

	  
	  
	    
              More detail about cases in which OPEN is affected by
	      ACE mask bits, including the dependence on the type of
	      OPEN.
	    

	  
	
	
	  107
	  BC
	  
	     
	      #107a in S 
	    
	     
	      #107b in S 
	    
	  
	  
	    
              More detail about use of ACE4_WRITE_DATA and the
	      dependence on the support for finer-grained bits
	      in descriptions of ACE mask bits.
	    
	  
	
	
	  108
	  BC
	  
	    
	    
	  
	  
	    
	      Distinguish mask bit treatments depending on the type of
	      the objects
	    
	  
	
	
	  109
	  BC
	  
	    
	    
	  
	  
	    
	      More detail about cases in which RENAME is affected by ACE
	      mask bits including the dependence on the directories for
	      wich the mask bits, distinguising the within-directory and
	      cross-directory cases, and dealing appropiately with the
	      rename-over case.
	    
	  
	
	
	  110
	  NM
	  
	    
	      #110a in S 
	    
	    
	      #110b in S 
	    
	    
	      #110c in S 
	    
	    
	      #110d in S 
	    
	    
	      #110e in S 
	    
	    
	      #110f in S 
	    
	    
	      #110g in S 
	    
	  
	  
	    
	      Make explicit reference to the ACL semantics provided
	      by the server, assuming this can be known somehow, rather
	      than by hand-wavily assuming that clients will somehow
	      get by.
	    
	    
	      Assumes that Item #61 or #105 is present or some
	      replacement.
	    
	  
	
	
	  111
	  WI
	  
	    
	      #111a in S 
	    
	    
	      #111b in S 
	    
	    
	      #111c in S 
	    
	    
	      #111d in S 
	    
	  
	  
	    
	      Addresss more substantively the handling of the mask bits
	      ACE4_{READ,WRITE}_NAMED_ATTRIBUTES.
	    
	    
	      Part of the eventual necessary resolution,
	      most likely best deferred
	      until we learn about an actual implementation, will need to
	      tackle serously the question of whether
	      ACE4_WRITE_NAMED_ATTRIBUTES is somehow a
	      finer-grained variant of the write privilege bits.
	      While this is arguanle despite it refers to a different
	      object, the coresponding issue with regard to
	      ACE4_READ_NAMED_ATTRIBUTES is more troublesome in that it
	      is a finer-grained variant of the or of two privilege bits:
	      R and X.
	    
	  
	
	
	  112
	  WI
	  
	    #112a in S 
	  
	  
	    
	      Address the validity/utility of ACE4_READ_ATTRIBUTES.  This
	      might be unnecessary, if Aclfearure were implemented, since
	      non-support would be a available as an option likely
	      to be commonly chosen.
	    
	  
	
	
	  113
	  NE
	  
	    #113a in S 
	  
	  
	    
	      Clarify how ACE mask bits defined in
	       are to be dealt with
	      by clients when the server does nt spport those mask bits, as
	      migh be the case when he server supports the UNIX ACL model.
	    
	  
	
      
    

    
      The following table summarizes the issues in each particular
      state.
    
    
      
	
	  Type
	  Cnt
	  Detail
	
      
      
	
	  BC
	  11
	  
	    
	      12, 13, 14, 15
	    
	    
	      29, 50, 51
	    
	    
	      106, 107, 108, 108
	    
	  
	
	
	  BE
	  2
	  
	    
	      3, 7
	    
	  
	
	
	  CI
	  8
	  
	    
              4, 8, 9, 11
            
              
	      26, 27, 30, 63 
	    
	  
	
	
	  EI
	  7
	  
	    
	      5, 62, 100, 102
	    
	    
	      104, 105, 113
	    
	  
	
	
	  NM
	  4
	  
	    
	      16, 101, 103, 110
	    
	  
	
	
	  NS
	  1
	  
	    
	      65
	    
	  
	
	
	  WI
	  6
	  
	    
	      10, 28, 31, 64 
	    
	    
              111, 112
	    
	  
	
	
	  Non-terminal)
	  39
	  
	    
	      BC, BE, CI, NE
	    
	    
              NM, NS, WS
	    
	  
	
	
	  RT
	  1
	  
	    
	      61
	    
	  
	
	
	  Terminal
	  1
	  
	    
	      RT
	    
	  
	

	
	  All
	  40
	  
	    
	      Grand total for above table.
	    
	  
	


      
    
  
  
    Acknowledgments

    
      The author wishes to thank Tom Haynes for his helpful suggestion
      to deal with security for all NFSv4 minor versions in the same
      document.
    
    
      The author wishes to draw people's attention to Nico Williams'
      remark that NFSv4 security was not so bad, except that there was
      no provision for authentication of the client peer.  This
      perceptive remark, which now seems like common sense, did not seem
      so when made, but it has served as a beacon for those working
      on putting NFSv4
      security on a firmer footing.  We appreciate Nico's perceptive
      guidance.
    
    
      The author wishes to thank Bruce Fields for his helpful comments
      regarding ACL support which had a major role in the evolution
      of this document.
    
    
      The author wishes to acknowledge the important role of the authors
      of RPC-with-TLS, Chuck Lever and Trond Myklebust, in moving the
      NFS security agenda forward and thank them for all their efforts
      to improve NFS security.
    
    
      The author wishes to thank Chuck Lever for his many helpful
      comments about nfsv4 security issues, his explanation of many
      unclear points, and much important guidance he provided that
      is reflected in this document, including his work to streamline
      the security negotiation process by the definition of new
      pseudo-flavors.
    
    
      The author wishes to thank Rick Macklem for his help in 
      resolving NFSv4 security issues.  These include
      clarifying possible server policies regarding RPC-with-TLS, helping
      to clarify "owner-override semantics" and
      bringing to the Working Group's attention the possibility of
      deriving limited principal identification from client peer authentication
      while still staying within the boundaries of RPC-with-TLS.

#	Type	...References...	Substance
3	BE	#3a in S	Conversion of mask bit descriptions from being about "permissions" to being about the action permitted, denied, or specified as being audited or generating alarms.
4	CI	#4a in S #4b in S #4c in S #4d in S #4e in S #4f in S #4g in S	Elimination of uses of SHOULD believed inappropriate in the descriptions of ACEs and clarification of ongoing use of SHOULD.
5	NE	#5a in S #5b in S	Changes needes in treatment of ACCESS, including the following: ACCESS is listed as an operation in all cases in which one of the bits returned by the operation ould be affected. There is now explcit indication of which bit(s) returned by ACCESS might be affected. There is now a discussion of differences between the effect on authorization and that on other uses of the associated mask biks for ACEs not conncted with authorization. Given the inability of the server to determine which bits are being tested by the client, determiing when success or failure has occurred is impossible. As a result it appears best to given the server freedom, in any particular case, to decide whether an ACCESS has succeeed or failed in determining whether it constitutes a recordable event.
7	BE	#7a in S #7b in S	Clarification of relationship between READ_DATA and EXECUTE.
8	CI	#8a in S #8b in S #8c in S	Revised discussion of relationship between WRITE_DATA and APPEND_DATA.
9	CI	#9a in S #9b in S	Clarification of how ADD_DIRECTORY relates to RENAME. We are assuming that the cros-directory and within-directory cases need to be treated differently.
10	WI	#10a in S	Possible revisions in handling of the masks WRITE_RETENTION and WRITE_RETENTION_HOLD.
11	CI	#11a in S	Explicit recommendation and requirements for mask granularity, replacing the previous treatment which gave the server license to ignore most of the previous section, placing clients in an unfortunate situation.
12	BC	#12a in S #12b in S	Revised treatment of directory entry deletion.
13	BC	#13a in #13b in #13c in #13d in	Attempt to put some reasonable limits on possible non-support (or variations in the support provided) for the ACE flags. This is to replace a situation in which the client has no real way to deal with the freedom granted to server implementations.
14	BC	#14a in S #14b in S	Explicit discussion of the case in which aclsupport is not supported.
15	BC	#15a in S	Handling of the proper relationship between support for ALLOW and DENY ACEs.
16	NM	#16a in S	Discussion of coherence of acl, sacl, and dacl attributes.
26	CI	#26a in S #26 in S	Decide how ACEs with who values other than OWNER@, Group, or EVERYONE@ are be dealt with when setting mode.
27	CI	#27a in S #27b in S #27c in S	Concerns the possible existence of multiple methods of computing a mode from an acl that clients can depend on, and the proper relationship among these methods.
28	WI	#28a in S #28b in S #28 in S	Decide how to address flags in mapping to/from reverse- slope modes.
29	BC	#29 in S	Address the coordination of mode and ACL-based attributes in a unified way for all minor versions.
30	CI	#30a in S #30b in S #30c in S #30d in S #30e in S #30f in S #30g in S	New proposed treatment of setting mode incorporating some consequences of anticipated decisions regarding other consensus items (#26, #28, #29)
31	WI	#31a in S	Need to deal with mask bits ACE4_READ_ATTRIBUTES, ACE4_WRITE_RETENTION, ACE4_WRITE_RETENTION_HOLD, ACE4_READ_ACL to reflect the semantics of the mode attribute.
50	BC	#50a in S #50b in S #50c in S	Revise handling of "special" who values, making it clear for which ones "special" is a euphemism for "semantics-challenged".
51	BC	#51a in S	Clarify the handling of the group bit for the special who values.
61	RT	#61a in S #61b in S #61c in S #61d in S #61e in S #61f in S #61g in S	Proposal to distinguish support for UNIX and NFSv4 ACLS, depending on the results returned by the Aclsupport attribute. Modified to e conditional on the absence of Aclfeature attribute because of the need to effectively handle hybrids. Many previous instances of this item now include Item #105 as well, since Aclfeature, when supported, replaces the attempt to infer the semantic model more simply.
62	NE	#62a in S	New/revised description of the role of the "sticky bit" for directories, with respect to ACL/ACE handling. Needs to be considered together with Item #6 in the security document proper.
63	CI	#63a in S #63b in S #63c in S #63d in S #63e in S #63f in S	Revised description of co-ordination of acl and mode attributes to apply to NFSv4 as a whole. While this includes many aspects of the shift to be more specific about the co-ordination requirements including addressing apparently unmotivated uses of the terms "SHOULD" and "SHOULD NOT", it excludes some arguably related matters dealt with as Consensus Items #26 and #27. Needs to be considered together with Item #25 in the security document proper.
64	WI	#64a in S	Discussion of issues related to the handling of allowed variants of the NFSv4 ACL model, including subsets based on the Unix ACL model. Needs to be considered together with Item #56 in the security document proper.
65	NS	#65a #65b #65c	Designation of the Acl, Dacl, and Sacl attributes as Experimental in previous specifications even though still formally OPTIONAL. Note that this is separate from the possibility of sufficiently clarifying the description of the acl, dacl, and sacl attributes to make the Experimental designation unnecessary, or providing other means of semantic model discovery, which will be covered as Item #110. Needs to be considered together with Item #58 in the security document proper.
100	NE		Needs to be considered together with Item #66 in the security document wich deal with parallel issues regarding POSIX-based authorization. Address issues regarding ACE4_{READ,WRITE}_NAMED_ATTRIBUTES.
101	NM	#101a in S	Inclusion of the action of READLINK as authorized by ACE4_READ_DATA
102	NE	#102a in S #102b in S	Mask bits have to be dealt with that are not simply finer-grained correlates of the three POSIX privilege bits.
103	NM	#103a in S	Classification of masks bits based on relationship to permission bits and existence of implementations.
104	NE	#104a in S	Presentation of UNIX ACLs as the basis of the feature, rather than the possibly aspirational NFSv4 ACLs Includes work to mention of deletion of Extension features that were never implemented, where the WG agrees.
105	NE	#105a in S #105b in S #105c in S #105d in S #105e in S #105f in S #105g in S #105h in S #105i in S #105j in S #105k in S #105l in S #105m in S #105n in S	Support for discovery of ACL extensions using the Aclfeature attribute or by using inference rules, to help in those case in which it is not supported. Presumes Item #104 has been implemented as well.
106	BC	#106a in S #106b in S	More detail about cases in which OPEN is affected by ACE mask bits, including the dependence on the type of OPEN.
107	BC	#107a in S #107b in S	More detail about use of ACE4_WRITE_DATA and the dependence on the support for finer-grained bits in descriptions of ACE mask bits.
108	BC		Distinguish mask bit treatments depending on the type of the objects
109	BC		More detail about cases in which RENAME is affected by ACE mask bits including the dependence on the directories for wich the mask bits, distinguising the within-directory and cross-directory cases, and dealing appropiately with the rename-over case.
110	NM	#110a in S #110b in S #110c in S #110d in S #110e in S #110f in S #110g in S	Make explicit reference to the ACL semantics provided by the server, assuming this can be known somehow, rather than by hand-wavily assuming that clients will somehow get by. Assumes that Item #61 or #105 is present or some replacement.
111	WI	#111a in S #111b in S #111c in S #111d in S	Addresss more substantively the handling of the mask bits ACE4_{READ,WRITE}_NAMED_ATTRIBUTES. Part of the eventual necessary resolution, most likely best deferred until we learn about an actual implementation, will need to tackle serously the question of whether ACE4_WRITE_NAMED_ATTRIBUTES is somehow a finer-grained variant of the write privilege bits. While this is arguanle despite it refers to a different object, the coresponding issue with regard to ACE4_READ_NAMED_ATTRIBUTES is more troublesome in that it is a finer-grained variant of the or of two privilege bits: R and X.
112	WI	#112a in S	Address the validity/utility of ACE4_READ_ATTRIBUTES. This might be unnecessary, if Aclfearure were implemented, since non-support would be a available as an option likely to be commonly chosen.
113	NE	#113a in S	Clarify how ACE mask bits defined in are to be dealt with by clients when the server does nt spport those mask bits, as migh be the case when he server supports the UNIX ACL model.

Type	Cnt	Detail
BC	11	12, 13, 14, 15 29, 50, 51 106, 107, 108, 108
BE	2	3, 7
CI	8	4, 8, 9, 11 26, 27, 30, 63
EI	7	5, 62, 100, 102 104, 105, 113
NM	4	16, 101, 103, 110
NS	1	65
WI	6	10, 28, 31, 64 111, 112
Non-terminal)	39	BC, BE, CI, NE NM, NS, WS
RT	1	61
Terminal	1	RT
All	40	Grand total for above table.