ACLs within the NFSv4 Protocols

1.1. Relationship to the Overall Security Document

This document is best understood when it is read together with RFCTBD20 which also 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 RFCTBD20.¶

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 RFCTBD20, in its entirety, applies to both documents, even in the absence of explicit inter-document references.¶
• The terminology defined in Section 4.1 of RFCTBD20 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 RFCTBD20, 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 RFCTBD20, 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 rfc8881bis 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 rfc88811bis 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 D.¶

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 E.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 rfc8881bis 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 ACL_Choice¶

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

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

• [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 ACL_Choice 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 ACL_Choice attribute. See Section 4.7 for further discussion of this attribute, its motivation, and the reason that its absence needs to be treated as a defect, subject to correction as part of the NFSv4.1 respecification effort.¶

1.4. Effect on Various Minor Versions

Because of the profound underspecification of ACL feature and the associated misuse of RFC2119-defined keywords, it is necessary that this document, when published as an RFC, supersede the existing specification of ACLs for all NFSv4 minor versions ([RFC7530] [RFC8881]).¶

However, because of the rules relating to minor versions changes introduced in [RFC8178] and associated practical considerations regarding minor versions not under active development, the following differences should be noted:¶

• In the case of minor version zero, despite the supersession noted above, there is no change to the protocol described or to the XDR described by [RFC7531].¶

  The changes in this document provide a more complete description with more clarity regarding the parts of ACL feature whose implementation is OPTIONAL. As a result, there is no new functionality introduced or compatibility issues expected.¶

  While there is a conceptual change that allows new forms of ACLs to be defined, this change cannot be realized in minor version zero, since additional attributes to use them cannot be added.¶

• In the case of minor version one, the description of ACLs in this document supersedes that in [RFC8881]. In addition, it will provide the ACL description for minor version one that applies once the successor of [I-D.ietf-nfsv4-rfc8881bis] is published as an RFC. That document will explicitly refer to the ACL description being published here.¶

  The changes in this document, while providing a more clear description of the OPTIONAL nature of many elements of the ACL feature, also corrects a number of protocol defects. The correction of protocol defects is explicitly allowed in revised specifications of existing minor versions, as described in Section 9 of [RFC8178]. The limited XDR changes associated with such corrections will be included in the RFC to be derived from [I-D.dnoveck-nfsv4-rfc5662bis]¶

  Section 1.3 discusses such potential defects, including a number of potential changes to allow for semantics compatible with draft-POSIX ACLs to be incorporated in NFSv4.1. While such changes could be considered correctible defects, it was decided to defer support for draft-POSIX ACLs to a later minor version, thus leaving the only defect being corrected here as the lack of a way for the client to determine what OPTIONAL protocol elements were implemented by the server, addressed by defining the ACL_Choice attribute.¶

  Because the ACL_Choice attribute is OPTIONAL, its inclusion cannot result in compatibility issues.¶

• In the case of later minor versions, the ACL description is inherited from minor version one and the modification described above will apply to those minor version as well.¶

  Because these minor versions are allowed to define new attributes, the conceptual change in this document, allowing the definition on new forms of ACLs could be taken advantage of in minor version two, by adding a protocol extension, as provided for by [RFC8178].¶

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 RFCTBD20, 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 previously communicated through the mistaken use of RFC2119-defined 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 ACL_Choice 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.¶