ACLs within the NFSv4 Protocols

1.1. Relationship to the Overall Security Document

This document is best understood when it is read together with [I-D.dnoveck-nfsv4-security] which discusses 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 [I-D.dnoveck-nfsv4-security].¶

For the most part, these two documents are independent, except for the inter-document references discussed above. However, the following exceptions should be noted:¶

• Section 1 of [I-D.dnoveck-nfsv4-security], in its entirety, applies to both documents, even in the absence of explicit inter-document references.¶
• The terminology defined in Section 4.1 of [I-D.dnoveck-nfsv4-security] in intended to be used in either document, without an explicit inter-document reference for each use.¶
• The sections dealing with Security Considerations and IANA Considerations appearing in [I-D.dnoveck-nfsv4-security], 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 [I-D.dnoveck-nfsv4-security], 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 Appendix B of [I-D.dnoveck-nfsv4-security], 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 are the descendants of consensus items affecting material now in multiple documents.¶

1.2. Relationship to the V4.1 Respecification Effort

This document is a necessary part of the rfc5661bis effort which seeks to provide an updated and corrected specification of NFSv4 Minor Version One. Since ACLs are part of that minor version, a corrected and updated specification of the processing of ACLs would be required as part of that effort.¶

However, given the wide scope of the ACL model presented in [RFC3530] and subsequent specifications and the wide allowances made in those documents for non-implementation of various elements of that specification, there is necessarily a great deal of uncertainty about the necessary scope of a respecification. Many features might have never been implemented by servers or used by clients and could have been purely speculative when described.¶

This situation is complicated by the long time between the initial inclusion of this package of features and now. In many cases, there might not be a clear understanding of the gaps between the feature set in the specification and that commonly implemented.  In addition, gaps between the specification and implementation of protocol elements which were implemented may not have been understood or were forgotten after implementation work in this area ceased. The practices discussed in Section 3.3 and the attitudes that led to them, make it likely that this would happen without extensive attention being devoted to regularizing this situation.¶

[Consensus Needed (Items #104b, #105b, #110a, #114a), Through end of section]:¶

Since we now consider the extensions to the core UNIX ACL model as OPTIONAL features, we have a framework to consider the suitability of these extensions to the protocol. We are now in a different situation from that confronting the working group when the original approach to ACLs was first arrived at. At that time, the idea of conceiving of these extensions as individually selectable OPTIONAL features was not available.¶

In any case, the realities that make that view appropriate now existed then as well. The way in which the Working Group chose to accommodate the situation have left us with a set of challenging issues that have been exacerbated by the passage of time, as described in Section 3.5.¶

It appears that the specification of ACLs to be done as part of the rfc561bis effort cannot include all of the possible features we are able to identify since:¶

• Some of these features might not have been implemented due to a lack of interest in the feature.¶

• There could have been issues exposed by implementation attempts that might have excluded them as candidates for implementation.¶

• Many of the issues that made these difficult-to-implement in some environments (e.g. UNIX) might have been more refractory than expected.¶

• Even where none of the above issues exist, it might not be able to research the relevant issues in a reasonable time.¶

Since it appears impossible to resolve all the questions left unanswered since ACLs were included in the protocol, it appears necessary to focus on the most important subsets in the near term while allowing further development to proceed in later minor versions. The two important feature subsets are:¶

• The feature set of the core UNIX ACL model, which is the subset that that servers are essentially required to implement and which clients have been capable of using so far.¶

  Because of the way previous specifications chose to deal with expected server behavioral diversity (see Section 3.3), there is considerable work involved in identifying probable sources of diversity and making the choices allowed into OPTIONAL features that the client is to be made aware of.¶

• [Consensus Needed (Item #117c), Through end of bulleted item]: The subset of extensions to the core UNIX ACL model intended to allow support of NFsv4 ACLs by servers and server-side file systems originally implemented to provide the functionality to support the draft POSIX ACL model.¶

  For reasons discussed in more detail in Section 3.4, this subset had been mostly ignored. As a result, clarifying the relationship between draft POSIX ACLs and NFsv4 ACLs is an essential part of our work, although providing full support for POSIX ACL semantics on either the client or server is unlikely to be doable as part of the respecification effort, for reasons made clear in in Section 5.2. Possible ways of addressing issues outside the respecification effort are discussed in Appendix C.¶

Work involving extensions to support the remainder of the extensions within the NFSv4 ACL model will necessarily have a lower priority. Nevertheless, the effort done to identify the extensions will make it possible for clients to use these extensions. Work will be necessary in later minor versions to decide which of these extensions make sense, to remove those that don't, and to make sure clients and server can use these extensions interoperably.¶

The likely work to be completed as part of the NFSv4.1 respecification is discussed below:¶

• The work to provide interoperability needs to focus on the core ACL features, each of which is part of the UNIX ACL subset. This will include the interaction of clients depending on this functionality to interoperably interact with servers that support any of the extensions within the more inclusive NFSv4 ACL model.¶

  The inclusion of two different means of computing modes from ACLs is a flaw that is desirable to remove, but that is probably not possible to eliminate now given the likely existence of servers implementing these two approaches. The possibility of making this a client choice will be deferred to a later minor version as discussed in Appendix D.2¶

  Unless other issues arise, the current draft is expected to provide this level of interoperability, for those not depending on any of the extensions.¶

• Consensus Needed (Item #117c)]: For clients depending on the NFSv4 extensions necessary to support the draft POSIX ACL model, we will need to provide clarification of the semantic differences between NFSv4 ACLs and draft POSIX ACLs. The result of this clarification is to eliminate unrealistic expectations regarding the ability of mappings between these two models to provide adequate support. For discussion of the basic elements of that support, man of which will not be available in NFsv4.1, see Section 5.2.¶

• For clients depending on some of the other NFSv4 extensions, the situation is different in that we will try to provide interoperability, but we have to prepared for the possibility that it will not be possible to provide it in time for the completion of the rfc5661bis effort.¶

  We will give priority to features used by clients for which server implementations exist. While we hope to find no noteworthy behavioral variants, giving us a specification supporting interoperability, that is not guaranteed but we do have the option, as described in Section 12.1 of allowing multiple variants for now and working toward a common approach in later drafts or in subsequent minor versions.¶

• There will probably be features for which there is no prospect of either client use or server implementations. Although this raises the possibility of eventually deleting such never-implemented proposed features, this will not happen before the end of the respecification effort.¶

  Such feature deletions would only be possible in a new minor version that allows features to be designated mandatory-to-not-implement, as described in Section 12.1.¶

1.3. Protocol Defects That Might Need to be Corrected

Although normally, protocol respecifications in bis documents do not modify the protocol and focus instead on clarifications, there are provisions within [RFC8178] to provide needed OPTIONAL extensions as a means of correcting protocol defects.¶

Determining what issues are sufficiently important to justify taking that step is best left to the judgment of the working group. In this draft, I have limited its use to defects that sufficiently compromise the usefulness of the either of two ACL model as to make that model essentially unusable. The following possibilities were considered:¶

• The lack of any way to determine which of the extensions to the core UNIX ACL model is supported by a particular server. This includes the majority of ACE mask bits, the ACE flags, all of which are effectively OPTIONAL, and various allowed behavioral differences with significant semantic consequences.¶

  This issue has been addressed by the creation of the OPTIONAL attribute Aclchoice¶

• The different handling of partial satisfaction of ALLOW ACEs by draft POSIX ACLs and non-POSIX ACLs appeared to require a means for clients to make visible their different requirements in this regard.¶

  The option of defining a new ACE4_NPS_ACE flag to allow the client to request the proper handling of this situation was seriously considered. However, as this issue turned out to be only a small part of the different approaches of the two ACL model in resolving authorization questions, the choice was made to defer resolving this issue in NFsv4.1 and address it later as described in Appendix C.¶

• The handling of ACL inheritance by means of default ACLs was not supported despite the intention to consider valid servers supporting the draft POSIX ACL model. From the viewpoint of the Supersession Narrative referred to in Section 3.2, the included ACEs could be dealt with as inherit-only ACEs applying to all object types but that made the necessary adaptation by draft POSIX ACL clients unduly difficult.¶

  This issue could have been addressed by defining the ACE4_DEFAULT_ACE flag to allow the client to specify that an inherit-only ACE applying to both file and subdirectories would be treated as part of a default ACL, not normally modified when ACLs were set on an object. To complement this, flags were to be added to the aclflag4 word in the sacl and dacl attributes to allow control of which acl(s) were to be modified.¶

  Eventually, it was decided to defer this item as well and address it later by using a separate attribute for default ACLs as described in Appendix C.¶

• [Consensus Needed (Item #117d), Through end of bulleted item]: Because the existing definition of the OWNER@, GROUP@, and EVERYONE made it impossible to translate reverse-slope modes to ACLs unless DENY ACEs (not part of draft POSIX ACLs) were supported, it was considered whether it was necessary to define the special users GROUPNOTOWNER@ and OTHERS@ and to provide Aclchoice support to indicate the presence of handling of these special who values.¶

  Eventually, it was decided not to do this and instead to warn implementors of the unfortunate consequences of non-support despite its formal status as OPTIONAL. This is despite the previous use of "SHOULD" which was not taken seriously because of its clear contradiction of the intention to allow use of servers supporting draft POSIX ACLs which have no DENY ACEs. See Section 3.4 for more details.¶

As a result, the only protocol extension provided was the addition of the Aclchoice attribute. See Section 4.6 for further discussion of this attribute, its motivation, and the reason that its absence needed to be treated as a defect.¶

2.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.2. 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 [I-D.dnoveck-nfsv4-security], 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 [RFC2119]), 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 have been used in accord with [RFC2119], 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.¶

2.3. Use of the Term "SHOULD

[Consensus Needed (Item #4a), Through end of Section]:¶

The use of the BCP14-defined term "SHOULD" merits particular attention because of its mistaken use common 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 characteristics 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 [RFC2119].¶

• In some cases, specific uses of the term were described as "intentional", with the apparent implication that the reason for the use of this term was to allow implementations to ignore the recommended action simply because it was felt to be inconvenient. The effect was that such uses of "SHOULD" were interpreted as "MAY" with the added expectation that implementations 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 [RFC2119] 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 threshold 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 to conform to the recommendation would constitute a valid reason to bypass the recommendation, the effect on feature interoperability notwithstanding.¶

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 [I-D.dnoveck-nfsv4-security], 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 further valid reasons to bypass the recommendation unless those are explicitly mentioned.¶

• That when reporting implementation characteristics (e.g. by use of the Aclchoice attribute) the right to bypass a recommendation is not to be accepted does not allow an implementer to report the recommendation as being adhered to.¶

• That clients are under no obligation to accept such variances from these recommendations and MAY, as the implementors judge prudent, decide to not use the ACL feature or to restrict its use to avoid reliance on particular troublesome instance of recommendations being bypassed.¶

3.1. Nature of the Existing Problems

[Consensus Needed (Item 104d), Through end of section]:¶

Acl handling within the NFSv4 protocols is in an unsatisfactory state, characterized by a troubling level of underspecification that:¶

• Leaves potential implementers unsure about what is needed to implement the feature.¶

• Provides no reasonable way for the client to determine what part of the existing feature specifications a server implements.¶

• Puts interoperability essentially beyond reach.¶

3.2. Probable Problem Sources

[Consensus Needed (Item #104d), Through end of section]:¶

Existing difficulties appear to have arisen from a misguided attempt to accommodate two very different approaches to the issue of providing ACL support within NFSv4, each one with its own strengths and weaknesses:¶

• An approach based on a subset of ACL work being done for local UNIX file systems. This was consistent with the pattern used in earlier versions of NFS in which the focus the effort was on making file system functions previously accessible locally available over a network.¶

  [Consensus Needed (Items #105d, #117e), Through end of bulleted list]: In this document, we refer to this approach as the core UNIX ACL model. Although this approach was derived from the now-withdrawn POSIX draft ACLs there are some elements of the latter that are considered distinct and turned out not to be representable within the NFsv4 ACL model. These include the approach to computing Mode based on an ACL, the handling of partial satisfaction of authorization requests using ALLOW ACEs, and the method of supporting ACL inheritance (described as "default ACLs" in the POSIX drafts).¶

  While this approach would have provided a relatively simple path toward implementation on both the client and server sides, it was eventually not chosen.¶

  Unfortunately, it was never made clear what specific gaps caused that result and it still remains unclear to what degree the extensions made available by a more ambitious approach could be used by UNIX clients, even if they could be successfully implemented on the server side.¶

• A more ambitious approach not so strongly tied to the UNIX ecosystem. This eventually turned out to be one based on Windows ACLs.¶

  Although many elements of this more ambitious approach have been implemented, it is not clear that the more ambitious approach, which we refer to as the NFSv4 ACL model was ever implemented by any server.¶

The more ambitious approach to providing ACL support was added to [RFC3010] as a five-page section that outlined an approach based on Windows ACLs. That section was not really a feature specification did not appear to be attempting to fill that role. Instead, like other ambitious proposals in that RFC, it was a statement of ambition and its approval as a proposed standard did not involve a commitment by implementers to implement that proposal.¶

When [RFC3530] was published, the ACL section followed the same basic approach. At the same time, there were clear indications that implementations based on the proposal in [RFC3010] might not be possible in many environments. Despite this justified concern, a shift to a more UNIX-oriented approach was not made. Instead, the more ambitious approach continued to be presented as canonical while the specification was revised in an attempt to allow ACLs based on the withdrawn POSIX draft ACLs to be implemented within the XDR established for the original, more ambitious approach.¶

As things turned out, that attempt failed, since the subset of the NFSv4 ACL model that was treated as required ignored some aspects of the draft POSIX ACL model.¶

As a result, the fundamental differences between these two approaches were obscured. Instead of providing explicitly for two distinct approaches, the core UNIX and NFSv4 approaches to ACLs were presented as variant implementations of the same underlying approach, simply because they were expressed using the same XDR. Semantic differences were dealt with only when absolutely necessary and the wider semantic range of the NFSv4 model led to an incorrect approach in which the core UNIX and draft POSIX ACL model were considered as obstacles to be overcome as part of a supersession narrative.¶

In order to accommodate these multiple ACL models, the specifications were drafted with a troubling level of semantic laxity, as described in "PROB-lax"/>. As a result, clients had no way to determine what approach a server had implemented. As a result, most clients could only depend on the features of the least ambitious model while these needing features of the more ambitious models could only use them if they approached the issue with no prospect of interoperability and chose particular server implementations based on the features which each supported and adapted each client to each server used. As a result,¶

• Clients that needed the functionality of draft POSIX ACLs had to deal with mapping between two sets of ACE masks, without documentation of the process, uncertainty about the partial ALLOW satisfaction required by this model and with no direct support for the default ACL semantic.¶

  They had to deal with the core UNIX ACL subset which was not a good fit for their needs.¶

• Clients that needed functionality provided by the NFSv4 extensions had no API for users to use to request those services. In addition, it was impossible for clients to determine whether the particular extension was supported.¶

3.3. Semantic Laxity

[Consensus Needed (Item #104e), Through end of section]:¶

As we consider the extraordinary semantic laxity regarding ACLs in current specifications, it appears that a number of factors were involved in arriving at the approach we see reflected in [RFC7530] and [RFC8881].¶

• A lack of concern about and experience with defining semantics.¶

  For NFSv3, this was not an issue since all necessary semantics was inherited from POSIX semantics with regard to file access, originally defined to support local operation.¶

  Unfortunately, the working group's members with this background were unable to shift their approach to adapt to a very different environment, in which semantic extensions to POSIX, such as named attributes and ACLs required a different approach.¶

• A lack of concern with authorization issues combined with a tendency to treat these as inherently-server specific.¶

• A lack of familiarity with the needs of standards-based specifications together the expectation, derived from the history of NFS, that there would be coordinated dominant client and server implementations that would resolve semantic issues at the implementation level.¶

These resulted in a situation in which important behavioral specifications, important to provide interoperability, were left unresolved by writing the specs in various ways that, appear, in retrospect, to be ill-advised:¶

• The use of SHOULD without any attention to a clear characterization of the supposed "valid reasons" to bypass the recommendation.¶

  The common use of this keyword in connection with actions to be taken in implementing ACLs might or might not have affected actual implementations as there was often no reason to bypass the recommendation. Nevertheless, it created a substantial uncertainty about many elements of the specification since it allowed the possibility of variant implementations to develop with clients forced to adapt.¶

• The designation of certain choices by uses of SHOULD explicitly identified as "intentional".¶

  Essentially, these uses of SHOULD, had the same effect as if MAY had been used but the fact that MAY was not used obscured the reality that the degree of freedom thereby granted to the server had negative consequences for interoperability.¶

• In many cases, the specification simply cited distinct possible server behavior, implying that it was the job of the client to adapt to the server behavior.¶

The unfortunate consequences of this approach and the means by which it needs to be addressed are discussed in Section 3.5.¶

3.4. Problems in the Handling of Draft POSIX ACLs

[Consensus Needed (Item #117f), Entire section]:¶

In previous specifications, it was indicated that it was desired to allow servers built to support draft POSIX ACLs to serve in this role while supporting NFsv4 ACLs. It was assumed that, for a clearly defined subset of NFSv4 ACLs, a simple translation to the NFSv4 format could provide for effective implementation of something sufficiently close to the draft POSIX ACL model to be useful. The assumption that it was possible to use such servers to support NFSv4 ACLs ignored many of the fundamental differences between the two ACL models. Analysis of the differences between the semantics of the NFSv4 ACL model and the draft POSIX ACL model established that this was unachievable for the reasons discussed below.¶

• The handling of inheritance within the NFSv4 ACL model, was not usable in the draft POSIX ACL context, because the draft POSIX ACL concept of default ACLs had no correlate within the NFSv4 ACL model.¶

• The one case in which a specific semantic difference was mentioned, with the presumed draft POSIX ACL semantics explicitly made essentially OPTIONAL (although confusingly described as an "intentional SHOULD") did not accomplish the intended purpose because it did not accurately reflect draft POSIX ACL semantics.¶

• The role of the acl mask within the draft POSIX ACL approach was essentially ignored.¶

  This made it extremely difficult to extend the NFSv4 ACL model to incorporate draft POSIX ACLs because important information needed to support it was excluded from the already-defined ACE/ACL structures.¶

• Most important was the two different approaches to authorization checking. For draft POSIX ACLs a single ACE is selected based on the requesting principal, while in the NFsv4 ACL model any number of applicable ACEs can allow or deny the requested operation. This restricts the set of translatable ACLs but is even more troublesome in that it makes the translation dependent on group membership. This requires the translator to have extensive knowledge in order to be able to determine when two named groups or a name user and named groups might intersect and means that a translation can be rendered invalid post facto in response to group membership changes.¶

Given the above, the assumption that servers built to support draft POSIX ACLs could support a submodel of the NFSv4 ACL model appears to be grossly mistaken. It appears that the neglect of defined semantics noted previously caused the semantics of draft POSIX ACLs to be essentially ignored.¶

In addition, The corresponding assumption regarding client support neglected much of the semantics of draft POSIX ACLs. As a result, only a subset of the possible ACLs within the draft POSIX ACL model were expressible within NFSv4 ACL model.¶

Given the pervasive lack of attention to semantic details, it seems to have been assumed that the draft POSIX ACL model could be handled in the framework of the Supersession Narrative discussed in Section 3.4, leaving others with the job of providing true support for draft POSIX ACLs.¶

3.5. Challenges We Now Face

[Consensus Needed (Items #104f, #105e), Through end of section]:¶

The way in which the features incorporated in the original NFSv4 ACLs model were selected and specified raises difficult-to-resolve issues as we try to provide now what should have been provided at an earlier stage.¶

Often, when the specification is at variance with existing implementation, we can create a specification that matches the existing implementation. This was the approach taken when the internationalization specified in [RFC3530] was replaced by that in [RFC7530].¶

In that case, we were able to make that switch because the existing specification had essentially been ignored by implementers and their uniform choice, which provided widespread interoperability, was based on previous NFSv3 practice and was consistent with the needs of UNIX users, clients, and servers and could be adapted carefully to meet some of the needs that motivated the approach in [RFC3530].¶

In this case we have a far more difficult situation to deal with, because of the following factors:¶

• Implementation was not uniform in that there were two basic implementation patterns to fill, with the non-POSIX pattern presenting implementers many choices about the feature set to support.¶

• Much more time has elapsed making it harder to access information about implementations.¶

• Even within the POSIX-oriented set of implementations, there were a significant set of behavioral choices allowed, whether explicitly or by a lax approach to the specification of expected behaviors.¶

As a result, the following needs be done for each of the constituent features:¶

• Assess the suitability of the extension for inclusion in NFSv4 based on user needs, server implementability, and issues concerning the consistency of the extension with the rest of the NFSv4 protocol.¶

  In connection with this, the existence of implementations is a clear indications of need/usefulness, but their non-existence cannot be considered dispositive.¶

• Find server implementations of the feature¶

  We will wind up with certain cases in which the number of servers implementing the feature is low or zero.¶

  It might take considerable time to find them and ascertain details of their implementation, especially since this might depend on the local file system used.¶

• Specify details of the required behavior.¶

  In the ideal case, we will find an interoperable client-server pair but even in that case, we will need to find out if other such pairs exist, which might take considerable time.¶

  If multiple such pairs exist it is possible, although unlikely, that agreement on a single approach can be achieved. A more likely result in that case is that one or more behavioral variants will be allowed and there will be a way for the server to provide the client information about its behavioral choices as described in Section 4.6¶

It is unlikely that it we will be able to complete all of the above for all of the extensions to the core UNIX ACL model described in Section 5.1 in a reasonable time, as part of the NFSv4.1 respecification effort. As a result, we will focus on a more limited of goals described in Section 3.6.¶

3.6. Work Necessary to Address Interoperability Issues as Part of NFSv4.1 Respecification Effort.

The ideal state for a feature group such as ACL support is one in which the set of allowable server behavioral variants is limited as follows:¶

• Allowed behavioral variation should be used primary to allow the presence or absence of specific OPTIONAL features not needed by all clients but usable by some client subset.¶

  These can be supplemented by allowing multiple behaviors if the reasons to allow multiple behaviors outweigh the difficulty, for clients and users, of dealing with servers that manifest different behaviors.¶

• There is a good way for the client to determine the server's behavioral choices and adapt to them, to provide to users a common result independent of particular server choices.¶

  In many cases, the client, if provided with appropriate information about server behavior, can provide the same interface to its users, irrespective of server choices.¶

While it would have been possible to design ACL support to meet the above, the problem was not then recognized, leaving us to try to correct it after the fact. In this case, the difficulty of doing so has been compounded by the development of a server support with a wide range of behavioral variation although we are still unclear about the variation that actually exists.¶

A critical part of addressing this issue is definition of the Aclchoice attribute described in Section 4.6 Aclchoice provides a means of specifying the server's choices when there are allowable behavioral variants including elements of the protocol for which support is essentially OPTIONAL and other behavioral variants that exist. Because of the ways ACLs were described previously (See Section 3.3), we can never be sure of knowing all of these, but items have been included as described below and the set of allowed variants is subject to later extension.¶

• We have included all cases in which feature-like elements are essentially made OPTIONAL in previous specifications. This is done even though those specifications did not specify this choice in those terms or recognize the full implications of their optional nature.¶

  These cases include the fact that each ACE type is OPTIONAL (choices reported by the Aclsupport attribute), the fact that almost all ACE mask bits are OPTIONAL (See details below), and the optional nature of each of the items of ACE flag support. In the latter two cases, the only ways that the client can determine which features are supported is through use of the Aclchoice attribute.¶

• We have not included many cases in which the servers is implicitly allowed to manifest different behaviors via the otherwise unexplained use of the keyword "SHOULD". Given the lack of explanation and the pervasive misuse of RFC2119-defined terms in these specification, it is hard to conclude that there was any specific reason to allow these recommendations to be bypassed and it is likely that no implementations actually did so. If we find cases in which servers did bypass the recommended action, they can be added by an extension of the Aclchoice attribute.¶

  There is one case in which a possible behavioral variant is introduced by what is referred to as an "intentional 'SHOULD'". Because it is hard to conclude, given the context, that anything different than "MAY" was intended, this choice, as to how to compute a mode value from an ACL, was added as a valid behavioral variant within Aclchoice.¶

  There is one case which an unexplained SHOULD is used but the recommended action (i.e supporting DENY ACEs) has been treated as OPTIONAL nevertheless. This partly because of the specification's need, mentioned in a number of places, to support servers implementing draft POSIX ACLs which have no DENY facility, but it also reflects other elements in which such support is presented as OPTIONAL including the definition of the Aclsupport attribute.¶

• In some cases connected with modifying an ACL to reflect the potential change to the low-order bit of the mode attribute, we have created allowable behavioral variants to reflect the fact that the existing specification are self-contradictory about what does and does not need to be done many potentially existing ACEs. See Section 10.7 for details.¶

• There are a number of cases in which certain behavioral variants necessary to provide explicit support for draft POSIX ACLs are explicitly disallowed. This is despite the desire, mentioned in other places to allow use of such servers.¶

  As allowed by Section 9 of [RFC8178], we have provided additional flexibility to accept such server behavior and to allow its use to¶

The other critical element in addressing these issues in the context of the NFSv4.1 respecification effort involves the reorganization of the specification into a required core and several sets of extensions as described in Section 5. As mentioned above, each of these sets will have its own requirements in the context of the respecification effort as described below. This gives us the option of providing further steps later in areas that are not a current priority, allowing us move towards the sort of implementation we should have started with.¶

• For the core functionality described in Section 5.1, our goal as part of this respecification is simply to recognize and document the fact that this is a set core functionality that needs to be present whenever ACLs are used to provide authorization instead of using the mode attribute.¶

  This is in contrast to the current approach which treats the full NFSv4 ACL model as canonical, but essentially treats almost any variation from the specified behavior as something that clients have to accept but do not need to be informed about.¶

  Within this document, the three ACE mask bits corresponding to the POSIX read, write and execute privilege bits are always expected to be supported. While the same expectation is made by the existing specification, that is never clearly stated and it is possible to read the statement allowing the server to choose mask bit granularity on its own as allowing something even more coarse-grained. This is despite the fact that the lack of an API correlate of any such implementation would make it essentially unusable.¶

• The definition and support of ACE mask bits beyond the three corresponding to the three POSIX privilege bits are an important part of the extensions needed by the NFSv4 ACL model. See Section 7.2.3 for details. Previously, many important aspects of the handling of these bits was left to the server's discretion or assumed to follow naturally from the position of each bit in a an assumed granularity hierarchy that was not documented and is not viable as a full framework for the existing mask bits.¶

[Consensus Needed (Item #117g), Through end of bulleted list]: While it would be helpful to address the following items as part of the respecification effort by making the draft POSIX ACL model a submodel of the NFSv4 ACL model, it has proved impossible to do so, because of the large set of semantic differences between the two models described in Section 3.4. For discussion of ways to address draft POSIX ACL semantics in later minor versions, see Appendix C.¶

• The different handling of ACL inheritance in the draft POSIX and NFSv4 ACL models. The NFSv4 approach is more general but the POSIX approach is simpler to use and understand.¶

• The very different approaches to authorization determination in which POSIX checks only a single ACE based on the principal while NFSv4 scans the entire ACL for potential principal matches.¶

• The very different approaches taken to the interaction of mode and ACLs including the use of the ACL mask.¶

Given this framework the degree of satisfaction of our basic goals to be expected as part of the respecification varies with the area, as described below:¶

• The definition of the core UNIX ACL model presented in this document is adequate as it stands and will be part of the respecification effort.¶

  The corresponding work to allow clients using this model to interact correctly with servers implementing the NFSv4 ACL model in whole or in part is also adequate as it stands and will be part of the respecification effort.¶

• Support for the draft POSIX ACL model is not possible as part of the respecification effort and will need to be deferred to an NFsv4.2 extension.¶

• Considerable effort has been done to provide better support for servers that implement some or all of the extensions within the NFSv4 ACL model and for clients that need these extensions. Considerable advances have already been made by recognizing these as OPTIONAL extensions and allowing the client, using Aclchoice, to determine the extension that are supported.¶

  To reach an a truly interoperable state, we would need either a full definition of expected semantics, as we have in the case of draft POSIX ACLs, or a complete understanding of the allowable behavioral variants. Since the latter was not provided as part of the design of the feature as would normally be expected, these decisions would have be done after-the-fact based on the details of all existing server implementations, That step is likely to be delayed and is not expected be done as part of the NFsv4.1 respecification effort.¶

4.1. Definition to Support ACL-related attributes

The definitions of the acemask4 and some other data structures related to the Aclchoice attribute appear in included subsections. These need to be done earlier than others for a number of reasons:¶

• They are used directly in the definition of ACL-related attributes as well as within the definition of the ACE structure in Section 7.¶

• They need to be referenced as part various data elements that need to incorporated into the Aclchoice attribute, defined in Section 4.6.¶

typedef uint32_t        acemask4;

typedef uint32_t        ombr4word;

struct nfs4acds {
            uint32_t    acd_offset;
            uint32_t    acd_length;
};
typedef struct nfs4acds nfs4acdi;

struct nfs4acas {
            bitmap4     aca_bits;
            nfs4acdi    acs_ditems<>;
            opaque      aca_dpool<>;
};

4.2. Table of ACL-related Attributes

The following table summarizes 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: Aclchoices, Aclsupport.¶

4.3. 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:¶

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

2. For particular 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 Section 6, address 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 a the core subset of NFSv4 ACLs (i.e., the parts which are not OPTIONAL whenever ACL-related attributes are supported make a more limited change to the POSIX authorization model and are represented by the same sorts of structures as NFSv4 ACLs, although there are restrictions imposed by the UNIX ACL model. These ACLs are based on a subset of the draft POSIX ACL model.¶

Although these two models (i.e., NFsv4 ACLs and draft POSIX ACLs) have some common goals and are presented in a common XDR framework, they are substantially different, for reasons listed below. Previous specifications have assumed that server implementations of the draft POSIX ACLs could serve to support NFsv4 ACLs and ignored the issues that the semantic differences would pose for clients attempting to support the draft POSIX model.¶

• 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 specific 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.¶
• These models implement very different approach to authorization in that the NFSv4 ACL model is based on the sequential scanning of all ACEs to verify authorization for all requested actions, while the draft POSIX ACL model scans a limited subset of these and requires that all authorization for each requested action be determinable based on a single ACE.¶
• Both have very different approaches to managing the interaction of the mode attribute and ACL-related attributes. In particular, draft POSIX ACLs use the middle three of the nine bits controlling authorization to establish an ACL mask applying to all ACEs except those controlling access to the owning user and to everyone.¶
• They have very different approaches to the management of ACL inheritance.¶

{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 Aclchoice 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 provided by attempting to set ACLs containing such ACEs¶

• In the case in which neither the Aclsupport attribute nor the SACL attribute is supported, then it is not possible to determine of support for NFSv4 ACL semantics, as opposed to core UNIX ACL semantic is provided.¶

  As a consequence, server implementations providing support for NFsv4 extensions need to support the Aclsupport attribute. This is because, if they do not, the client could legitimately assume that support for the NFSv4 ACL model is not present.¶

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

[Consensus Needed (Item #118b)]: When this attribute is interrogated, it either returns an array of all ACEs in effect for this object including those related to authorization and to the monitoring of attempted operations. When there are no such ACEs, a zero-length array is returned, indicating that there is no ACL (and thus no SACL or DACL) associated with the object.¶

[Consensus Needed (Item #118b)]: When this attribute is set the values of the SACL and DACL attributes are also affected. When it is set to a zero-length array, indicating the deletion an ACL, both the SACL and DACL attributes will subsequently return an indication that there is no such ACL. If the ACL value being set only contains ALLOW and DENY ACEs, the SACL attribute will subsequently return an indication that there is no such ACL. Similarly, if the ACL value being set only contains AUDIT and ALARM ACEs, the DACL attribute will subsequently return an indication that there is no such ACL.¶

This attribute, consists only of an ACE array and does not support automatic inheritance or default ACEs. Although some inheritance features might be supported, some of the inheritance features of the draft POSIX ACL model are not accessible using this attribute.¶

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

[Consensus needed, Including List (Item #65a)]: 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 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 essentially 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 semantics 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 uncoordinated choices, exponentially raising the number of possibly valid semantic models that clients and users have to accommodate.¶

• 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 unaddressed, 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 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 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.¶

4.5. 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 Section 4.3.¶

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 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 SHOULDs are essentially equal to MAYs.¶

• The most likely source of divergence, the fact that UNIX ACLs do not support 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 types supported by the 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 acl attribute MUST be supported in the dacl attribute as well.¶

4.6. The Aclchoice Attribute (v4.1 extension for bis)

[Consensus Needed (Item #105f), Through end of section]:¶

The Aclchoice attribute provides information regarding the server's provision of various OPTIONAL elements or valid behavioral choices in implementing NFSv4 ACLs and using them for authorization or other security-related functions.¶

This has been necessary by the approach taken in previous specification, in which numerous extensions of the core UNIX ACL model are mentioned as possibilities but there is no attention at all to the problems that this creates for clients without a way to determine whether any particular extension is supported. Without such facilities, the ability to determine whether the necessary extensions are supported is severely compromised. We consider that inability as a protocol defect justifying the extension of the protocol via the addition of a new OPTIONAL attribute.¶

While it might be supposed that this attribute could be rendered unnecessary since the server would be expected to reject requests for unsupported services, the definition of ACLs in previous specifications make that impossible for the following reasons:¶

• In many cases, existing specifications are written, so that such rejection is not required and sometimes it is suggested that it is undesirable. For example, [RFC8881] contains the following.¶

  • 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.¶
  • So it may be useful for a server to accept an ACL even if not all of its modules are able to support it.¶
  • 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.¶

  As a result of this and similar statements in the existing specifications, it is impossible to rely on rejection in the cases we concerned with.¶

• Much of the existing vagueness about the handling of ACE mask bits is exacerbated by the false assumption that all such mask bits can be treated as part of granularity hierarchy mappable to the coarse-grained approach of three permissions derived from POSIX.¶

• A further source of difficulty arises from the possibility, alluded to in previous specifications that a server might accept ACLs it is not prepared to enforce, in the expectation that another that is capable of enforcing the ACL might later do so.¶

  As a result, ACLs could be accepted with this expectation, with no way of determine whether they are enforced where first created or any other server to which they might be copied.¶

While it is now easy to see that the choices above were ill-advised, it is impossible to change them now without created compatibility issues not acceptable in the bis context. As a result, our only realistic option is to define a protocol extension to correct this defect as provided for by Section 9 of [RFC8178].¶

const FATTR4_ACLCHOICE     = 87; -

enum acc4bitnums {
            ACC4BN_NEINGM   = 0,
            ACC4BN_SEPFWX   = 1,
            ACC4BN_SEPAFD   = 2,
            ACC4BN_SEPDE    = 3,
            ACC4BN_RNASDI   = 4,
            ACC4BN_NAD      = 5,
            ACC4BN_NADMOD   = 6,
            ACC4BN_MBCA     = 7,
            ACC4BN_SMJUST3  = 8,
            ACC4BN_SMOLD    = 9,
            ACC4BN_SMFULL   = 10,
            ACC4BN_3MASKB   = 11,
            ACC4BN_AUTHWHO  = 12,
            ACC4BN_IN1BIT   = 13,
            ACC4BN_INHFULL  = 14,
            ACC4BN_INHAUTO  = 15,
            ACC4BN_RVINV    = 16,
            ACC4BN_OTHWHO   = 17,
            ACC4BN_SVTX     = 18,
            ACC4BN_SVTXOLD  = 19
};

enum acc4dinums {
            ACC4IN_OWNMB    = 0,
            ACC4IN_ODDMB    = 1,
            ACC4IN_STOREUA  = 2,
            ACC4IN_TSUPP    = 3
};

The tables below provide information about the individual implementations that are communicated in the Aclchoice attribute. One table is used for specific bits for cases in which the choice is specified with the associate bit map. The other is used when the choice is combined with some additional info in a subsidiary data item. In both cases, the table identifies the choice class while is selected from the following list:¶

Mbcs:

Mask bit with clear semantics¶

Mbus:

Mask bit with uncertain semantics¶

Obv:

Original behavioral variant¶

Lbv:

Later behavioral variant¶

These tables and the sections they point to will contain restrictions making certain sets of flags or data items invalid. When such restrictions are violated, the client is free to ignore the Aclchoice attribute and treat it as unsupported.¶

4.7. 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 (Item #118c)]: When this attribute is interrogated, it returns an array of ACEs of types ALLOW and DENY, in an order consistent with the ordering of those ACEs in the Acl attribute. When there are no such ACEs, it return a zero-length ACE array, indicating the absence of a DACL associated with the current file object.¶

[Consensus Needed (Item #118c)]: When this attribute is set to a value represent by a zero-length ACE array, all ALLOW and DENY ACEs are removed from the Acl attribute. If there were no AUDIT and ALARM ACEs, the Acl attribute will subsequently return a zero-length ACE array indicating the absence of an ACL for the current file object.¶

[Consensus Needed (Item #118c)]: When this attribute is any other value, any existing ALLOW and DENY ACEs are removed from the Acl attribute and the ones specified are added. Subsequently the Acl and Dacl attributes will not return a zero-length array because there will be an ACL an a DACL associated with the current file object.¶

{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 Section 4.4 are addressed¶

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

• Implementations of POSIX ACLs might not have been updated to support the sacl attribute, since doing so would add no value.¶
• Even if such POSIX-ACL-oriented implementations 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.¶

4.8. 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 inheritance and default ACEs (see Section 8).¶

[Consensus Needed (Item #118d)]: When this attribute is interrogated, it returns an array of ACEs of types ALLOW and DENY, in an order consistent with the ordering of those ACEs in the Acl attribute. When there are no such ACEs, it return a zero-length ACE array, indicating the absence of a DACL associate with the current file object.¶

[Consensus Needed (Item #118d)]: When this attribute is set to a value represent by a zero-length ACE array, all AUDIT and ALARM ACEs are removed from the Acl attribute. If there were no ALLOW or DENY and ACEs, the Acl attribute will subsequently return a zero-length ACE array indicating the absence of an ACL for the current file object.¶

[Consensus Needed (Item #118d)]: When this attribute is any other value, any existing AUDIT and ALARM ACEs are removed from the Acl attribute and the ones specified are added. Subsequently the Acl and sacl attributes will not return a zero-length array because there will be an ACL an a SACL associated withe current file object.¶

{Consensus needed, Thru rest of Section (Item #65c)]: While the original intention was to define a usable OPTIONAL attribute based on the NFSv4 ACLs defined in previous specifications, it is now more appropriate to designate this under-specified attribute as experimental although still formally OPTIONAL until the issues discussed in Section 4.4 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 combined in the same attribute with the ALLOW and DENY entries.¶

[Author Aside, Including List (Items #61c, #105g, #110b)]: Although 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.¶

5.1. Role of the Core UNIX ACL model

[Consensus Needed (Items #64a, #105i), Through end of section]¶

Although the working group did not adopt the ACLs in the withdrawn POSIX draft, the continued existence of implementations of them and variants sharing important features with them in UNIX contexts has created protocol difficulties that need to be resolved. In many cases, such ACLs and their associated semantics are the basis for ACL support in UNIX client-side APIs and in UNIX file systems supported by NFSv4.¶

In the context of this document, the Core UNIX ACL model is defined as any approach which shares all of the following features:¶

• Supports only the ACE mask bits that are direct replacements for the three POSIX privilege bits.¶

  When the Aclchoice attribute is supported, this characteristic is reported to the server using the flag bit ACC4BN_3MASKB.¶

• Supports only ALLOW ACEs.¶

• [Consensus Needed (Item #117h)]: Has no support for ACL inheritance. For a discussion of how this affects support for handling of POSIX ACLs, see Section 5.2.¶

The following characteristics of draft POSIX ACLs are not included in this definition but are treated as allowable behavioral variants within the UNIX ACL model:¶

• The inclusion of mask bits derived from ALLOW ACEs for named users and groups in the group mode bits.¶

  When the Aclchoice attribute is supported, this characteristic is reported to the server using the flag bit ACC4BN_NEINGM.¶

• The non-support for partial satisfaction of ALLOW ACEs, so that each authorization request can only be supported by a single ALLOW ACE.¶

  When the Aclchoice attribute is supported, this characteristic is reported to the server using the flag bit ACC4BN_AANPS.¶

[Consensus Needed (Item #117h)]: Although the semantic range of core UNIX ACLs is a subset of that for NFSv4 ACLs, expecting clients to perform the mapping between NFSv4 ACLs and draft POSIX ACL on their own has not worked well. Those issues are addressed for NFv4.1 as described in Section 5.2 while possible approaches to correct this situation are discusssed in Appendix C.¶

5.2. Potential Support for the POSIX ACL Model

[Consensus Needed (Item #117i), Though end of section]:¶

A helpful summary of the draft POSIX ACL model can be found in [Grünbacher]. Although this document deals only with the Linux implementation, the guidance it provides regarding required semantics is expected to be helpful to other potential implementations as well.¶

Although considerable efforts were made to accommodate POSIX ACL implementations with in the existing NFSv4 ACL model, those efforts left support for POSIX ACLs in an unfortunate state for the following reasons:¶

• Many important parts of the POSIX ACL model, such as inheritance were not REQUIRED and no attention was paid to the differences between those functions in the two different ACL models that were to be supported.¶

• While efforts were made to accommodate semantic differences between those models, the effect was limited since many differences were simply ignored due to a lack of interest in semantic description. In addition, behavioral differences that were recognized were addressed in a way that gave the client no ability to select its preferred variant or even determine the choice made by the server.¶

The development of the Aclchoice attribute served to address some of these issues, but did not provide full support, as discussed below.¶

• The uncertainty about the mapping between ACL and modes (and between core UNIX ACLs an server NFSv4 ACLs has been addressed by making this server choice one that the client can find out about, where Aclchoice is supported.¶

  Fully addressing this variability would most likely require a significant degree of attribute incompatibility making it only possible in NFSv4.2 or later.¶

• The differences in the processing of ALLOW ACEs has been addressed by making either of the approaches an allowable server behavioral variant as was done in the mode computation case discussed above. As part of that change, the server choice was made one that the client can find out about, where Aclchoice is supported.¶

  The fact that this had not been done previously was treated as an easily remedied oversight, given the clear intention to allow servers supporting POSIX ACLs to be used, without, as previous specifications put it, "invalidating" them.¶

As a result, it became necessary to accommodate support for draft POSIX ACLs as a separate ACL model. The details of that model are best deferred to an extension of a later minor version as discussed in Appendix C. What is necessary in this document is to appropriately prepare for future specification of multiple ACL models by doing the following things:¶

• Distinguishing between ACLs in general and the specifics of NFSv4 ACLs, that, for some time, are expected to be the only ACL structures that exist. Since it is difficult to name NFSv4 ACL structure as anything other than "ACL", we retain that naming but refer to the general concept as "Access Control List". In addition, the term "Authorization Control List" will refer to any ort of Access Control List that is only capable of controlling authorization, such as the Dacl attribute.¶

• Distinguishing between ACEs in general and the specifics of NFSv4 ACEs, that, for some time, are expected to be the only ACE structures that exist. Since it is difficult to name NFSv4 ACE structures as anything other than "ACE", we retain that naming but refer to the general concept as "Access Control Element".¶

• Making it clear that the material in Section 10 applies only to ACLs and that the handling of co-ordination of the mode with other sorts of Access Control Lists is the jobs of the extensions defining those new models.¶

5.3. Server Behavioral Restrictions to Apply when Aclchoice is not Supported

[Author Aside (Item #116a)]: This section explores possible additional behavioral restrictions to avoid situations in which the lax approach to the specification of server semantics could unacceptably interfere with client operation. Given the difficulty of supporting NFSv4 extensions without the use of Aclchoice, we are focusing for now on NFSv4-oriented clients, although the working group might consider what could be done for other clients in later drafts.¶

[Consensus Needed (Item #116a), Through end of section]:¶

Because of the uncertainty about the proper handling of the ACE mask bits defined in Section 7.2.7, the recommendations below SHOULD be adhered to by servers that do not support the Aclchoice attribute in order to allow clients to convert UNIX ACLs to NFSv4 ACLs as described in Section 7.2.14. In the context of the above recommendations, the only valid reason to bypass them is reliance on previous specifications that do not make clear the importance of adhering to these constraints. Further, those implementing such servers need to be aware that they are compromising the utility of the implementation for UNIX-oriented clients and that other clients might not be able to with their semantics either.¶

When transforming an ALLOW ACE using only the three ACE mask bit that correspond to POSIX privilege bits, the corresponding bit mask SHOULD be constructed as follows:¶

• When ACE4_READ_NAMED_ATTRIBUTES is not excluded (i.e., when named attributes are supported) it is to be set if the mask bit corresponding to the read privilege bit (i.e., ACE4_READ_DATA or ACE4_LIST_DIRECTORY) is set.¶

  The bit can also be set in other circumstances, such as when the ACE4_EXECUTE MASK bit is set.¶

• ACE4_READ_ATTRIBUTES is always to be set.¶

• ACE4_READ_NAMED_ACL is always to be set.¶

• [Consensus Needed (Item #62a), Through end of bulleted item]: ACE4_DELETE is always to be set.¶

  This applies to authorization in the case in which the "sticky" bit for the directory is set as well as the case in which it is not set.¶

• ACE4_WRITE_RETENTION and ACE4_WRITE_RETENTION_HOLD are not to set unless the mask bit corresponding to the write privilege bit (i.e., ACE4_WRITE_DATA or ACE4_ADD_FILE) is set.¶

  Servers MAY condition these settings on other conditions (e.g., only setting the bit for ACEs for the owner of a file).¶

The above recommendations do not apply when Aclchoice is supported because the information provided allows the mapping described in Section 7.2.14 to be performed as needed by the semantics provided by the server.¶

[Author Aside (Item #116a)]: The possibility of extending these restrictions to case in Aclchoice is supported needs to be considered, as does the possibility of follow-on restrictions regarding the details of the mapping between modes and ACLs. Much will depend on the range of existing server behaviors. This might enable further simplification of the ACC4IN_ODDMB data item.¶

5.4. Feature Extensions With Clear Semantics

[Consensus Needed (Items #104h, #105j), Through end of section]:¶

The following extensions of UNIX ACL model are now considered OPTIONAL feature whose support, on each given file system, can be determined using the Aclsupport and Aclchoice attributes. These include some for which the core semantics is clear but there are potential behavioral differences, that resolved based on the existence of other features described in Section 5.6.¶

• The provision of separate authorization control for extending a file and for overwriting existing bytes is represented by the flag bit ACC4BN_SEPFWX of the Aclchoice attribute.¶

  When this feature is available and different authorization apply to a file authorization decision cannot be made at OPEN time but are reflected in the results returned to ACCESS and enforced on each Write.¶

• The provision of separate authorization control for adding a new entry to a directory and making sorts of modification for the directory is represented by the flag bit ACC4BN_SEPAE of the Aclchoice attribute.¶

  The detailed semantics of this feature are affected by the feature represented by the ACC4BN_RNASDI flag bit, discussed in Section 5.6. Note that when this bit is not set, renaming of objects within the directory would be affected by restrictions on adding new entries.¶

• The provision of separate authorization control for adding a sub-directories to a directory and for adding other sorts of entries to a directory represented by the flag bit ACC4BN_SEPAFD of the Aclchoice attribute.¶

  This feature bit is only meaningful if feature represented by the ACC4BN_SEPAE flag bit is also in effect.¶

  The detailed semantics of this feature are affected by the feature represented by the ACC4BN_RNASDI flag bit, discussed in Section 5.6. Note that when this bit is not set, the ability to rename a subdirectory and a file within a directory would be controlled by different ACE mask bits and that renaming of objects within the directory would be affected by restrictions on adding new entries.¶

• The provision of separate authorization control for deleting a new entry to a directory and making other sorts of modification to the directory is represented by the flag bit ACC4BN_SEPDE of the Aclchoice attribute.¶

  The detailed semantics of this feature are affected by the feature represented by the ACC4BN_RNASDI flag bit, discussed in Section 5.6. Note that when this bit is not set, renaming of objects within the directory would be affected by restrictions on deleting existing entries.¶

• The provision of separate authorization control for operations involving a file object's named attribute directory is represented by flag bit ACC4BN_NAD of the Aclchoice attribute.¶

  The detailed semantics of this feature are affected by the feature represented by the ACC4BN_NADMOD flag bit, discussed in Section 5.6. Note that when this bit is not set the creation of a new name attribute directory would be controlled by a separate ACE mask bit but this same bit would not control the authorization of otherwise modifying the named attribute directory.¶

• The server's support for a limited set of mask bit derived from the three POSIX privilege bits is represented by flag bit ACC4BN_3MASKB of the Aclchoice attribute.¶

  This bit cannot be validly combined with any of the bits ACC4BN_SEPFWX, ACC4BN_SEPAE, ACC4BN_SEPDFD, ACC4BN_SEPDE, or with any use of the data items ACC4IN_OWNMB or ACC4IN_ODDMB.¶

• The server's support for DENY ACEs is indicated by the bit ACL4_SUPPORT_DENY_ACL in the Aclsupport attribute or by the bit with numeric value two in the word associated with data item ACC4IN_TSUPP.¶

• The server's support for AUDIT ACEs is indicated by the bit ACL4_SUPPORT_AUDIT_ACL in the Aclsupport attribute or by the bit with numeric value four in the word associated with data item ACC4IN_TSUPP.¶

• The server's support for ALARM ACEs is indicated by the bit ACL4_SUPPORT_ALARM_ACL in the Aclsupport attribute or by the bit with numeric value eight in the word associated with data item ACC4IN_TSUPP.¶

• The server's support for newly defines ACE types is indicated a bit the word associated with data item ACC4IN_TSUPP. The selected bit is one left-shifted by the value of the ACE type.¶

• The server support's support for a limited form of ACL inheritance is indicated by the flag bit ACC4BN_IN1BIT. In this form of inheritance there is no provision for separate control of inheritance for subdirectories and for non-directory objects.¶

  Because this level of inheritance support is needed for implementation of the draft POSIX ACL model, clients needing that support requires a file system with either ACC4BN_IN1BIT or ACC4BN_INHFULL set.¶

  When this form of inheritance is supported, ACEs in ACE4_FILE_INHERIT_ACE and ACE4_DIRECTORY_INHERIT_ACE are set to different values are generally rejected. However, when ACC4BN_RVINV is set the server is allowed to convert the ACE to one in which the two values are the same.¶

  This bit is incompatible with ACC4BN_INNO and ACC4BN_INHFULL.¶

• The server support's support for full ACL inheritance is indicated by the flag bit ACC4BN_INHFULL. In this form of inheritance there IS separate control of inheritance for subdirectories and for non-directory objects.¶

  This bit is incompatible with ACC4BN_INNO and ACC4BN_IN1BIT.¶

• The server's support for automatic ACL inheritance is indicated by the flag bit ACC4BN_INHAUTO.¶

  This bit in incompatible with ACC4BN_INNNO.¶

• The server's support for ACL inheritance using the concept of default ACLs is indicated by the flag bit ACC4BN_INHDEF.¶

  This approach to ACL inheritance is needed for the support of the draft POSIX ACLs model, but can be used by others as well.¶

  This bit in incompatible with ACC4BN_INNNO.¶

5.5. Features with wide Semantic Ranges

[Consensus Needed (Item #105k), Through end of section]:¶

There are a number of features in which the wide latitude given to server implementers creates a set of uncertainties that cannot be reduced to a small set of individual binary choices. These cases are dealt within the Aclchoice attribute by defining a data item to provide the necessary data, as listed below:¶

• The Aclchoice data item with index ACC4IN_TSUPP is used to provide information the ACE types that a server accepts and enforces. Unlike the Aclsupport attribute it is not limited to the current set of known ACE types, but is designed so that new types, added via the protocol extension mechanism have ready-made means to indicate whether support is present.¶

• The Aclchoice data item with index ACC4IN_ODDMB is used to provide information about the nature of the support for ACE mask bits which are neither REQUIRED nor a finer-grained corelate of another REQUIRED mask bit.¶

  There are many aspects of the support for these mask bits that are not clearly discussed in the existing specifications. That is most likely because it was incorrectly assumed that all the mask bits did fit in this model, making detailed explanation necessary.¶

  As a result, it remains unclear, for each of these bits, how authorization for the corresponding operation is to be determined, when ACLs are generated based on the setting of mode. Similarly, their contribution, if any, to modes computed from existing ACLs needs to be clarified.¶

  See Section 7.2.10 for details about how such information is made available to the client, when the server supports any of these ACE mask bits.¶

• The Aclchoice data item with index ACC4IN_STOREUA is used to provide information about cases in which a server accepts, store, and returns ACLs that it is not prepared to enforce.¶

  This includes cases in which the client specifies different handling for two mask bits that the server is not prepared to distinguish, an also cases in which there are other features of the NFSv4 ACL model that the server is not prepared to support (e.g. DENY ACEs, ACL inheritance).¶

  While the possibility of servers accepting ACLs that they are not prepared to enforce is mentioned in a number of places in the existing specifications, there is no normative text regarding this practice. In this document, we treat it as an OPTIONAL feature with details of the set of ACLs supported in this way described using the structures defined in Section 12.2.¶

  Within the existing specifications, the possibility of accepting ACLs that cannot be enforced has the unfortunate consequence that clients needing particular ACL functionality might set ACLs using that functionality and have them accepted with no way of finding that the required functionality is not available.¶

  When the Aclchoice attribute is supported, there is a way to find out the ACE types for which support is available. Nevertheless, it is still helpful to be notified when unsupported ACLs are set. When the ACC4IN_STOREUA is not present, clients can often be assured of such notification. See Section 12.2 for details.¶

The handling of the ACE mask bit ACE4_SYNCHRONIZE could arguably dealt with as part of either of the above data items, since it does not fit in the varying-granularity model and, by its nature, it cannot be enforced within NFsv4 semantics. Within the context of this specification, this mask bit's handling is addressed in the ACC4IN_ODDMB data item.¶

It is possible that the above data items might be eventually replaced by a small set of feature bits, as described in Section 12.1. For that to be possible, the working group would need information about servers that supported this feature and decide if a small set of bits could adequately represent the needed semantic range. That could be done for either of the above data items as part of the rfc5661bis effort, as described in Section 5.7.¶

5.6. Implementation Behavioral Choices

[Consensus Needed (Items #12b, #105l), Through end of section]:¶

There are a number of cases in which for various reasons, multiple behaviors are allowed in implementing some function. Since it is necessary that clients be aware of these differences, they are being treated as features within the Aclchoice attribute, even though they might not be considered features in other contexts.¶

Such behavioral choices can arise as a result of an explicit decision to allow multiple server behaviors, or because the lack of a clear semantic description allowed multiple approaches to develop. In the latter case, we may currently be unaware of these different approaches, so that it is expected, as described in Section 12.1 to extend Aclchoice as these different behaviors are discovered.¶

One additional source of such possible behavioral differences results from cases in which existing specifications describe the function of various ACE mask bits in a way that does not seem to make sense and other approaches have had to be added to allow useful authorization control. In such cases, the newer approach is presented as a distinguishable feature, at least until such time as a consensus can be arrived at to standardize on a single approach.¶

The following behavioral differences are treated as features within the Aclchoice attribute:¶

• The Aclchoice flag bit BN_NEINGM specifies the behavior implemented by the server in computing a mode based on an existing ACL. Because two methods are explicitly allowed in existing specifications, we represent this choice as a feature despite the lack of a clear benefit to either approach.¶

  When this flags is set, ALLOW ACEs for named entities contribute to the privilege bits used for member of the owning group.¶

  The inclusion of this choice within the Aclchoice does not imply that each of these choices is equally desirable. It is hard to determine whether the existing specifications contains a clear recommendation regarding this choice. In any case, this is a matter that would need to be addressed in Section 12.3.¶

• The Aclchoice flag bit ACC4BN_RNASDI specifies that the authorization of within-directory renames is to be controlled by permission to write the specified directory and does not requires, when these operations are authorized separately, specific permission to delete directory entries and to add directory entries of the type of object being renamed¶

  This difference was not recognized in the existing specifications and the existing text in those documents suggests a different approach. Nevertheless, we take a different approach in this document while allowing the older approach because of the unfortunate consequences of the earlier approach for clients and server that do support a finer-grained approach to the authorization of directory-modifications. See Section 12.3 where this issue is addressed as part of Consensus Item #9, for specifics.¶

• The Aclchoice flag bit ACC4BN_NADMOD specifies that authorization of operations accessing or modifying named attribute directories is to be controlled as described in this document.¶

  This approach is significantly different from the approach taken in the existing specification, which essentially ignored the issue of authorization of operations on named attribute directories and only described authorization for the OPENATTR operation.¶

  As there is no known implementation of the earlier approach, it is uncertain whether allowances need to be made for such implementations. In any case, the lack of authorization semantics for named attribute directories means that the treatment of this issue in the existing specifications cannot remain as it is. The precise nature of the advice/recommendations to be provided remains unclear but it will be addressed in Section 12.3 was part of Consensus Item #111.¶

• The Aclchoice flag bit ACC4BN_MBCA specifies that when faced with a request to store an ACL that it does not support and is not prepared to enforce the server will sometimes modify it to a different one that it can support, without notice to the client.¶

  This behavior is considered an allowable behavior variant because existing specifications allowed it. Nevertheless, because of the general uncertainty it creates and its unfortunate effect on interoperability, its use is discouraged as provided for in Section 12.3.¶

• The Aclchoice flag bit ACC4BN_SMJUST3 specifies that, when the server is processing a change to the mode, it sets the acl to represent the handling specified by those mode bits, making no effort to preserve other aspects of the ACL¶

  Although this appears to be an alternative to BN_SMOLD and BN_SMFULL, described below, there are situations in which multiple of these can be true simultaneously¶

  For example, in the case of ACLs that fit within the UNIX ACL model, there are no inheritable ACEs and no ACEs specifying mask bits not controlled by the mode, substituting an ACL consisting of three entries derived from the mode would satisfy BN_SMOLD and BN_SMFULL as well¶

• The Aclchoice flag bit ACC4BN_SMOLD specifies that, when the server when processing a change to the mode, it sets the acl to represent the handling specified by those mode bits, while making the efforts to preserve other aspects of the ACL recommended by the existing specifications.¶

  This recommendation provide for the retention of inherit-only ACEs, but allows effect outside the scope of the mode change in that the elimination of inheritable ACEs affects inheritance as well as authorization for actions involving the current object.¶

  Although this appears to be an alternative to BN_SMJUST3 and BN_SMFULL, there are situations in which ACL inheritance is not supported so that multiple of these can be true simultaneously.¶

• The Aclchoice flag bit ACC4BN_SMFULL specifies that, when the server when processing a change to the mode, it sets the acl to represent the handling of authorization specified by the mode bit, and avoid any other changes to the authorization of actions involving the current object or the authorization for any subordinate objects that result from ACL inheritance.¶

  Unlike the cases of BN_SMJUST3 and BN_SMOLD, the server's action is specified in terms of a goal to be to be reached rather than a procedure to be applied. The necessary procedure depends on such matters as support for DENY ACEs and the existence of ACL inheritance and is discussed in Section 10.7.3.¶

• The Aclchoice flag bit ACC4BN_AUTHWHO indicate that the server provides support for special who values relating o the existence of requester authentication/identification.¶

• The Aclchoice flag bit ACC4BN_RVINV specifies that the server will, at times, deal with invalid ACLs/ACEs that are normally rejected by accepting them after modifying them to be valid, as provided for by previous specifications.¶

• The Aclchoice flag bit ACC4BN_INNO specifies that there is no support for ACL inheritance.¶

  This bit is incompatible with ACC4BN_IN1BIT, ACC4BN_INHFULL, and ACC4BN_INHAUTO.¶

• The Aclchoice flag bit ACC4BN_OTHWHO indicates that the server provides for support for a miscellaneous set of special who values of uncertain semantics.¶

• The Aclchoice flag bit ACC4BN_SVTX indicates that the server's authorization of deletion and RENAME is modified based on the directory's setting of MODE4_SVTX, as described in Section 7.2.15.¶

  In the case in which the objects do not have ACLs, possible because of non-support, the handling is as described in Section 5.3.1 of [I-D.dnoveck-nfsv4-security].¶

• The Aclchoice flag bit ACC4BN_SVTXOLD indicates that the server's authorization of deletion and RENAME is modified based on the directory's setting of MODE4_SVTX, as described in Section 6.2.1.3.2 [RFC8881]. Although this approach is outdated and SHOULD NOT be used, previous implementations might have adopted it and continue to use it, bypassing the current recommendation to the contrary.¶

  In the case in which the objects do not have ACLs, possible because of non-support, the handling is as described in Section 5.3.1 of [I-D.dnoveck-nfsv4-security].¶

5.7. ACL Choices in Various Stages of Development

The Aclchoice attribute is designed to be modified over time but the propriety of any particular modification depends on the state of development of the feature. In doing so, we will need to distinguish between extensions and other modifications whose use is more limited.¶

During development of this specification, until its eventual publication as an RFC, the following stages need to be distinguished:¶

• The initial specification in this document.¶

  The main goal is to fully cover the valid semantic range provided by previous specifications where it reasonable to assume that alternate approaches exist. Because of the lax approach taken to the specification of semantics, there could be cases where alternatives are allowed but there is no reason to suppose that the multiple approaches have been adopted.¶

• As further drafts of this specification are developed there will be the opportunity to provide needed changes.¶

  These will includes the creation of new bits for newly discovered variants and the deletion of bits for variants that were previously allowed but found not to exist.¶

  In addition, cases in which detailed behavior must be specified in a complicated data item could be simplified if a less general approach satisfies the needs of existing implementations.¶

• Subsequent to Working group last call, the state of the attribute will be permanently assigned to NFSv4.1 and further change will be limited as specified in [RFC8178].¶

After the completion of the rfc5661bis effort, handling will depend primarily on the minor version, as described below:¶

• In NFSv4.0, this attribute will not be available. As a result, clients that need the extensions of the UNIX ACL provided by servers that do support will be unable to use them since there is no good way to determine if they are supported. In addition, as described in Section 7.2.14 certain servers whose semantics is allowed by existing specification will not be usable because the semantics associated with certain ACE mask bits might be such that the client cannot map UNIX ACLs to those maintained by the server.¶

• Similar issues apply to NFSv.1 implementations that were developed before rfc56661bis was published. While it is desirable to update them to provide Aclchoice attribute, this might not be possible in all cases.¶

• Many implementations of NFSv4.1 will have support for the Aclchoice attribute. As a result, the problems that exist for implementations that do not support it will be ameliorated and interoperable operation will be available for clients that do not need any of the extensions to the UNIX ACL model.¶

• In NFSv4.2, it will be possible make additions to Aclchoice attribute as extensions to deal with behavioral variants discovered after thc5661bis was published.¶

• In a later minor version we will be able to further restrict allowable behavior if the Working Group can reach a consensus. One example would be to make standard the ACE mask bits where the varying-granularity model is workable and expand it cover all mask bits or eliminate mask bits that don't fit. As a result many existing elements of the Aclchoice attribute could be made mandatory-to-not-implement and what was left could be limited to the distinct extensions made to the UNIX ACL model to arrive at the NFSv4 ACL model plus a few behavioral variants that the working group decides to accommodate.¶

6.1. Overview of ACL Semantics Choices

[Consensus Needed (Items #105n, #110d), Through end of section]:¶

For reasons discussed in Section 3, there is an extremely wide range of ACL-related semantics that servers are allowed to support. While it would be desirable to narrow this range, there are sufficient practical problems in doing so that we need to focus on helping clients deal appropriately with this wide range of semantic variability. The following means are available:¶

• Where supported by the server, the Aclchoice attribute, described in Section 4.6, can provide extensive information about the ACL semantics provided by the server.¶

  [Consensus Needed (Item #14c)]: The set of supported ACE types is also needed. Normally, this is provided by the Aclsupport attribute. However, when it is not supported, the default discussed in Section 4.5 is available.¶

  For a discussion of how the client can best use this information, see Section 6.2.¶

• Where the Aclchoice is not supported, information is more limited. This includes the case of use with Minor Version Zero, in which this attribute is not defined.¶

  For a discussion of how the client can best use the available information, see Section 6.3.¶

The classes of semantic variability listed below are of potential importance to clients. In some cases, the client's need for information is related to the client's own semantic expectations with an important distinction being that between client's expecting support for the UNIX ACL model and those that require certain features provided by the extensions to that model that servers MAY provide. In the list below, we refer to the former as "UNIX-oriented" clients.¶

• The set of ACE mask bits supported and how actions are mapped to them.¶

  Although clients might need this information, UNIX-oriented clients can interacts with servers since support for the mask bits needed by these clients is REQUIRED. See Section 7.2.14 for details.¶

• The presence of authorization-related extensions to the UNIX ACL model such as ACL inheritance and support for DENY ACEs.¶

  This information is of no interest to UNIX-oriented clients.¶

• Support for the security-related services described in Section 11.¶

  This information is of no interest to UNIX-oriented clients.¶

• The presence of semantics associated with the withdrawn POSIX draft ACLs that we do not treat as part of the UNIX ACL model. These include the way in which a mode is computed from an ACL when an ACL is set (see Section 10.3) and the POSIX-draft-specified handling of the partial satisfaction of ALLOW ACEs in which multiple ACEs can collectively allow an operations even if none of them does so completely.¶

  Although this information might be of interest to clients when it is available, clients will need to allow for a range of sever behaviors in cases in which Aclchoice is not supported¶

• Allowable behavioral variability in the handling of existing ACLs when the mode is set.¶

  This information is only available to the client when Aclchoice is supported.¶

6.2. ACL Semantics Choices

[Consensus Needed (Items #14d, #61e, #105o, #110d), Through end of section]:¶

There is a wide range of potential ACL semantics that servers can provide. When the Aclchoice attribute is supported, the client can determine the semantics provided by the server as described below.¶

• The set of supported ACE mask bits can be determined as described in Section 7.2.12. Also described there is how other elements of the ACE mask support information can be derived from the contents of the Aclchoice attribute.¶

• Supported ACE types can be determined using the Aclsupport attribute or the appropriate default value described in Section 4.5.¶

• The level support for ACL inheritance, including the automatic inheritance features, can be determined as described in Section 7.3.2.¶

• The way in which the mode corresponding is to be computed based on the objects ACL is that described in Section 10.3. Note that the effect of that procedure for a given file system depends on the ACE mask support information for that file system.¶

• The way in which existing ACLs are modified when the mode attribute is set is described Section 10.7.3. Note that the effect of that procedure for a given file system depends on the ACE mask support information for that file system.¶

• The way is which an ACL being set UNIX-oriented client (which only support three ACE mask bits) can be mapped to an appropriate ACL for the current server is discussed in Section 7.2.14 Note that the effect of that procedure for a given file system depends on the ACE mask support information for that file system..¶

6.3. Limited Inference Regarding ACL Semantics

In cases in which the Aclchoice attribute is not supported, including use of the minor version for which it is not defined (i.e. NFSv4.0) there are very limited ways to determine the extensions supported. As a result clients that need to use the extensions to the UNIX ACL are generally unable to determine whether that extension is supported.¶

It is only possible for clients to use these extensions, if they do so without providing for interoperability, by only using servers that are known, from experience that support the required extensions, in addition to those supporting the Aclchoice attribute where the set of extensions available can be found as described in Section 6.2.¶

Although it is possible to test for the presence such extensions, this is generally not helpful because of inherent complexity of making such determinations when crossing into new file systems and because of the freedom given to servers to avoid returning errors for situations in which extensions are used bur not supported.¶

As will be seen in the following list, paralleling the one in Section 6.2, clients that need to use features beyond those provided by UNIX ACLs are generally limited to use servers supporting Aclchoice or to using the features in a non-Interoperable way as discussed above.¶

• The set of supported ACE mask bits in addition to those which are REQUIRED cannot be determined. This is not a problem for UNIX-oriented clients, but those that need to use extensions to that set are basically unable to take advantage of the extensions.¶

• Supported ACE types can be determined using the Aclsupport attribute or the appropriate default value described in Section 4.5.¶

• There is no way to determine the level of support for ACL inheritance, including the automatic inheritance features. The is particular troubling since draft POSIX ACLs require some acl inheritance,¶

• The way in which the mode corresponding is to be computed based on the objects ACL is that described in Section 10.3. Because that computation depends on information provided by the Aclchoice attribute, the client winds up having to accept the server's preferences in this matter.¶

• The way in which existing ACLs are modified when the mode attribute is set is described Section 10.7.3. As in the case of computing a mode from an ACL, that computation depends on information provided by the Aclchoice attribute. As a result, the client winds up having to accept the server's preferences in this matter.¶

• The way is which an ACL being set UNIX-oriented client (which only support three ACE mask bits) can be mapped to an appropriate ACL for the current server is discussed in Section 7.2.14. Certain assumptions have to be made about the server's handling of certain ACE mask bits. However, as long as recommendations in Section 5.3 are adhered to UNIX-oriented clients can function properly.¶

7.1. ACE Type

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;

7.2. 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 depending 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 name 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 which treated differently depending on whether the object is a directory 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. In each case, the same mask bit has two different names and controls two different sets of actions, depending on whether the underlying object is a directory which is not a named attribute directory or another type of object.¶

• The mask bit designated by ACE4_EXECUTE controls two different sets of action depending on whether the underlying object is a directory which is not a named attribute directory or another type of object.¶

[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 relationship to the three POSIX-derived permission bits: Read, Write, and Execute. As described in Section 7.2.3, it is no longer assumed that different sets of supported can be adequately explained as a different server choice as to mask bit "granularity". Changes include material in multiple subsections of Section 7.2.¶

• Mask bits whose set of authorized actions corresponds to a single POSIX-derived permission bit are explained in Section 7.2.4.¶

  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-derived permission bit are explained in Section 7.2.5. These only include mask bits controlled by the write privilege bit.¶

  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 6.2 and 6.3.¶

• Mask bits whose set of authorized actions is a subset of those normally allowed to the owner of a file are explained in Section 7.2.6.¶

  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 6.2 and 6.3.¶

• Other mask bits are explained in Section 7.2.7. These include mask bits which do not fit in the varying-granularity approach since they cannot be considered finer-grained variants of either a single POSIX privilege bit or of ownership of the file. Also included are bits where the relationship to POSIX privileges is uncertain and might depend on the behavior of particular implementations.¶

  This section includes some mask bits for which we have found existing implementations and some for which no implementations have yet been found. 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 paragraph has to be considered tentative for now, at least until some implementation of this bit is found 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.¶

[Consensus Needed (Item #5a) The descriptions in the section below are relevant to both authorization and for recognizing operations whose success or failure are to be recorded when ACL are used for the non-authorization functions described in Section 11. 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 connection with these mask bits be those cited in the sections below, it is possible that existing implementations might behave differently, based on their reliance on earlier specifications 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 Section 7.2.12 for information about how the client is to be made aware of such discordant implementations.¶

typedef uint32 ombr4word;

/*
 * Fields in an ombr4word
 8/
const OMBR4_BNUM_SHIFT  =   0;
const OMBR4_BNUM_MASK   =   0x1f;
const OMBR4_OTYP_SHIFT  =   5;
const OMBR4_OTYP_MASK   =   0X60;
const OMBR4_SUPP_SHIFT  =   7;
const OMBR4_SUPP_MASK   =   0X80;
const OMBR4_MCC_SHIFT   =   8;
const OMBR4_MCC_MASK    =   0x300;
const OMBR4_UAM_SHIFT   =   10;
const OMBR4_UAM_MASK    =   0x3800
const OMBR4_MSM_SHIFT   =   16;
const OMBR4_MSM_MASK    =   0xfff00000;


/*
 * Values within the otype field
 */
const OMBR4OT_DIR       =   1;
const OMBR4OT_NDIR      =   2;
const OMBR4OT_BOTH      =   3;

/*
 * Values within the mode-computation-control field
 */
const OMBR4MCC_NONE     =   0;
const OMBR4MCC_READ     =   1;
const OMBR4MCC_WRITE    =   2;
const OMBR4MCC_EXEC     =   3;

/*
 * Values within the UNIX-ACL-map field
 */
const OMBR4UAM_NEVER    =   0;
const OMBR4UAM_READ     =   1;
const OMBR4UAM_WRITE    =   2;
const OMBR4UAM_EXEC     =   3;
const OMBR4UAM_ALWAYS   =   4;
const OMBR4UAM_OWNER    =   8;

/*
 * Values of shifts used in forming the mode-set mask field.
 */
const OMBR4MSH_RBIT     =   1;
const OMBR4MSH_WBIT     =   2;
const OMBR4MSH_XBIT     =   4;
const OMBR4MSH_OWN      =   8;

/*
  * Values of the mode-set mask field to reflect dependence on a
  * single one of the indices used in accessing the sixteen-bit
  * integer as a four-dimensional boolean array.
  */
const OMBR4MSH_RBIT     =   0xaaaa;
const OMBR4MSH_WBIT     =   0xcccc;
const OMBR4MSH_XBIT     =   0xf0f0;
const OMBR4MSH_OWN      =   0xff00;

7.3. 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 between 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 certain combination of support and non-support are not allowed, as described in Section 7.3.1¶

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

10.1. Background for Combined Authorization Model

Both [RFC7530] and [RFC8881] contain material relating to the need, when both mode and ACL attributes are supported, to make sure that the values are appropriately coordinated. 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.¶

This section and included subsections discuss issues related to the use of the NFSv4 ACL model. Similar issues, as they apply to the use of Access Control Lists defined as part of later extensions are to be dealt with by the documents defining those extensions.¶

[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 10.2 through 10.11. In addition, an NFSv4.2-based extension related to attribute co-ordination will be described in Section 10.12.¶

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 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 Section 10.2, 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 part of what is referred to in this document as "UNIX ACLs", as described in Section 4.1 of [I-D.dnoveck-nfsv4-security]. A discussion of the issues for support of for these ACLs appears in Section 5.1.¶

  [Author Aside]: Despite the statement, now cited in Section 10.2, 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 Section 10.2 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 Section 10 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 interpretation of these terms 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.¶

10.2. Needed Attribute Coordination

On servers that support acl or dacl attributes, together 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.1 of [I-D.dnoveck-nfsv4-security], are modified as necessary to be consistent with the ACLs set by the by client. When the ACL-related attributes are supported, they control authorization so that the role is more limited since authorization uses the ACL rather than the mode to make decisions. As a result clients that need to change authorization for file have most control when they directly affect the ACL which supports a more flexible authorization model. As a result, users and clients that deal with the mode value do so for the following reasons:¶

• They do so to view or modify the three high-order bits of the mode that are not devoted to controlling authorization.¶

• They do it to affect authorization for the object in which case the ACL needs to be modified to be consonant with it.¶

  The previous specifications have allowed considerable behavioral variation on what does and does not need to be modified. In addition, the existence of mask bits whose relationship to the three privilege bits is unclear causes considerable uncertainty. As a result, the server handling of this will be different for different servers.¶

• They do it to provide a rough, but not deceptive, description of the file's authorization status for display.¶

  Since opinions differ as to what an appropriate summary might be and because previous specifications have allowed considerable behavioral variation, the server handling of this will be different for different servers¶

See Sections 10.7 through 10.9 for detailed discussion of these matters.¶

[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 mode. 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 Section 10.7.1 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 from 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 the 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 Section 10.7.3.¶

• When the ACL is changed, the corresponding mode is determined and used to set the nine low-order 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 Section 10.3 be used or another one that provides the same results.¶

{Consensus Needed (Item #26a)]: How other ACEs are dealt with when setting mode is described in Section 10.7.3. 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 Section 10.4. 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 Section 10.5. 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 coordination discussed in this section, the method used to compute the mode from the ACL has an important role. In this regard, the method described Section 10.3 is to be used. This method allows considerable variation including that motivated by a decision allow computation using the method mandated by withdrawn POSIX ACL draft (1003.1e draft 17). Since 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 unless and until the working group revises the protocol to require more uniform treatment. In any case, the Aclchoices attribute allows the client to determine which approach is used by the current server. A more complete discussion of handling of the UNIX ACLs in general is to be found in Section 5.1.¶

10.3. Computing a Mode Attribute from an ACL (proposed)

[Consensus Needed (Items #27b, #28b, #61f, #105t, #110f), Through end of section]:¶

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. In this case, the only valid reason to bypass the recommendation is implementor reliance on previous specifications which left this to implementor choice 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.¶

First, for each of the sets of mode bits (i.e., user, group other, process the ACL in order, with the result in each case with a specific evaluation procedure depending on the specific set of mode bits being determined. The result will be two acemask4 words which are referred to below as "Allowed" and "Denied".¶

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@", @GROUP, and "EVERYONE@" are to be considered, all 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.¶

  In some cases, ALLOW ACEs specifying named users and groups are considered, in a positive sense. Fundamentally the decision whether to do so or not is up to the server, although it needs to always make the same choice for all object in a given file system.¶

• For the bits for others, "EVERYONE@" is to be considered in a positive sense, while "OWNER@" and "GROUP@" are to be considered in a negative sense.¶

Regarding the phrases "considered in a ...sense", the following actions are indicated:¶

• When the ACE to be considered in a positive sense is an ALLOW ACE, the associated mask m is used in AddToAllowed(m), as described below. When it is a DENY ACE, the associated mask m is used in AddToDenied(m), as described below.¶

• When the ACE to be considered in a negative sense is an ALLOW ACE, the associated mask ignored When it is a DENY ACE, the associated mask m is used in AddToDenied(m), as described below.¶

void AddToAllowed(acemask4 m)
{
    acemask4 ov = Denied & m;

    m &= ~ov;
    Allowed |= m;
};

void AddToDenied(acemask4 m)
{
   acemask4 ov = Allowed & m;
   acemask4 nov = m & ~ov;

   Allowed &= ~ov;
   Denied |= nov;
};

acemask4 GetAllowed(void)
{
   return Allowed & ~Denied;
}

Once these ACL masks are constructed, the mode bits for, user, group, and others can each be obtained as described below:¶

• The mask to use to determine the privilege bits is obtained using GetAllowed().¶

• For each of the mode-computation masks, the associated privilege bit is set if all of the mask bits in the associated mask are allowed.¶

10.4. Computing a Mode Attribute from an ACL (vestigial)

[Previous Treatment (Item #27c)]: 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 Section 10 essentially pointless. Would prefer "is to be used" or "MUST", with "SHOULD" available if valid reasons to do otherwise can be found.¶

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

10.5. Alternatives in Computing Mode Bits (vestigial)

[Author Aside]: All unannotated paragraphs within this section are to be considered the Previous Treatment corresponding to Consensus Item #27d.¶

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 nine low-order bits of the mode select one of 512 corresponding ACLs is a desirable but the absence significant details or 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 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.¶

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

10.7. Setting Mode and not ACL (overall)

10.8. 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 Section 10.3. The three high-order bits of the mode (MODE4_SUID, MODE4_SGID, MODE4_SVTX) SHOULD remain unchanged.¶

10.9. 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: 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 Section 10.8.¶

10.10. 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:¶

1. 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 Section 10.7, thereby modifying the ACL.¶

2. 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 Section 10.8.¶

3. 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 Section 10.9.¶

4. 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 MUST be as computed in Section 10.3, 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.¶

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

10.12. 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 [RFC8257], 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.¶

12.1. Provisions for Aclchoice Modification

The structure of the Aclchoice attribute makes it quite easy to add or delete existing flag and data item. However, to ensure interoperability, there are a number of policies set out below, derived from [RFC8178], that restrict how necessary changes can be done.¶

• New items, whether flags or data item can be done whenever new attributes or similar item can be added. Since all such items are OPTIONAL, defaults need to be specified to cover the case in which the items in question are not present¶

  This serves a way to address newly discovered behavioral variants.¶

  In addition to allowing this in extensible minor versions, we will also allow them during the development of this document. New items will be allowed in successive drafts both before and after working group adoption. However, once the document approaches Working Group last call, these will need to cease.¶

• Deletions, as such, will not be allowed. However, as with OPTIONAL attributes, there will be the opportunity to make existing flags and data items mandatory-to-not-implement in new minor versions, such as, for example NFSv4.3.¶

It is desirable ability to allow complicated data items by a set of binary choices, when that can be done. In this case the addition of the new flags bits can proceed quickly but the data item to be superseded will remain in the protocol until it can be made mandatory-to-not-implement in a later minor version.¶

12.2. Storing of ACLs which are not Enforced

The potential ability of servers to accept and store ACEs that they are not prepared to enforce requires the server that supports the Aclchoice attribute to either:¶

• Set acd_length to zero in acsditems[ACC4IN_STOREUA] to indicate that this functionality is never provided.¶

• Set acsditems[ACC4IN_STOREUA] to refer to an acc4storeua (as described below) within acs_dpool to describe the non-enforced ACEs that they accept.¶

  Acceptance of ACE4_SYNCHRONIZE is not considered a use of this facility, since that is true of that bit in all cases.¶

struct acc4storeua {
    uint32_t    asua_types;
    uint32_t    asua_flags;
    ace4mask    asua_mask:
};

This structure is to be filled in as described below:¶

• asua_types contain a mask of ACE type that are accepted but not enforced. Each type is represented by a one left-shifted by the numeric value of the type.¶

• asua_flags contains a mask of ACE flags accepted but and returned on fetched ACLs but not enforced.¶

  When both ACE4_FILE_INHERIT_ACE and ACE4_DIRECTORY_INHERIT_ACE are set, the is no opportunity to determine potential inheritance so specifying any of ACC4BN_IN1BIT, ACC4BN_INHFULL, or ACC4BN_INHAUTO as part of the Aclchoice attribute is invalid.¶

  When one of either ACE4_FILE_INHERIT_ACE or ACE4_DIRECTORY_INHERIT_ACE is set inheritance is limited to being decided by the bit not included if ACC4BN_IN1BIT is set. In addition specifying either of ACC4BN_INHFULL, or ACC4BN_INHAUTO as part of the Aclchoice attribute is invalid¶

• asua_mask contains a set of mask bits that the server is prepared to accept and return on fetched ACLs, but have no role in authorization and are not considered for the AUDIT and ALARM functions.¶

12.3. Advice/Recommendations Regarding ACL Choices

[Consensus Needed (Items #12e, #105v, #117k), For entire section]:¶

The Aclchoice allows the clients to be informed about behavioral choices the server is allowed to make. The fact that the server is allowed to make these choices and report them does not necessarily imply that these choices are valid. They may be allowed solely because they always have been allowed since previous specifications chose to be quite lax in these matters. Also, to correct situations in which previous specifications gave servers undue latitude in making such choices, some behavior previously not felt to be noteworthy is recommended against using "SHOULD" or "SHOULD NOT" with the understanding that the valid reasons to bypass the recommendation are limited to the reliance on earlier specifications.¶

In the table below, we summarize the existing items defined within the Aclchoice attribute, including both flags and data items, providing summary advice/recommendations regarding their use together with some expectations/speculations regarding future development. The advice is summarized using the codes listed below.¶

Vox

Valid OPTIONAL extension.¶

An extension to the core that was allowed to be present or not according to previous specifications, without clearly stating that. The absence of the extension was treated as an excusable implementation flaw.¶

Upx

Valid OPTIONAL extension useful for the support of draft POSIX ACLs.¶

An extension to the core that was allowed to be present or not according to previous specifications, without clearly stating that. Although the absence of the extension was treated as an excusable implementation flaw, it is useful for supporting draft POSIX ACLs.¶

Npx

Valid OPTIONAL extension necessary for the support of draft POSIX ACLs.¶

An extension to the core that was allowed to be present or not according to previous specifications, without clearly stating that. Although he absence of the extension was treated as an excusable implementation flaw, it is necessary for supporting draft POSIX ACLs.¶

Vax

Valid absence of an OPTIONAL extension¶

A choice to support core functionality without any of a set of extensions that were allowed to be present or not according to previous specifications. Only the core functionality is provided despite the absence of a clear statement that this was REQUIRED.¶

Lux

Valid OPTIONAL extension with limited uses¶

Mentioned in passing as acceptable in previous specifications. Despite the fact that it should avoided because of its unfortunate side-effects, it has some valid use cases.¶

Vbc

Valid Behavioral Choice¶

An extension to the core that was allowed to be present or not according to previous specifications.¶

Nbc

Needed Behavioral Choice.¶

Whether allowed by previous specifications or not, needed by clients to provide needed functionality.¶

Dbc

Dubious Behavioral Choice.¶

Whether allowed by previous specifications or not, an acknowledged behavioral variant for which substantive justification is hard to perceive.¶

Sbt

Should be True.¶

Indicate that setting this false has negative consequences of which clients and servers need to be aware.¶

Sbf

Should be false.¶

Indicate that setting this true has negative consequences of which clients and servers need to be aware.¶

Mbc

Miscellaneous behavioral choices.¶

Describes a set of matters for which previous specifications gave no behavioral guidance allowing a range of server behaviors to be chosen.¶

A.1. List of Issues

This section helps to keep track of specific changes which the author has made or intends to make to deal with ACL-related issues that appear 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 formally verified.¶

  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 [I-D.dnoveck-nfsv4-security], 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 items in the following table can be divided into three groups, based on the associated numeric id.¶

• Those with ids less than 62 were created as part of the security document and transferred to this one as part of the document split.¶
• Those with ids between 62 and 65 are the result of splitting items created as part of the security document that now address issues in 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.¶

The following table summarizes the issues in each particular state.¶

A.2. Issue Changes

A.3. Issue Priorities

As a result of the history of this document, there are two important classes of issues that should be dealt with expeditiously to allow us to make progress on this document and complete the rfc5661bis effort, despite the plethora of problems in the specification of ACL in exiting standard-track documents.¶

• There a large set of issues whose discussion is now long overdue, as a result of lack of working group discussion of the issues raised by the existing approach to specification of this feature.¶

  Thirteen of these issues listed in Table 9 should be non-controversial making it desirable we get these out of the way in order to focus on more difficult matters.¶

• Another set of important issues are of more recent origin and reflect the important need, previously unaddressed, is to recognize OPTIONAL features and behavioral variants and make these choices accessible to clients.¶

  Eight of these issues listed in Table 10 need to be prioritized so that the working group has a clearly understood shared understanding of the general approach being taken towards ACLs.¶

B.1. Possible Simplifications

Simplification  of following items is likely to be necessary:¶

• The handling of ACC4IN_ODDMB could be simplified once we had more information on the actual range of behavioral variation shown by existing server implementations.¶

• There are a number of ACE mask bits that look likely to be deleted at some point. These include ACE4_READ_ATTRIBUTES and others for which no server implementation has been brought to the working group's attention.¶

  To delete these it would be necessary to make an assessment of client need leading to a Consensus.¶

Work on these two areas is likely to be mutually reinforcing since the a reduction in the number of attributes to be reported within ODDMB will make it easier to classify the implementations of the rest. After all, in the likely event that some of these bits have only a signed server implementation, there is no possibility of behavioral variants.¶

B.2. Possible Additions

Excluding those connected with Aclchoice simplification, there are two likely sources of potential additions in subsequent drafts and minor versions:¶

• Discovery of new behavioral variants in existing server implementations.¶

  While it could be argued that many of these are instance of flawed, non-compliant implementations, the general tenor of existing specifications may make it difficult to put existing implementations outside the set of acceptable choices.¶

  In view of the need to accommodate file system implementations with widely varying heritages, the most likely way of dealing with divergent implementations is to treat them as behavioral variants and deal with the groups advice/recommendations in Section 12.3.¶

• The potential need for finer authorization granularity.¶

  Although there is a need for removal of granularity overshoot, there may be need for additional granularity to deal with new functionality such as extended attributes¶

D.1. Finer-grained Authorization Support For Extended Attributes

Currently, authorization for the modification or interrogation of extended attributes, is handled in a coarse-grained fashion:¶

• Authorization of the modification of these attributes is controlled by the write permission bit if there is no ACL.¶

  When there is an ACL, authorization is controlled by a single ACE mask bit: ACE4_ADD_FILE in the case of directories and ACE_WRITE_DATA in the case of other types of objects.¶

• Authorization of the interrogation of these attributes is controlled by either read permission bit or the execute permission bit if there is no ACL.¶

  When there is an ACL, authorization is controlled by a the allowance associated with the or of two ACE mask bits.¶

  The first is ACE4_LIST_DIRECTORY in the case of directories and ACE_WRITE_DATA in the case of other types of objects.¶

  The second is ACE4_EXECUTE.¶

It needs to be considered whether it is worthwhile to provide finer-grained authorization in a fashion similar to the way in which reading and writing of named attributes is controlled, i.e., with separate ACE mask bits ACE4_READ_NAMED_ATTRIBUTES and ACE4_WRITE_NAMED_ATTRIBUTES.¶

It is worth noting that the current situation is inconsistent in that [RFC8276] defines extensions to ACCESS "to provide fine-grained access control to query or modify extended attributes", there are no fine-grained ways to control how these bits are set.¶

The following possibilities need to be considered:¶

• Creation of new mask bits ACE4_READ_XATTR and ACE4_WRITE_XATTR parallelling ACE4_READ_NAMED_ATTRIBUTES and ACE4_WRITE_NAMED_ATTRIBUTES with similar mappings when not supported.¶

• Creation of new mask bits ACE4_READ_XATTR, ACE4_WRITE_XATTR, and ACE4_LIST_XATTR matching the set of new ACCESS bits.¶

D.2. Client Choice Regarding Mode Display

While the existing handling of this issue make this a matter of server choice, it is really not clear why the server's choices have any relevance here.¶

When a file has an ACL, it controls file authorization and the mode's role is limited to providing a value for display. Given this fact, it is unclear why the server's preferences in the matter have any real relevance and that, since this does not have any effect on what other clients see, the choice of what to do for display is not up to the requesting client.¶

If the client continues to interrogate the mode attribute there is no way to avoid the server's preferences in this becoming controlling, for no good reason.¶

A new read-only per-object attribute which we will call modeinfo could provide separate information regarding the permissions of named user and groups, allowing the actual reported to the client-side API a mater of client choice, as it should be.¶