Security for the NFSv4 Protocols

1.1. Document Motivation

1.2. Document Annotation

In order to make progress on difficult issues which will require that changes be made in the existing handling of security issues, including many whose resolution will probably involve compatibility issues with existing implementations, the author has tried his best to resolve these issues, even though there is no assurance that the resolution adopted by consensus will match the author's current best efforts. To provide a possible resolution that might be the basis of discussion while not foreclosing other possibilities, proposed changes are organized into a series of consensus items, which are listed in Appendix B.¶

For such pending issues, the following annotations will be used:¶

• A paragraph headed "[Author Aside]:", provides the author's comments about possible changes and will probably not appear in an eventual RFC.¶

  This paragraph can specify that certain changes within the current section are to be implicitly considered as part of a specific consensus item.¶

  The paragraph can indicate that all unannotated material in the current section is to be considered either the previous treatment or the proposed replacement text for a specific consensus item.¶

• A paragraph headed "[Consensus Needed (Item #NNx)]:", provides the author's preferred treatment of the matter and will only appear in the eventual RFC if working group consensus on the matter is obtained, allowing the necessary changes to be made permanent, without being conditional on a future consensus.¶

  The item id, represented above by "NNx" consists of a number identifying the specific consensus item and letter which is unique to appearance of that consensus item in a particular section. In cases in which a pending item is cited with no part of the discussion appearing in the current section, an item id of the form "#NN" is used.¶

• A paragraph headed "[Previous Treatment]:", indicates text that is provided for context but which the author believes, need not appear in the eventual RFC, because it is expected to be superseded by a corresponding consensus item.¶

  The corresponding consensus item is often easily inferred, but can be specified explicitly, as it is for items associated with the consensus item itself.¶

Each of the annotations above can be modified by addition of the phrase, "Including List" to indicate that it applies to a following bulleted list as well as the current paragraph or the phase "Entire Bulleted Item" to indicate it applies to all paragraphs within a specific bulleted item.¶

1.3. Compatibility and Compliance Issues

Changes that need to be adopted in this document will need to eventually change the behavior of clients and servers that were written to conform to earlier protocol specifications. There are two important classes of such changes discussed in Sections 1.3.1 and 1.3.2 below.¶

As [RFC2119] was originally conceived, compliance and compatibility issues were tightly bound together so that a change to compliance specifications would inevitably give rise to compatibility issues. However, over time, behaviors have come to be denigrated by use of the terms "SHOULD NOT" and "MUST NOT" to warn implementors of a harm deriving from from insecure operation rather than peer incompatibility.¶

When making changes in compliance requirements/recommendations we need to deal with the possibility that, in changing the specification, we might cause a previously compliant implementation to become non-compliant. Some implementers take the view that the compliance status of their implementations is of less importance than other considerations such as compatibility with local file system semantics. Others feel it is important to maintain the compliance status of existing implementations. In any case, the working group has been reluctant, when making such necessary changes, to make previously compliant implementations non-compliant, and will try not to do in cases in which it is known or can reasonably be expected that such implementations exist.¶

Although there is no way to be sure about the non-existence of such implementations, the working group has made judgments about what implementations are likely to exist. For example, when internationalization for NFSv4.0 was changed in the transition to [RFC7530], many previously non-compliant server implementations became officially compliant and there was a potential for conflict with implementations compliant with RFC3530 [RFC3530], if any such implementations existed.¶

In that particular case, it was decided that no such RFC3530-compliant server implementations existed and there was no need to accommodate servers whose internationalization was written to conform to [RFC3530] since no such servers existed and there were no client implementations expecting such behavior. As a result, no actual implementations became non-compliant as a result of this necessary shift.¶

In the corresponding cases dealt with in this document, the situation is more difficult since it may be harder to determine the actual behavior of all existing implementations, since the authors might no longer be actively involved with implementation issues. However, it will be necessary to warn implementors of the negative consequences of certain behaviors without going so far as to declare these practices non-compliant. For the most part, this document will use the terms "SHOULD" and "SHOULD NOT" to draw attention to the problems with troublesome behaviors that previous specifications mentioned with no indication of the problems with them. In such contexts, it is made clear that the need to maintain existing patterns of interoperation is a valid reason to bypass the normative term. The intention is to continue to allow previously acceptable implementations to be considered compliant while not placing the troublesome behaviors on the same levels as other alternatives as would happen if we used the terms "MAY" or "OPTIONAL" or continued to use some of the unfortunate practices discussed in Section 1.3.2.¶

This approach allows implementations to accept input from peers written in accord with previous specification while not obligating them to do so. The intent is to allow a transition to newer, better behaviors over time as client and server policies evolve. However, the specifics of this anticipated transition will vary:¶

• In the case of the issues dealt with in Section 1.3.1, the focus is on making implementers aware of the security problems with practices previously considered acceptable.¶

  It is specified that these practices SHOULD NOT be used by clients or allowed by servers in order to draw attention to the security problems with them. At the same time, the discussion of valid reasons to by pass these recommendations allows them to continue to be used while the infrastructure is developed to make their replacements easy to use.¶

  Servers are encouraged to adopt policies foreclosing client use but not obligated to do so.¶

• In the case of the issues dealt with in Section 1.3.2, the focus is different. In these cases, while we anticipate making changes in compliance specifications, there is no need to address a specific set of troublesome practices. Instead, the problem to be addressed is the vast range of allowable server behaviors previously defined as allowed, although not necessarily explicitly. This server-centered approach has made compatibility a hit-or-miss matter, requiring serious consideration of the question of what specific instances of multiple server behaviors need to be allowed and how clients can find out the choices that servers have made and possibly affect them, also making appropriate provision, as with other optional features, about how to adapt to the server's behavioral choices or to decide that they do not meet its needs.¶

  It appears that this approach was motivated, at least in large part, by the desire to fully support much of Windows ACL semantics while accommodating Unix servers incapable of providing much of that functionality. As a result, the working group will need to provide a way for the server to explicitly opt out of providing Windows functionality that it cannot provide and that Linux clients are not prepared to use.¶

  In addition, the working group will have to restrict, or at least better organize, sever behavioral choices related to the handling of ACLs.¶

  Some approaches to providing the client information about server choices or allowing negotiation of mutually satisfactory handling of these issues are discussed in Section 17.2.¶

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

  Some specific issues relating to this case are described below Section 8.1.¶

• The term may 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.¶

  An important instance of this situation is the description of AUTH_SYS as an "OPTIONAL" means of authentication". For detailed discussion of this case, see Sections 14 and 18.1.5¶

3.1. Per-connection Security Features

There are a number of security-related facilities that can be provided on a per-connection basis, eliminating the need to provide such support on a per-request basis, based on the RPC auth-flavor used.¶

These will initially be provided, in most cases, by RPC-with-TLS but similar facilities might be provided by new versions of existing transports or new RPC transports.¶

• The transport or a layer above it might provide encryption of requests and replies, eliminating the need for privacy and integrity services to be negotiated later and applied on a per-request basis.¶

  While clients might choose to establish connections that provide such encryption, servers can establish policies allowing access to certain pieces of the namespace using such security facilities, or limiting access to those providing privacy, allowing the use of either per-connection encryption or privacy services provided by RPCSEC_GSS.¶

• The transport or a layer above it might provide mutual authentication of the client and server peers as part of the establishment of the connection This authentication is distinct from the the mutual authentication of the client user and server peer, implemented within the RPCSEC_GSS framework.¶

  This form of authentication is of particular importance when the server allows the use of the auth-flavors AUTH_SYS and AUTH_NONE, which have no provision for the authentication of the user requesting the operation.¶

  While clients might choose, on their own,to establish connections without such peer authentication, servers can establish policies a limiting access to certain pieces of the namespace without such peer authentication or only allowing it when using RPCSEC_GSS.¶

To enable server policies to be effectively communicated to clients, the security negotiation framework now allows connection characteristics to be specified using pseudo-flavors returned as part of the response to SECINFO and SECINFO_NONAME. See Section 16 for details.¶

3.2. Handling of Multiple Minor Versions

In some cases, there are differences between minor versions in that there are security-related features, not present in all minor versions.¶

To deal with this issue, this document will focus on a few major areas listed below which are common to all minor versions.¶

• File access authorization (discussed in Section 8) is the same in all minor versions together with the identification/ authentication infrastructure supporting it (discussed in Section 14) provided by RPC and applying to all of NFS.¶

  An exception is made regarding labelled NFS, an optional feature within NFSv4.2, described in [RFC7862]. This is discussed as a version-specific feature in this document in Section 11.¶

• Features to secure data in-flight, all provided by RPC, together with the negotiation infrastructure to support them are common to all NFSv4 minor versions, are discussed in Section 16.¶

  However, the use of SECINFO_NONAME, together with changes needed for connection-based encryption, paralleling those proposed here for SECINFO, is treated as a version-specific feature and, while mentioned here, will be fully documented in new NFSv4.1 specification documents.¶

• The protection of state data from unauthorized modification is discussed in Section 12) is the same in all minor versions together with the identification/ authentication infrastructure supporting it (discussed in Section 14 by security services such as those provided by RPC-with-TLS.¶

  It needs to be noted that state protection based on RPCSEC_GSS is treated as a version-specific feature and will continue to be described by [RFC8881] or its successors. Also, it needs to be noted that the use of state protection was not discussed in [RFC7530].¶

3.3. Handling of Minor-version-specific features

There are a number of areas in which security features differ among minor versions, as discussed below. In some cases, a new feature requires specific security support while in others one version will have a new feature related to enhancing the security infrastructure.¶

How such features are dealt with in this document depends on the specific feature.¶

• In addition to SECINFO, whose enhanced description appears in this document, NFSv4.1 added a new SECINFO_NONAME operation, useful for pNFS file as well as having some non-pNFS uses.¶

  While the enhanced description of SECINFO mentions SECINFO_NONAME, this is handled as one of a number of cases in which the description has to indicate that different actions need to be taken for different minor versions.¶

  The definitive description of SECINFO_NONAME, now appearing in [RFC8881] needs to be modified to match the description of SECINFO appearing in this document. It is expected that this will be done as part of the rfc5661bis process.¶

  The security implications of the security negotiation facilities as a whole will be addressed in the security considerations section of this document.¶

• The OPTIONAL pNFS feature added in NFSv4.1 has its own security needs which parallel closely those of non-pNFS access but are distinct, especially when the storage access protocol used are not RPC protocols. As a result, these needs and the means to satisfy them are not discussed in this document.¶

  The definitive description of pNFS security will remain in [RFC8881] and its successors (i.e. the eventual rfc5661bis document). However, because pNFS security relies heavily on the infrastructure discussed here, it is anticipated that the new treatment of pNFS security will deal with many matters by referencing the overall NFS security document.¶

  The security considerations section of rfc5661bis will deal with pNFS security issues.¶

• In addition to the state protection facilities described in this document, NFS has another set of such facilities that are only implemented in NFSv4.1.¶

  While this document will discuss the security implications of protection against state modification, it will not discuss the details of the NFSv4.1-specific features to accomplish it.¶

• The additional NFSv4.1 acl attributes, sacl and dacl, are discussed in this document, together with the ACL inheritance features they enable.¶

  As a result, the responsibility for the definitive description of these attributes will move to overall NFS security document, with the fact that they are not available in NFSv4.0 duly noted. While these attributes will continue to be mentioned in NFSv4.1 specification documents, the detailed description appearing in [RFC8881] will be removed in successor documents.¶

• Both NFSv4.0 and NFSv4.1 specifications discussed the coordination of the values the mode and ACL-related attributes. While the treatment in [RFC8881] is more detailed, the differences in the approaches are quite minor.¶

  [Consensus Item #25a]: This document will provide a unified treatment of these issues, which will note any differences of treatment that apply to NFSv4.0. Changes applying to NFSv4.2 will also be noted.¶

  As a result, this document will override the treatment within [RFC7530] and [RFC8881]. This material will be removed in the rfc5661bis document suite and replaced by a reference to the treatment in the NFSv4 security RFC.¶

• The protocol extension defined in [RFC8257], now part of NFSv4.2, is also related to the issue of co-ordination of acl and mode attributes and will be discussed in that context.¶

  Nevertheless, the description in [RFC8257] will remain definitive.¶

• The NFSv4.1 attribute set-mode-masked attribute is mentioned together with the other attributes implementing the POSIX authorization model.¶

  Because this attribute. while related to security, does not substantively modify the security properties of the protocol, the full description of this attribute, will continue to be the province of the NFSv4.1 specification proper.¶

• There is a brief description of the v4.2 Labelled NFS feature in Section 11. Part of that description discusses the limitations in the description of that feature within [RFC7862].¶

  Because of some limitations in the description, it is not possible to provide an appropriate security considerations section for that feature in this document.¶

  As a result, the responsibility for providing an appropriate Security Considerations section remains, unrealized for now, with the NFSv4.2 specification document and its possible successors.¶

3.4. Features Needing Extensive Clarification

For a number of authorization-related features, the existing descriptions are inadequate for various reasons:¶

• In the description of the use of the mode attribute in implementing the POSIX-based authorization model, critical pieces of the semantics are not mentioned, while, ironically, the corresponding semantics for ACL-based authorization are discussed.¶

  This includes the authorization of file deletion and of modification of the mode, owner and owner-group attributes. For ACL-based authorization, there is an attempt to provide the description.¶

  The situation for authorization of RENAME is similar, although, in this case, the corresponding semantics for the ACL case are also absent.¶

• The description of authorization for ACLs is more complete but it needs further work, because the previous specifications make extensive efforts, in my view misguided, to allow an enormous range of server behaviors, making it hard for a client to know what the effect of many actions, and the corresponding security-related consequences, might be.¶

  Troublesome in this connection are the discussion of ACE mask bits which essentially treats every mask bit, as its own OPTIONAL feature, the use of "SHOULD" and "SHOULD NOT" in situations which it is unclear what valid reasons to ignore the recommendation might be, and cases in which it is is simply stated that some servers do some particular thing, leaving the unfortunate implication that clients need to be prepared for a vast range of server behaviors.¶

  This approach essentially treated ACLs in a manner appropriate to an experimental feature even though in appeaed in a Proposed Standard.¶

• Similar issues apply to descriptions related to the need to co-ordinate the values of the mode attribute and the ACL-related attributes.¶

  Although the need for such coordination is recognized. There are multiple modes of mapping an ACL to a corresponding mode together with multiple sources of uncertainty about the reverse mapping.¶

  In addition, certain of the mapping algorithms have flaws in that their behavior under unusual circumstances give results that appear erroneous.¶

Dealing with these issues is not straightforward, because the appropriate resolution will depend on:¶

• The actual existence of server implementations with non-preferred semantics.¶

  In some cases in which "SHOULD" was used, there may not have been any actual severs choosing to ignore the recommendation, eliminating the possibility of compatibility issues when changing the "SHOULD" to a formulation that restricts the server's choices.¶

• The difficulty of modifying server implementations to eliminate or narrow the effect of non-standard semantics.¶

  One aspect of that difficulty might be client or application expectations based on existing server implementations, even if the existing specifications give the client no assurance that that server's behavior is mandated by the standard.¶

• Whether the existing flaw in some existing recommended actions to be performed by the server is sufficiently troublesome to justify changing the specification at this point.¶

This sort of information will be used in deciding whether to:¶

• Narrow the scope of allowable server behavior to those actually used by existing severs.¶

• Limiting the negative effects of unmotivated SHOULDs by limiting valid reasons to ignore the recommendation to the difficulty of changing existing implementations.¶

  This would give significant guidance to future implementations, while forcing clients to live with the uncertainty about existing servers¶

• Tie a more restricted set of semantics to nominally unrelated OPTIONAL features such as implementation of dacl and sacl.¶

  This would provide a way to allow the development of newer servers to proceed on a firmer basis, without requiring changes on older servers that do not support these SMB-oriented attributes.¶

• Provide means that clients could use to determine, experimentally, what semantics are provided by the server.¶

  Would need to be supported by a requirement/assurance that a server behave uniformly, at least within the scope of a single file system.¶

• Allow the provision of other ways for the client to know the semantics choices made by the server or the file system.¶

Despite the difficulty of addressing these issues, if the protocol is to be secure and ACLs are to be widely available, these problems have to be addressed. While there has not been significant effort to provide client-side ACL APIs and there might not be for a while, we cannot have a situation in which the security specification makes that development essentially impossible.¶

3.5. Process Going Forward

Because of the scope of this document, and the fact that it is necessary to modify previous treatments of the subject previously published as Proposed Standards, it is necessary that the process of determining whether there is Working Group Consensus to submit it for publication be more structured than that used for the antecedent documents.¶

In order to facilitate this process, the necessary changes which need to be made, beyond those clearly editorial in nature, are listed in Appendix B. As working group review and discussion of this document and its successors proceeds, there will be occasion to discuss each of these changes, identified by the annotations described in Section 1.2.¶

Based on working group discussions, successive document versions will do one of the following for some set of consensus items:¶

• Deciding that the replacement text is now part of a new working group consensus.¶

  When this happens, future drafts of the document will be modified to remove the previous treatment, treat the proposed text as adopted, and remove Author Asides or replace them by new text explaining why a new treatment of the matter has been adopted or pointing the reader to an explanation in Appendix A.¶

  At this point, the consensus item will be removed from Appendix B and an explanation for the change will be added to Appendix A.¶

• Deciding that the general approach to the issue, if not necessarily the specific current text has reached the point of "general acceptance" as defined in Appendix B¶

  In this case, to facilitate discussion of remaining issues, the text of the document proper will remain as it is.¶

  At this point, the consensus item will be marked within the table in Appendix B as having reached general acceptance, indicating the need to prioritize discussion in the next document cycle, aimed at arriving at final text to address the issue.¶

  In addition, an explanation for the change will be added to Appendix A.¶

• Deciding that modification of the existing text is necessary to facilitate eventual consensus, based on the working group's input.¶

  In this case, there will be changes to the document proper in the next draft revision. In some cases, because of the need for a coherent description, text outside the consensus item may be affected.¶

  The table in Appendix B will be updated to reflect the new item status while Appendix A is not expected to change.¶

• Deciding that the item is best dropped in the next draft.¶

  In this case, the changes to the document proper will be the inverse of those when a change is accepted by consensus. The previous treatment will be restored as the current text while the proposed new text will vanish from the document at the next draft revision. The Author Aside will be the basis for an explanation of the consequences of not dealing with the issue.¶

  At this point, the consensus item will be removed from Appendix B.¶

The changes that the working group will need to reach consensus on, either to accept (as-is or with significant modifications) or reject can be divided into three groups.¶

• A large set of changes, all addressing issues mentioned in Section 1.1, were already present in the initial I-D so that there has been the opportunity for working group discussion of them, although that discussion has been quite limited so far.¶

  As a result, a small set of these changes is marked, in Appendix B, as having reached general acceptance.¶

  That subset of these changes changes, together with the organizational changes to support them are described in Appendix A.1.¶

• Another large set of changes were made in draft -02. These mostly concern the issues mentioned in Section 3.4 None of these changes is yet considered to have reached general acceptance.¶

  The issues that need to be addressed are described in Appendix A.2 while the possible approaches that might be taken to resolve these issues are described in Appendix A.3.¶

• There remain a set of potential changes for which a need is expected but for which no text is yet available.¶

  Such changes have associated Author Asides and are listed in Appendix B.¶

  The text for these changes is expected to be made available in future document revisions and they will be processed then, in the same way as other changes will be processed now.¶

  If and when such changes reach general acceptance, they will be explained in the appropriate subsection of Appendix A.¶

4.1. NFSv4 Security Terminology

In this section, we will define the security-related terminology used in this document. This is particularly important for NFSv4 because many of the terms terms related to security in previous specification may be hard to understand because their meanings have changed or have been used inconsistently, resulting in confusion.¶

The following terms are listed in alphabetical order:¶

• "Access Control" denotes any control implemented by a server peer to limit or regulate file system access to file system objects. It includes but is not limited to authorization decisions. Access control features can be divided into those which are "Discretionary" or "Mandatory" as described below.¶

• "ACL" or "Access Control List" denotes a structure used, like the mode (see below), to defines the privileges that individual users have with respect to a given file. These structures provide more options than modes with regard to the association of privileges with specific users or group and often provide a finer-graned privilege structure as well. This specification will have need to refer to two types of ACLs.¶

  The ACLs intended to be presented in the acl, sacl, and dacl attributes are called "NFSv4 ACLs". This ACL format, was modeled on the the semantics of the SMB ACL format which provide a privilege model substantially finer-grained than that provided by POSIX modes.¶

  [Consensus needed (Item #56a)]: Another ACL type derives from an attempt to define, within POSIX, a UNIX-oriented approach to ACLs which was published as a draft (POSIX 1003.1e draft 17), but subsequently withdrawn. Despite the withdrawal of this draft and the working group's decision to adopt a native NFsv4 ACL format based on SMB ACLs, this document will have to discuss these ACLs, which we will term "UNIX ACLs" because many server file systems do not support the finer-grained privilege model needed by the the NFSv4 ACL model and because many clients are built on systems whose only ACL-related API is based on the UNIX ACL model.¶

• "authentication" refers to a reliable determination that one making a request is in fact who he purports to be. Often this involves cryptographic means of demonstrating identity.¶

  This is to be distinguished from "identification" which simply provides a specified identity without any evidence to verify that the identification is accurate.¶

  In the past, these terms have been confused, most likely because of confusion engendered by th use of the term "authentication flavor" including flavors for which only identification is provided or which do not provide even identification.¶

• "authorization" refers to the process of determining whether a request is authorized, depending on the resources (e.g. files) to be accessed, the identity of the entity on whose behalf the request was issued, and the particular action to be performed.¶

  Depending on the type of request, the entity whose identity is referenced can be a user, a peer, or a combination of both.¶

  Authorization is distinct from authentication. However, performing authorization based on identities which have not been authenticated makes secure operation impossible since use of unauthenticated identities allows acceptance of requests that are not properly authorized if the sender has the ability, as it typically does, to pretend to be an authorized user/peer.¶

• "client" refers to the entity responsible for setting up a connection. In most cases the client and the requester reside on the same node but this not always the case for NFSv4 because of the possibility of callback requests in which the server makes some request of the client.¶

• "confidentiality" refers to the assurance provided, typically through encryption, that the contents of requests and responses are not inadvertently disclosed to unauthorized parties.¶

• "Discretionary Access Control" denotes forms of access control, that rely on a user, such as the owner, specifying the privileges that various users are to have.¶

• "Mandatory Access Control" denotes forms of access control that reflect choices made by the server peer and based on its policy and that are typically based on the identity of the client peer rather than the specific user making a request. While such access control is discussed in this document, it is important to note that many forms of mandatory access control are discussed by other NFsv4 documents and that there are forms that are not standardized.¶

• [Consensus Needed, Entire Bulleted Item (Items #21a, #57a)]: "Mode" designates a set of twelve flag bits used by POSIX-based systems to control access to the file with which it is associated. In NFSv4, there are represented by the REQUIRED attribute mode.¶

  The three high-order flags are generally accessed only by the client while low-order bits are divided into three three-bit fields, which give, in order of decreasing numeric value, the privileges to be associated with, the owner of the file, other users in the group owning the file, and users not in the above two categories.¶

  In most cases, the privileges associated with each successive group are no greater than those for the previous group. Modes whose privileges are of this form are referred to as "forward-slope modes" because the privilege level proceeds downward as successive groups of users are specified. Cases in which the contrary possibility is realized are referred to as "reverse-slope modes".¶

• "peer" refer to the entity which is charged with requesting or performing a specified request as opposed to the entity on whose behalf the request is requested or performed, the principal;¶

• "principal" refers to the specific entity (e.g. user) on whose behalf a request is being made.¶

• "privacy", has in the past been used to refer, to what is now referred to as "confidentiality".¶

  over time, this usage has changed so that the word most often refers to applicability of data to a single individual and person's right to prevent its unauthorized disclosure¶

  As a result, many references to "privacy" in previous are no longer appropriate and really refer to confidentiality.¶

  The NFSv4 protocol has no way to determine whether particular data items raise privacy concerns (In the new sense). NFSv4 provides confidentiality whatever type of data is being accessed so that private data is kept private.¶

• "integrity" refers to the assurance that data in a request has not been modified in the process of transmission. Such an assurance is generally provided b means of a cryptographic hash of the requests or response.¶

• "requester" is the entity making a request, whether that entity is on the client-side, as it most often is (forward-direction request) or the server side, in th case of callback (reverse-direction requests)¶

• "responder" is the entity performing a request, whether that entity is on the server side, as it most often is (forward-direction request) or the client side, in the case of callbacks (reverse-direction requests.¶

• "server" refers to the entity to which the client connects. In most cases the client and the responder reside on the same node but this not always the case for NFSv4 because of the possibility of callback requests in which the server makes some request of the client.¶

4.2. NFSv4 Security Scope Limitations

This document describes the security features of the NFSv4 protocol and is unable to address security threats that are inherently outside the control of the protocol implementors. Such matters as out of this document's scope.¶

As a way of clarifying the threats that this document, and the threat analysis in Section 18.4 can and cannot deal with, we list below the potential threats discussed Section 3.1 of [nist-209] and review how, if at all, it is discussed in the current document. In cases in which the threat is dealt with in this document, distinctions are to be made between cases in which the issues have been dealt with directly or have been delegated to a lower layer on which the protocol is built and whether the issue has been addressed by the changes to NFSv4 security made by this document.¶

• Regarding the possibility of "Credential Theft or Compromise", this is not a matter that the NFSv4 protocols concern themselves with or can address directly, despite its importance for security. Depending on the auth flavor chosen, either the client (for AUTH_SYS) or a third-party (for RPCSEC_GSS), usually Kerberos, will be responsible for credential verification.¶

  Since experience has shown that credential compromise (e.g. through "phishing" attacks) is a common occurrence, this problem cannot be ignored, even though NFSv4's reliance on RPC facilities for authentication might be thought to make it out-of-scope as it would be RPC if had an effective solution to the issue. However, the urgency of the situation this issue is such that will be discussed in Section 18.4.2, even though no definitive solutions to this issue are likely before this document is completed and published.¶

  Regardless of such issues, the likelihood of such compromise has had a role in decisions made regarding the acceptance and use of "superuser" credentials. The possibility of such compromise is also relevant to implementation of means to synchronize credentials when they are managed by the client, as described in Section 18.4.6.1¶

• Regarding the possibility of "Cracking Encryption", prevention of this is responsibility of the NFSv4 protocols but it is one which has been delegated to RPC, so that its discussion in Security Considerations will rely on RPCSEC_GSS and RPC-with-TLS impelentations to manage the selectio and replacement of kets for encryption so as to limit the possibility of such unwanted encryption key discovery.¶

• Regarding the possibility of "Infection of Malware and Ransomware", NFSv4 has no direct role in preventing such infection, but does have an important role in limiting its consequences, by limiting the the ability of Malware to access or modify data, through the file access authorization model supported by NFSv4 to limit access to authorized users. Of course, malware will be able to execute on behalf of the user mistakenly invoking it but the authorization model will server to limit the potential damage.¶

  The possibility of vertical privilege escalation is of concern as regard the possible elevation to "superuser" privileges. For this reason, this document recommends that any such escalation not be effective on the server, even if it happens on local clients for which NFSv4 has no role.¶

  Execution of a ransomeware-based attack requires the attacker to have the ability to read existing data and replacing it with an encrypted version together with the ability to temporarily hide the encryption from ongoing operations by intercepting requests to read encrypted data and substitute the unencrypted data.¶

• Regarding the possibility of "Backdoors and Unpatched Vulnerabilities", it needs to be noted that the NFSv4 protocols do not specify any backdoors even though it is possible that might choose to provide such backdoors. Since it is not practical to specifically prohibit the existence of such backdoors nor would they be enforceable if written, this document will not attempt to do so. Instead, Section 18.2.3 will note the possibility of such backdoors and recommend against any such implementation, and include implementations containing backdoors in the category of insecure use that will not be dealt with in Section 18.4.¶

  Although it is expected that vulnerabilities will be due to incorrect implementations and thus outside the scope of this document, the possibility of a protocol design errors cannot be excluded. In dealing with such eventualities, it is likely that complete remediation would require co-ordinated changes on the client and server¶

• Regarding the possibility of "Privilege Escalation", NFSv4 has dealt with the possibility of vertical escalation by not allowing a client-local escalation to superuser privileges to be effective on the server.¶

  With regard to horizontal "escalation", NFSv4 provides for the use of various means RPC authentication of principals but relies on the client operating system to make sure that one user principal cannot masquerade as another.¶

• Regarding the possibility of "Human Error and Deliberate Misconfiguration", the approach taken is to limit the need for the server to make complicated decisions regarding the security requirements of each section of its namespace, with many opportunities for misconfiguration, if the chosen security requirements are insufficiently restrictive. This is in contrast to previous specifications which made such configuration the centerpiece of the security approach.¶

  Although it is possible to create configurations where certain data, generally publicly accessible, are to be made available without encryption, this is expected to be a rarely used option with the possibility of in-transit modification kept in mind before adopting such use.¶

• Regarding the possibility of "Physical Theft of Storage Media", this a matter which, while of concern to those deploying NFSv4 server, will be considered out-of-scope since there is nothing that the protocol could do to deal with this threat.¶

• Regarding the possibility of "Network Eavesdropping", when the protocol implementation follows the recommendations in this document, the protocol's use of RPC facilities is designed, through the consistent use of encryption to make it difficult for an attacker to have access to the data being transmitted, to modify it, or inject requests into an existing data stream.¶

  The possibility of an attacker with access to the network creating a new connection is best considered as a case of the attacker pretending to be a client and is addressed in Section 18.4.3.¶

• Regarding the possibility of "Insecure Images, Software and Firmware", while attention to such matters is important for those deploying NFSv4, it is important to note that these are matters outside the control the NFSv4, which has to assume that the infrastructure it is built is working properly. As a result, this document will not deal with the possibility of such threats.¶

5.1. Format of Id Strings in Authorization-related Attributes

Unlike the case in NFSv3, users and groups are represented by UTF-8-encoded Unicode strings. These include:¶

• [Consensus needed (Item #57c)]: The REQUIRED attribute owner, as described in Section 5.3.3.¶
• [Consensus needed (Item #57c)]: The REQUIRED attribute owner_group, as described in Section 5.3.4¶
• The "who" field within Access Control Entries as described in Section 6.2. These entries appear in the acl, dacl, and sacl attributes.¶

[Author Aside, Including List (Item #59a)]: This section had to be extensively revised in order to be clearer. The previous treatment, which is not reproduced here, can be found in Section 5.9 of [RFC8881]. In the author's opinion, major revision was necessary because:¶

• The existing treatment, by leaving the methods of mapping between strings and local user ids unspecified, created an interoperability issue.¶

  While the need for flexibility might make it impossible to specify mapping fully, the requirements for agreement between client and server need to be specified more clearly.¶

• There is inadequate attention to the additional implementation needs to support multiple domain values.¶

  The difficulties inherent in supporting all possible domains are obscured, with the very real security issues essentially ignored.¶

• The description of the domain value as "meant to be a DNS domain" is not clear and makes it harder to focus on the real difficulties involved in providing coherent secure means of providing necessary mappings for multiple domins.¶

• ¶

[Consensus Needed, Including Rest of Section (Items #52a)]:¶

These identifiers are represented by strings of the form "name@domain" in order to allow:¶

• Servers to support multiple clients each with users from one or more domains, without requiring construction of a single list of users together with associated authentication info.¶
• The number of users from being limited by existing hard-to-extend limits such as the POSIX/NFSv3 use of a 32-bit field to represent a user or group id.¶

These strings are assigned the xdr type utf8str_mixed because the name and domain portions are treated differently:¶

• The name portion is a utf8 string that is matched in a case- sensitive manner without any attempt to treat distinct canonically equivalent strings as the same.¶
• The handling of the domain portion, including recognition of equivalent string as the same is specified by the server. However, when multple domains are supported, case-insensitivity of ASCII characters is mandated by DNS, as well as translations to and from punycode-encoded forms.¶

It is expected that the client and server will have their own local representation of users and user groups that is used for local storage or presentation to the end user. In addition, it is expected that when these attributes are transferred between the client and server, the local representation is translated to the form "name@domain".¶

Although this allows for a client and server that do not use the same local representation the ability to translate to a common format, there will often be cases in which both client and sever use the same internal format. This often happens with servers that only support a single domain. However, regrdless of whether these forms are, in fact, different, it is inecessary that client and server agree on the following:¶

• The set of valid strings that can appear as the domain portion of these identifiers. This set must have at least a single member but when this not the case, the set known to each client must be a subset of the set recognized by the server.¶

• For each valid domain string passed by a client and accepted by a server, the server and client must agree on a means by which the user designated by each user and group name can be mapped to a user or group so that each interprets all name@domain strings identically.¶

  The above applies whether the client and server use the same internal name repreentation or not.¶

Security principals and the groups they belong to need to be integrated within this arrangement since these identities need to be presented to the server in a form compatible with this new format. The specfics depend on the auth flavor providing the principal identfication:¶

• When auth flavors based on RPCSEC_GSS are used, the prinipal is generally identified in a form easily converted to the name@domain fornat. For example, with Kerberos, the kerberos user name can provide the name ortion while kerberos realm can serve as the domain portion.¶

• When the AUTH_SYS auth flavor is used, principals are identified by a 32-bit numeric identifier which can be generally teated in the same manner as numeric id's used locally within the file system to arive at a name with the domain being the one assigned that filesysten.¶

  The idenification of principals MAY be subject to filtering to eliminate users with a high level of privilege.¶

  In the case of servers with filesystems that support the use of multiple domains, clients for which use of AUTH_SYS is supported need to be assigned to a specific domain so that the principal identfications received are properly dealt with.¶

The translation used to interpret owner and group strings is not specified as part of the protocol. This allows various solutions to be employed, as long as the requirement mentioned above are satisfied. For example, a local translation table may be consulted that maps a numeric identifier to the user@domain syntax. A name service may also be used to accomplish the translation. A server may provide a more general service, not limited by any particular translation (which would only translate a limited set of possible strings) by storing the owner and owner_group attributes in local storage without any translation or it may augment a translation method by storing the entire string for attributes for which no translation is available while using the local representation for those cases in which a translation is available.¶

[Author Aside:] The next sentence previously used the word "SHOULD. Since the author has been unable to determine valid reasons to do otherwise and has no reason velieve that any exist, the new text uses "MUST". It is possible that the original author might have been thinking of "nobody" for this but that case needs to be addressed separately and will need to be clearly distinguished from "nobody@domain".¶

Servers that do not provide support for all possible values of the owner and owner_group attributes MUST return an error (NFS4ERR_BADOWNER) when a string is presented that has no translation, as the value to be set for a SETATTR of the owner, owner_group, or as the who value in an ACE within the acl, sacl, or dacl attributes. When a server does accept an owner or owner_group value as valid on a SETATTR (and similarly for the owner and group strings in an ACL), it is promising to return that same string when a corresponding GETATTR is done. Configuration changes (including changes from the mapping of the string to the local representation) and ill-constructed name translations (those that include aliasing) may make that promise impossible to honor. Servers need to make appropriate efforts to avoid a situation in which these attributes have their values changed when no real change to ownership has occurred.¶

The "domain" portion of the owner string will often be a DNS domain name, for example, user@example.org. Servers should accept as valid a set of users for at least one value of the domain portion. A server may treat other domains as having no valid translations. A more general service is provided when a server is capable of accepting users for multiple domains values but the following will need to be attended to:¶

• When use of AUTH_SYS is allowed, the translation of numeric ids to the form name@domain becomes problematic.¶

  The server will need to determine the domain value to be used based on the identity of the client peer.¶

• When numeric ids are used in the file system the handling of those ids needs to be modified to support multiple sets of users with one set for each of the various domain values supported.¶

  One option is to add a small (i.e. 8- or 16-bit) field to represent the chosen domain value will leaving the 32-bit id field as it is.¶

  It is also possible to map individual 32-bit id spaces into a single 32-bit id space. HOwever,this involves eastablishing for each component id space a restricted mange, so that the mapping can be done without resulting in conflicting reverse mappings.¶

In cases in which there is no translation available to the client or server, the attribute value will be constructed without the "@". The absence of the @ from the user or group string signifies that no translation was available at the sender and that the receiver of the attribute should not use that string as a basis for translation into its own internal format. When the string consists of a numeric value with no leading zeroes it can be interprested as represeting the corresponding 32-bit numeric id. Even though such attribute values cannot be translated, they might still be useful. In the case of a client, the attribute string may be used for local display of ownership. However, in the case in which the server receives such a string, it is less likely to be useful and might be harmful in that its use by the server might undercut the value of the translation to the form name@domain. In order to avoid these negative effects:¶

• When a numeric value is received in an attribute being set where an RPCSECGSS-based auth flavor is being used, the SETATTR MUST return an error (NFS4ERR_BADOWNER).¶
• When the auth flavor AUTH_SYS is being used, the numeric id provided to the server as the principal identification MAY be translated to the numeric string form, rather than to the form name@domain.¶
• When the auth flavor AUTH_SYS is being used, the seerver MAY accept user and groups identified by ids using the string numeric form and return them in that form. However, when it does so it still MUST return these values, in the name@domain form to those using other auth flavors.¶

[Author Aside, Including List (Items #52a, #60a)]: Something needs to be done about the failure of the corresponding text in RFC8881 to deal approriately with root@domain and nobody@domain, either to exclude these or include them with appropriate explanations. Specifically:¶

• With regard to the case of "nobody", the primary issue is that "nobody@domain" is not addressed, although "nobody", which should not occur, is.¶

  A further difficulty is the use of the term "anonymous" with the intention to include unidentified and unauthentcated users as well as those which are not approrpriately authenticated.¶

• With regard to the case of "root", the issue is not mentioned at all, leaving it unclear as to whether this sort of special handling is gone, or is dependent now on the name "root" or the mumeric id zero despite the geneneral deprecation of numeric ids.¶

  The possibility of support for multiple domains, creates additional complexity whih needs to be addressed.¶

[Consensus Needed (Item #60a)]: An owner string of the form "nobody@domain" may be used to designate an anonymous or unauthenticated user, which will be associated with a file created by a security principal whose identity is not determinable or cannot be mapped through normal means to the owner attribute. Users and implementations of NFSv4.1 should avoid the use of the string "nobody" to identify an actual user.¶

[Consensus Needed (Item #52a)]: Certain id strings that map to known numeric values such as zero MAY be assigned special privileges with regard to operation authorization, allowing operations to be authoized that POSIX or ACL-based authentication might disallow. The granting of such privileges MUST NOT be based on the user name (e.g. "root"). Instead, the server MUST only use the principal id or information returned by a secure id mapping facility in assigning such privileges, which MAY be assigned differently based on the reliability of the authentication method used. When multiple domains are supported, the privilege assignments might be diffeent for diffeent domains, but the mapping of ids into a value used internally by the file systen is not to be considered in deciding about granting such privileges.¶

5.2. Table of Authorization-related Attributes

The list of authorization-related attributes appears in Table 1.¶

The meaning of the columns of the table are:¶

Name:

The name of the attribute.¶

Id:

The number assigned to the attribute. In the event of conflicts between the assigned number and minor version specification documents, the former is authoritative, but conflicts should be resolved with Errata to this document and/or the minor version specifcation document. See [errata] for the Errata process.¶

Data Type:

The XDR data type of the attribute.¶

Acc:

Access allowed to the attribute. R means read-only (GETATTR may retrieve, SETATTR may not set). W means write-only (SETATTR may set, GETATTR may not retrieve). R W means read/write (GETATTR may retrieve, SETATTR may set).¶

Defined in:

The section of this specification that describes the attribute.¶

5.3. POSIX-oriented Authorization-related Attributes

[Consensus Needed (Item #57d)]: The REQUIRED attributes owner, owning_group, and mode enable use of a POSIX-based authorization model, as described in Section 8.3. Given that all of these attributes MUST be supported, this authorization model is always available.¶

These attributes are also of use when ACL-based authorization is in effect.¶

• The values of the owner and owner_group attributes affect the interpretation of the special "who" values "@OWNER" AND "@GROUP">¶

• Changes to the acl and dacl attributes will often result in corresponding changes to mode attribute.¶

• Setting the mode attribute will often override the values in acl and dacl attributes, even if tere has been no changes to the authorzation-related bits.¶

  The set_mode_masked attribute can be set when changing bits in the mode, if the authorization-related bits are not to be changed and there is a need not to update authorization-related ACEs.¶

const MODE4_SUID = 0x800;  /* set user id on execution */
const MODE4_SGID = 0x400;  /* set group id on execution */
const MODE4_SVTX = 0x200;  /* save text even after use */
const MODE4_RUSR = 0x100;  /* read permission: owner */
const MODE4_WUSR = 0x080;  /* write permission: owner */
const MODE4_XUSR = 0x040;  /* execute permission: owner */
const MODE4_RGRP = 0x020;  /* read permission: group */
const MODE4_WGRP = 0x010;  /* write permission: group */
const MODE4_XGRP = 0x008;  /* execute permission: group */
const MODE4_ROTH = 0x004;  /* read permission: other */
const MODE4_WOTH = 0x002;  /* write permission: other */
const MODE4_XOTH = 0x001;  /* execute permission: other */

5.4. ACL-based Authorization-related Attributes

[Author Aside: (Items #14a, #15a... )]: The treatment of the various ACL-based attributes in the included subsections replaces the corresponding sections in earlier minor sections, in which the attribute descriptions were not consolidated in one place and were disbursed amonga number of top-level sections. Where it has been necessary to make significant changes, the annotations for those changes, including author asides and proposed text, appear here while vestigial text that is now superseded has not been brought forward.¶

The per-object attributes acl, dacl, and sacl sacl consist of an ACL object as described in Section 6 and its subsections.¶

      const ACL4_SUPPORT_ALLOW_ACL    = 0x00000001;
      const ACL4_SUPPORT_DENY_ACL     = 0x00000002;
      const ACL4_SUPPORT_AUDIT_ACL    = 0x00000004;
      const ACL4_SUPPORT_ALARM_ACL    = 0x00000008;

5.5. Authorization-related Attributes for MAC

6.1. ACL Semantics Choices

[Consensus Needed, Including List (Item #61e)]: There are two potential authorization models that can be supported using the acl and dacl attributes:¶

• Full NFSv4 ACLs, with expanded semantics derived from Windows ACLs.¶

  This includes a finer-grained permissions model, the inclusion of DENY ACEs, and the use of ACLs for non-authorization functions, via the use of AUDIT and ALARM ACEs.¶

• UNIX ACLs, based on the withdrawn POSIX ACL draft.¶

  This approach retains the three bits typical of POSIX semantics and maps them, with a number of implied restrictions, to the more expansive set of ACE mask bits defined in Section 6.4.¶

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

• The keyword SHOULD was used for just about every element of ACL semantics, without proper attention to the meaning of that term as defined in [RFC2119].¶

  The resulting text ofteb stated that these uses of "SHOULD" were "intentional" without explicitly providing any reason that would justify not performing the recommended action or discussion of the consquenes of doing so.¶

  The result was to effectively replace a single MAY by a lare number instances of SHOULD each treated essentilly as MAY with an exponential expansion of the number behaviors a client would have to be prepared for.¶

• In many cases, the use of SHOULD with the implied meaning MAY, leaves open more than two possiilities since it is not always clear what restictions apply to the case in which the recommendation is bypassed.¶

  As a result, the number of notionally valid server behaviors can expand even beyond the exponential increase discuused above.¶

• In the handling of the mapping of ACLs to modes, important when ACLs are supported and used, there are further sources of confusion that need to be resolved.¶

  What is almost surely the preferred method in introduced in Section 6.3.2 of [RFC8881] without a MUST or even a SHOULD but instead says it "can be used", even though Section 6.4 of [RFC8881] states that these methods are covered by an "intentional" SHOULD.¶

  An alternate method is introduced by stating that "Some server implementations" do, without any discussion of the effect on interoperability, although it does say that "implementations are discouraged" from doing this. Although Section 6.4 of [RFC8881] indicates the motivation of this alternate method is to provide support for servers supporting the withdrawn POSIX draft ACLs, there is no indication of a normative connection betweeen these two choices.¶

[Author Aside, Including List (Item #61e)]: An important component in removing the stigmata of the designation of acl, and dacl attributes as "under-specified" would by to allow a single choice of ACL semantics to be made and eliminate, to the degree possible, the multitude of ill-defined choices present in previous specfications. Some possibilities to be considered are discussed below. An important consideraion is the possible existence of server implementations that, for whatever reason, supported some hybridized versions of NFsv4 and UNIX ACLs.¶

• Because POSIX draft ACLs have no provision for ACEs corresponding to DENY ACEs, support for such ACEs could be treated as an indication that the support provided is not for UNIX ACLs.¶

  While the existing specifications allows UNIX ACLs to be extended to support DENY ACEs, among a large range of possible extensions, it is nost likely that no such implementatons exist, which would allow the approach suggested above to be adopted.¶

• Because POSIX draft ACLs have no provision for AUDIT or AlARM ACEs, support for such ACEs could be treated as an indication that the support provided is not for UNIX ACLs.¶

  While the existing specifications allows UNIX ACLs to be extended to support these sort of ACEs, among a large range of possible extensions, it is nost likely that no such implementatons exist, which would allow the approach suggested above to be adopted.¶

  The above applies whether the ACE mask in this hypotenetical extension, uses the full NFSv4 ACL mask described in Section 6.4 or the restricted set of mask configurations derived from the three POSIX permission bits.¶

• While it might be possible for a server to provide support for both sorts of ACL semantics and could do so on differenr file ystems, it appears not to be possible currently.¶

  Some approaches to making both sets of semantics avalilable in the conext of a single filesysten are discussed in Section 17.2.¶

[Consensus Needed, Thru end of Section (Item #61e)]: A client can determine the sort of semantics provided by examining the set of ACE types supported, as reported by the aclsupport attribute for the current file sytem. If only ALLOW ACEs are supported, it can be assumed that the ACL support is limited to that provided by the UNIX ACL model. Otherwise, support for the NFSv4 ACL model is indicated.¶

The semantics of ACLs provided for a given file system has the following effects, whic clients might need to be aware of:¶

• There is an important effect on the handling of ACE masks as described in Section 6.6.¶

• The computation of mode value from ACLs can be affected as described in Setions 10.3 and 10.4¶

6.2. Access Control Entries

The attributes acl, sacl (v4.1 only) and dacl (v4.1 only) each contain an array of Access Control Entries (ACEs) that are associated with the file system object. The client can set and get these attributes while the server is responsible for using the ACL-related attributes to perform access control. The client can use the OPEN or ACCESS operations to check access without modifying or explicitly reading data or metadata.¶

The NFS ACE structure is defined as follows:¶

typedef uint32_t        acetype4;

typedef uint32_t        aceflag4;

typedef uint32_t        acemask4;

struct nfsace4 {
        acetype4        type;
        aceflag4        flag;
        acemask4        access_mask;
        utf8str_mixed   who;
};

6.3. ACE Type

The constants used for the type field (acetype4) are as follows:¶

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

All four are permitted in the acl attribute. For NFSv4.1 and beyond, only the ALLOWED and DENIED types are used in the dacl attribute, and only the AUDIT and ALARM types.x used in the sacl attribute.¶

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

6.4. ACE Access Mask

The bitmask constants used for the access mask field of the ACE are as follows:¶

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, for example, ACE4_READ_DATA and ACE4_LIST_DIRECTORY. The mask entries ACE4_LIST_DIRECTORY, ACE4_ADD_FILE, and ACE4_ADD_SUBDIRECTORY are intended to be used with directory objects, while ACE4_READ_DATA, ACE4_WRITE_DATA, and ACE4_APPEND_DATA are intended to be used with non-directory objects.¶

6.5. Uses of Mask Bits

[Author Aside]: Because this section has been moved to be part of a general description of ACEs, not limited to authorization, the descriptions no longer refer to permissions but rather to actions. This is best considered a purely editorial change, but, to allow for possible disagreement on the matter, it will be considered, here and in Appendix B, as consensus item #3.¶

[Author Aside]: In a large number of places, SHOULD is used inappropriately, since there appear to be no valid reasons to allow a server to ignore what might well be a requirement. Such changes are not noted individually below. However, they will be considered, here and in Appendix B, as consensus item #4a.¶

[Author Aside}: In a significant number of cases the ACCESS operation is not listed as a operation affected by the mask bit. These additions are not noted individually below. However, they will be considered, here and in Appendix B, as consensus item #5a.¶

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

• Revisions were necessary to clarify the relationship between READ_DATA and EXECUTE. These are part of consensus item #7a.¶

• Revisions were necessary to clarify the relationship between WRITE_DATA and APPEND_DATA. These are part of consensus item #8a.¶

• Clarification of the handling of RENAME by ADD_SUBDIRECTORY. This is part of consensus item #9a.¶

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

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

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

[Consensus Item, Including List (Item #6b): The full description of the role of the sticky-bit appears in Section 5.3.1. In evaluating and understanding the relationship between the handling of this bit when NFSv4 ACLs are used and when they are not, the following points need to be kept in mind:¶

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

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

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

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

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

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

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

ACE4_READ_DATA¶

• Operation(s) affected:

  READ¶

  OPEN¶

  ACCESS¶

  Discussion:

  The action of reading the data to the data of the file.¶

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

  [Author Aside]: The treatment needs to be clarified to make it appropriate to all ACE types.¶

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

ACE4_LIST_DIRECTORY¶

• Operation(s) affected:

  READDIR¶

  Discussion:

  The action of listing the contents of a directory.¶

ACE4_WRITE_DATA¶

• Operation(s) affected:

  WRITE¶

  OPEN¶

  ACCESS¶

  SETATTR of size¶

  Discussion:

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

  [Consensus Needed (Item #8a)]: The action of modifying existing data bytes within a file's current data.¶

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

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

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

ACE4_ADD_FILE¶

• Operation(s) affected:

  CREATE¶

  LINK¶

  OPEN¶

  RENAME¶

  Discussion:

  The action of adding a new file in a directory. The CREATE operation is affected when nfs_ftype4 is NF4LNK, NF4BLK, NF4CHR, NF4SOCK, or NF4FIFO. (NF4DIR is not included because it is covered by ACE4_ADD_SUBDIRECTORY.) OPEN is affected when used to create a regular file. LINK and RENAME are always affected.¶

ACE4_APPEND_DATA¶

• Operation(s) affected:

  WRITE¶

  ACCESS¶

  OPEN¶

  SETATTR of size¶

  Discussion:

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

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

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

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

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

ACE4_ADD_SUBDIRECTORY¶

• Operation(s) affected:

  CREATE¶

  RENAME¶

  Discussion:

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

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

ACE4_READ_NAMED_ATTRS¶

• Operation(s) affected:

  OPENATTR¶

  Discussion:

  The action of reading the named attributes of a file or of looking up the named attribute directory. OPENATTR is affected when it is not used to create a named attribute directory. This is when 1) createdir is TRUE, but a named attribute directory already exists, or 2) createdir is FALSE.¶

ACE4_WRITE_NAMED_ATTRS¶

• Operation(s) affected:

  OPENATTR¶

  Discussion:

  The action of writing the named attributes of a file or creating a named attribute directory. OPENATTR is affected when it is used to create a named attribute directory. This is when createdir is TRUE and no named attribute directory exists. The ability to check whether or not a named attribute directory exists depends on the ability to look it up; therefore, users also need the ACE4_READ_NAMED_ATTRS permission in order to create a named attribute directory.¶

ACE4_EXECUTE¶

• Operation(s) affected:

  READ¶

  OPEN¶

  ACCESS¶

  REMOVE¶

  RENAME¶

  LINK¶

  CREATE¶

  Discussion:

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

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

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

  • nfsuser:ACE4_EXECUTE:ALLOW¶

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

  • nfsuser:ACE4_EXECUTE:ALLOW¶

  and MUST NOT return:¶

  • nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW¶

ACE4_EXECUTE¶

• Operation(s) affected:

  LOOKUP¶

  Discussion:

  The action of traversing/searching a directory.¶

ACE4_DELETE_CHILD¶

• Operation(s) affected:

  REMOVE¶

  RENAME¶

  Discussion:

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

ACE4_READ_ATTRIBUTES¶

• Operation(s) affected:

  GETATTR of file system object attributes¶

  VERIFY¶

  NVERIFY¶

  READDIR¶

  Discussion:

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

ACE4_WRITE_ATTRIBUTES¶

• Operation(s) affected:

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

  Discussion:

  The action of changing the times associated with a file or directory to an arbitrary value. Also permission to change the mimetype, hidden, and system attributes. A user having ACE4_WRITE_DATA or ACE4_WRITE_ATTRIBUTES will be allowed to set the times associated with a file to the current server time.¶

ACE4_WRITE_RETENTION¶

• Operation(s) affected:

  SETATTR of retention_set, retentevt_set.¶

  Discussion:

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

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

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

  [Consensus Needed (Items #10a, #11a)]: Options for coarser-grained treatment involving this mask bit are discussed in Section 6.6¶

ACE4_WRITE_RETENTION_HOLD¶

• Operation(s) affected:

  SETATTR of retention_hold.¶

  Discussion:

  The action of modifying the administration retention holds.¶

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

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

  [Consensus Needed (Items #10a, #11a)]: Options for coarser-grained treatment of this mask bit are discussed in Section 6.6¶

ACE4_DELETE¶

• Operation(s) affected:

  REMOVE¶

  Discussion:

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

ACE4_READ_ACL¶

• Operation(s) affected:

  GETATTR of acl, dacl, or sacl¶

  NVERIFY¶

  VERIFY¶

  Discussion:

  The action of reading the NFSv4 ACL.¶

ACE4_WRITE_ACL¶

• Operation(s) affected:

  SETATTR of acl and mode¶

  Discussion:

  The action of modifying the acl or mode attributes.¶

ACE4_WRITE_OWNER¶

• Operation(s) affected:

  SETATTR of owner and owner_group¶

  Discussion:

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

ACE4_SYNCHRONIZE¶

• Operation(s) affected:

  NONE¶

  Discussion:

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

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

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

6.6. Requirements and Recommendations Regarding Mask Granularity

This is a new section which replaces material formerly in the previous section, cited here as "Previous Treatment. The new material, constituting the remainder of the section is proposed to replace it. All such unannotated material is to be considered as part of consensus item #11b.¶

[Previous Treatment (Item #11b)]: Server implementations need not provide the granularity of control that is implied by this list of masks. For example, POSIX-based systems might not distinguish ACE4_APPEND_DATA (the ability to append to a file) from ACE4_WRITE_DATA (the ability to modify existing contents); both masks would be tied to a single "write" permission bit. When such a server returns attributes to the client that contain such masks, it would show ACE4_APPEND_DATA and ACE4_WRITE_DATA if and only if the the write permission bit is enabled.¶

[Previous Treatment (Item #11b)]: If a server receives a SETATTR request that it cannot accurately implement, it should err in the direction of more restricted access, except in the previously discussed cases of execute and read. For example, suppose a server cannot distinguish overwriting data from appending new data, as described in the previous paragraph. If a client submits an ALLOW ACE where ACE4_APPEND_DATA is set but ACE4_WRITE_DATA is not (or vice versa), the server should either turn off ACE4_APPEND_DATA or reject the request with NFS4ERR_ATTRNOTSUPP.¶

[Author Aside]: Giving servers a general freedom to to not support the masks defined in this section creates an unacceptable level of potential interoperability problems. With regard to the specific example given, it is hard to imagine a server incapable of distinguishing a write to an offset within existing file and one beyond it. This applies whether the server in question is implemented within a POSIX-based system or not. It is true that a server that used the unmodified POSIX interface to interact with the file system, rather than a purpose-built VFS, would face this difficulty, but it not clear how that fact could justify the client compatibility issues that accommodating this behavior in the protocol would generate. A further difficulty with the previous treatment is that it is at variance with the approach to other cases in which ACEs are stored with the understanding that implementations of other protocols might be responsible for enforcement.¶

[Author Aside]: A replacement clearly needs to be based on the idea that these mask bits were included in NFSv4 for a reason, and that exceptions need to be justified, and take interoperability issues into account. The treatment below attempts to do that.¶

[Consensus Needed (Items #11b, #61f): All implementations of the sacl attribute and of the acl and dacl attributes implementing NFSv4 ACL semantics SHOULD follow the definitions provided above in Section 6.5, which allow finer-grained control of the actions allowed to specific users than is provided by the mode attribute. Valid reasons to bypass this guidance include the need for compatibility with clients expecting a coarser-grained implementation. In the case of implementation of the acl and dacl implementations providing UNIX ACL semantics, coarser-grained implementations can be used, that map each of the three permission bits into a set of masks all controlled by that permission bit.¶

[Consensus Needed (Items #10b, #11b, #61f)]: The specific cases in which servers may validly provide coarser-grained implementations are discussed below.¶

[Consensus Needed, Including List (Items #10b, #11b, #61f)]: Servers not providing the mask granularity described in Section 6.5 MUST NOT treat masks other than described in that section except as listed below.¶

• Servers that do not distinguish between WRITE_DATA and APPEND_DATA need to make it clear to clients that support for append-only files is not present. For file systems providing support for the semantics of UNIX ACLs, the fact that this semantic information is available to the client satisfies the requirement. In other cases, requests to set NFSv4 ACLs where the handling for these two masks are different for any specified user or group MUST be rejected with NFS4ERR_ATTRNOTSUPP.¶

  In cases in which these two bits have different values, They cannot be enforced when opening a flile and the appropriate bits need to be checked at WRITE time.¶

• Servers that combine either of the masks WRITE_RETENTION or WRITE_RETENTION_HOLD with WRITE_ATTRIBUTES need to make it clear to clients that the finer-grained treatment normally expected is not available. To do that, requests to set NFSv4 ACLs in which the two combined masks are explicitly assigned different permission states (i.e. one is ALLOWED while the other is DENIED) for any specific user or group are to be rejected with NFS4ERR_ATTRNOTSUPP.¶

[Consensus Needed, Including List (Items #10b, #11b, #61f)]: The above are in line with the requirement that attempts to set NFSv4 ACLs that the server cannot enforce, it needs to be clear that there are cases in which such ACLs need to be set with the expectation that enforcement will be done by the local file system or by another file access protocol. In particular,¶

• In handling the mask bit SYNCHRONIZE, the server is not responsible for enforcement and so can accept NFSv4 ACLs it has no way of enforcing.¶

• When mask bits refers to an OPTIONAL feature that the server does not support such as named attributes or retention attributes, the server is allowed to accept NFSv4 ACLs containing mask bits associated with the unimplemented feature, even though there is no way these could be enforced. The expectation is that the files might be accessed by other protocols having such support or might be copied, together with associated ACLs to servers capable of enforcing them.¶

6.7. Handling of Deletion

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

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

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

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

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

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

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

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

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

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

6.8. 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. Also problematic is the use of the term "need not", suggesting that the server does not need any justification for choosing these flags, defined by the protocol. At least it needs to be said that the server SHOULD support the defined ACE flags. After all they were included in the protocol for a reason.¶

[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 dealing how an implementation 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)]: Servers SHOULD support the flag bits defined above as described in Section 6.9. 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.¶

6.9. Details Regarding ACE Flag Bits

ACE4_FILE_INHERIT_ACE

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

ACE4_DIRECTORY_INHERIT_ACE

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

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

ACE4_NO_PROPAGATE_INHERIT_ACE

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

ACE4_INHERIT_ONLY_ACE

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

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

ACE4_SUCCESSFUL_ACCESS_ACE_FLAG and ACE4_FAILED_ACCESS_ACE_FLAG

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

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

ACE4_IDENTIFIER_GROUP

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

ACE4_INHERITED_ACE

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

6.10. ACE Who

The "who" field of an ACE is an identifier that specifies the principal or principals to whom the ACE applies. It may refer to a user or a group, with the flag bit ACE4_IDENTIFIER_GROUP specifying which.¶

There are several special identifiers that need to be understood universally, rather than in the context of a particular DNS domain.¶

[Author Aside, including list]: so far, so good, but the following problems need to be addressed:¶

• Lack of clarity about which special identifiers can be understood by NFSv4.¶

• Confusion of "authentication" and "identification".¶

[Previous treatment (Item #50a)]: Some of these identifiers cannot be understood when an NFS client accesses the server, but have meaning when a local process accesses the file. The ability to display and modify these permissions is permitted over NFS, even if none of the access methods on the server understands the identifiers.¶

[Consensus Needed (Item #50a)]: These identifiers, except for OWNER@, GROUP@, EVERONE@, cannot be reliably understood when an NFS client accesses the server, but might have meaning when a local process accesses the file or when protocols other than NFSv4 are used As a result, when ACEs containing these who values are encountered, the server is free to make its own judgment as to whether any particular request will be treated as matching.¶

[Consensus Needed (Item #50a)]: The ability to display and modify these permissions is provide for by NFSv4, even though they are not useful when processing NFSv4 requests,¶

To avoid conflict, these special identifiers are distinguished by an appended "@" and will appear in the form "xxxx@" (with no domain name after the "@"), for example, ANONYMOUS@.¶

{Previous treatment (Item #51a)]: The ACE4_IDENTIFIER_GROUP flag MUST be ignored on entries with these special identifiers. When encoding entries with these special identifiers, the ACE4_IDENTIFIER_GROUP flag SHOULD be set to zero.¶

[Author Aside]: I don't understand what might be valid reasons to ignore this or how a server would respond in the case the that it was ignored.¶

[Consensus Needed (Item #51a)]: The ACE4_IDENTIFIER_GROUP flag MUST be ignored on entries with these special identifiers. When encoding entries with these special identifiers, the ACE4_IDENTIFIER_GROUP flag MUST be set to zero.¶

It is important to note that "EVERYONE@" is not equivalent to the UNIX "other" entity. This is because, by definition, UNIX "other" does not include the owner or owning group of a file. "EVERYONE@" means literally everyone, including the owner or owning group.¶

6.11. Automatic Inheritance Features

The acl attribute consists only of an array of ACEs, but the sacl (Section 5.4.5) and dacl (Section 5.4.4) attributes also include an additional flag field.¶

struct nfsacl41 {
        aclflag4        na41_flag;
        nfsace4         na41_aces<>;
};

The flag field applies to the entire sacl or dacl; three flag values are defined:¶

const ACL4_AUTO_INHERIT         = 0x00000001;
const ACL4_PROTECTED            = 0x00000002;
const ACL4_DEFAULTED            = 0x00000004;

and all other bits are to be cleared. The ACE4_INHERITED_ACE flag can be set in the ACEs of the sacl or dacl (whereas it always needs to be cleared in the acl).¶

Together these features allow a server to support automatic inheritance, which we now explain in more detail.¶

Inheritable ACEs are normally inherited by child objects only at the time that the child objects are created; later modifications to inheritable ACEs do not result in modifications to inherited ACEs on descendants.¶

However, the dacl and sacl provide an OPTIONAL mechanism that allows a client application to propagate changes to inheritable ACEs to an entire directory hierarchy.¶

A server that supports this feature performs inheritance at object creation time in the normal way, and SHOULD set the ACE4_INHERITED_ACE flag on any inherited ACEs as they are added to the new object.¶

A client application such as an ACL editor may then propagate changes to inheritable ACEs on a directory by recursively traversing that directory's descendants and modifying each NFSv4 ACL encountered to remove any ACEs with the ACE4_INHERITED_ACE flag and to replace them by the new inheritable ACEs (also with the ACE4_INHERITED_ACE flag set). It uses the existing ACE inheritance flags in the obvious way to decide which ACEs to propagate. (Note that it may encounter further inheritable ACEs when descending the directory hierarchy and that those will also need to be taken into account when propagating inheritable ACEs to further descendants.)¶

The reach of this propagation may be limited in two ways: first, automatic inheritance is not performed from any directory ACL that has the ACL4_AUTO_INHERIT flag cleared; and second, automatic inheritance stops wherever an ACL with the ACL4_PROTECTED flag is set, preventing modification of that ACL and also (if the ACL is set on a directory) of the ACL on any of the object's descendants.¶

This propagation is performed independently for the sacl and the dacl attributes; thus, the ACL4_AUTO_INHERIT and ACL4_PROTECTED flags may be independently set for the sacl and the dacl, and propagation of one type of acl may continue down a hierarchy even where propagation of the other acl has stopped.¶

New objects are to be created with a dacl and a sacl that both have the ACL4_PROTECTED flag cleared and the ACL4_AUTO_INHERIT flag set to the same value as that on, respectively, the sacl or dacl of the parent object.¶

Both the dacl and sacl attributes are Recommended, and a server MAY support one without supporting the other.¶

A server that supports both the old acl attribute and one or both of the new dacl or sacl attributes MUST do so in such a way as to keep all three attributes consistent with each other. Thus, the ACEs reported in the acl attribute will be the union of the ACEs reported in the dacl and sacl attributes, except that the ACE4_INHERITED_ACE flag will be cleared from the ACEs in the acl. And of course a client that queries only the acl will be unable to determine the values of the sacl or dacl flag fields.¶

When a client performs a SETATTR for the acl attribute, the server SHOULD set the ACL4_PROTECTED flag to true on both the sacl and the dacl. By using the acl attribute, as opposed to the dacl or sacl attributes, the client signals that it may not understand automatic inheritance, and thus cannot be trusted to set an ACL for which automatic inheritance would make sense.¶

When a client application queries an NFSv4 ACL, modifies it, and sets it again, it needs to leave any ACEs marked with ACE4_INHERITED_ACE unchanged, in their original order, at the end of the NFSv4 ACL. If the application is unable to do this, it needs to set the ACL4_PROTECTED flag. This behavior is not enforced by servers, but violations of this rule may lead to unexpected results when applications perform automatic inheritance.¶

If a server also supports the mode attribute, it SHOULD set the mode in such a way that leaves inherited ACEs unchanged, in their original order, at the end of the ACL. If it is unable to do so, it SHOULD set the ACL4_PROTECTED flag on the file's dacl.¶

Finally, in the case where the request that creates a new file or directory does not also set permissions for that file or directory, and there are also no ACEs to inherit from the parent's directory, then the server's choice of ACL for the new object is implementation-dependent. In this case, the server SHOULD set the ACL4_DEFAULTED flag on the ACL it chooses for the new object. An application performing automatic inheritance takes the ACL4_DEFAULTED flag as a sign that the ACL is to be completely replaced by one generated using the automatic inheritance rules.¶

8.1. Attributes for User-based File Access Authorization

NFSv4.1 provides for multiple authentication models, controlled by the support for particular recommended attributes implemented by the server, as discussed below:¶

• Consensus Needed (Item #57e)]: The REQUIRED attributes owner, owning_group, and mode enable use of a POSIX-based authorization model, as described in Section 8.3. Since these attributes are always supported, this authorization model is aways available.¶

• [Consensus Needed (Item #17a)]: The acl attribute (or the attribute dacl in NFSv4.1) can provide an ACL-based authorization model as described in Section 8.4 as long as support for ALLOW and DENY ACEs is provided.¶

  [Consensus Needed (Items #17a)]: When some of these ACE types are not supported attribute, this authorization model is unavailable, since there are some modes that cannot be represented as a corresponding NFSv4 ACL, when using only a single ACE type. See Section 10.2 for details.¶

8.2. Handling of Multiple Parallel File Access Authorization Models

NFSv4 ACLs and modes represent two well-established models for specifying user-based file access permissions. NFSv4 provides support for either or both depending on the attributes supported by the server and, in cases in which both NFSv4 ACLs and the mode attribute are supported, the actual attributes set for a particular object.¶

• [Consensus Needed (item #18b)]: When the attributes mode, owner, owner group are all supported, the posix-based authorization model, described in Section 8.3 can be used.¶

• [Consensus Needed (Items #17b, #18b)]: When the acl (or dacl) attribute is supported together with both of the ACE types ALLOW and DENY, the acl based authorization model, described in Section 8.4 can be used as long as the attributes owner and owner_group are also supported.¶

[Consensus Needed (item #18b)]: While formally recommended (essentially OPTIONAL) attributes, it appears that the owner and owner_group attributes need to be available to support any file access authorization model. As a result, this document will not discuss the possibility of servers that do not support both of these attributes and clients have no need to support such servers.¶

When both authorization models can be used, there are difficulties that can arise because the ACL-based model provides finer-grained access control than the POSIX model. The ways of dealing with these difficulties appear later in this section while more detail on the appropriate handling of this situation, which might depend on the minor version used, appears in Section 10.¶

The following describe NFSv4's handling in supporting multiple authorization models for file access.¶

• If a server supports the mode attribute, it needs to provide the appropriate POSIX semantics if no ACL-based attributes have ever been assigned to object. These semantics include the restriction of the ability to modify the mode, owner and owner-group to the current owner of the file.¶

• If a server supports ACL attributes, it needs to provide NFSv4 ACL semantics as described in this document for all objects for which the ACL attributes have actually been set. This includes the ACL-based restrictions on the authorization to modify the mode, owner and owner_group attributes.¶

• On servers that support the mode attribute, if ACL attributes have never been set on an object, via inheritance or explicitly, the behavior is to be the behavior mandated by POSIX, including tthose provisions that restrict the setting of authorization-related attributes.¶

• On servers that support the mode attribute, if the ACL attributes have been previously set on an object, either explicitly or via inheritance:¶

  • [Previous Treatment]: Setting only the mode attribute should effectively control the traditional UNIX-like permissions of read, write, and execute on owner, owner_group, and other.¶

    [Author Aside]: It isn't really clear what the above paragraph means, especially as it governs the handling of aces designating specific users and groups which are not the owner and have no overlap with the owning group¶

    {Consensus Needed (Item #19a)]: Setting only the mode attribute, will result in the access of the file being controlled just it would be if the existing acl did not exist, with file access decisions as to read made in accordance with the mode set. The ALLOW and DENY aces in the ACL will reflect the modified security although there is no need to modify AUDIT and ALARM aces or mask bits not affected by the mode bits, such as SYNCHRONIZE.¶

    [Author Aside]: the above may need to modified to reflect the resolution of Consensus Item #??.¶

  • [Previous Treatment]: Setting only the mode attribute should provide reasonable security. For example, setting a mode of 000 should be enough to ensure that future OPEN operations for OPEN4_SHARE_ACCESS_READ or OPEN4_SHARE_ACCESS_WRITE by any principal fail, regardless of a previously existing or inherited ACL.¶

    [Author Aside]: We need to get rid of or provide some some replacement for the subjective first sentence. While the specific example give is unexceptionable, it raises questions in other cases as to what would constitutes "reasonable semantics". While the resolution of such questions would be subject to dispute, the author believes that consensus item #19a deals with the matter adequately. As a result he proposes, that the that this bullet be removed and that the second-level list be collapsed to a single paragraph.¶

• Although [RFC7530] and [RFC8881] present different descriptions of the specific semantic requirements relating to the interaction of mode and ACL attributes, the difference are quite small, with the most important ones deriving from the absence of the set_mode_masked attribute. The unified treatment in Section 10 will indicate where version-specific differences exist.¶

8.3. Posix Authorization Model

8.4. ACL-based Authorization Model

9.1. Handling of ACCESS and OPEN Operations

The primary means by which client-side users find out whether particular operations are authorized is to attempt those operations and have them executed successfully or rejected with an error. However, clients can use the ACCESS operation to determine in advance whether operations are permitted done without actually attempting those operations.¶

The use of the ACCESS operation is of particular importance when ACLs exist. This is due in part to the complexity of the ACLs but also derives from cases in which the client is incapable of determining whether a specific ACE applies to a particular request, as when some of the special who-field values are used in an ACE.¶

An additional difficulty precluding the client performing its own interpretation of an ACL concerns the existing specifications' lack of clear requirements for server support, making it difficult for the client to determine how a server might choose to behave in some cases. Even if this lack of specificity were remedied by clarifying the specification servers would still exist that reflected the previously valid scope of acceptable server behavior. As a result, it is impossible for the client to predict determine the choices a server might make without using ACCESS.¶

Similarly, the OPEN operation can determine acces rights in advance of actual access. There are two differences from ACCESS that clients need to be aware of, since they might require use of ACCESS in addition to OPEN or make the results of OPEN incompatible with the results of attempting IO operations.¶

• The permission model of OPEN is coarser-grained than that provided for by ACCESS or the ACE masks defined as part of the definition of NFSv4 ACLs.¶

  When reading files, the fact that OPEN treats requests to open a file to read it and to execute it together means that the client will need to do an ACCESS operation to determine whether particular reads are to be allowed.¶

  When writing files, the fact OPEN that does not distinguish between WRITEs which extend the file and those that modify bytes already written means that the client will need to get the permission information using ACCESS or be prepared to have some set of WRITES on a file open for Write rejected as unauthorized.¶

• [Consensus needed, Entire Bulleted Item (Item #23a)]: Just as with ACCESS, the granting of permission does not foreclose subsequent permission changes, there are good reasons for servers to provide ways of allowing IO allowed at OPEN time to continue even in the face of permission changes that would normally be expected to make the IO operation invalid. These reasons derive from the fact that local operations work this way and that it is is often necessary for requests over NFSv4 to behave just as they would if done locally. As a result, it is desirable for servers to provide this expected behavior in some way since application programs have come to depend on it.¶

  One way of handling this situation is described in Section 9.2. It deals with the most common of these situations in which the owner of the is both writing a file and seeking to make it subsequently unwritable, and while it does not deal with all such situations, it has proven satisfactory for many NFS protocols over a long time period¶

  Another way of dealing with this situation involves the server explicitly using the stateid to reference a particular open made by a user, and avoiding reverification of access for READs and WRITEs made by that user since that verification was made at OPEN time. To do this safely, the server needs to have authenticated principals and client peers and, in order to prevent man-in-middle attacks, it s necessary for all connections on which stateids are sent to provide encryption.¶

This approach allows clients, for many purposes, to operate without reliable knowledge of ACl-based authorization semantic. However, as noted in Section 1.1, there are other aspects of client-server interaction which require more client knowledge for effective interoperability, as described, for example, in Section 17.2.¶

9.2. Server Considerations

The server uses the mode attribute or the acl attribute applying the algorithm described in Section 8.4.1 to determine whether an ACL allows access to an object.¶

[Author Aside, Including List]: The list previously in this section (now described as "Previous Treatment" combines two related issues in a way which obscures the very different security-related consequences of two distinct issues:¶

• In some cases an operation will be authorized but is not allowed for reasons unrelated to authorization.¶

  This has no negative effect on security.¶

• The converse case can have troubling effects on security which are mentioned in this section and discussed in more detail in Section 18¶

[Author Aside, Including List]: The items in that list have been dealt with as follows:¶

• The first and sixth items fit under the first (i.e. less troublesome) of these issues. They have have been transferred into an appropriate replacement list.¶

• The third item is to be deleted since it does not manifest either of these issues. In fact, it refers to the semantics already described in Section 6.5.¶

• The second, fourth and fifth items need to be addressed in a new list dealing with the potentially troublesome issues arising from occasions in which the access semantics previously described are relaxed, for various reasons.¶

  Included are cases in which previous specifications explicitly allowed this by using the term "MAY" and others in which the existence of servers manifesting such behavior was reported, with the implication that clients need to be prepared for such behavior.¶

[Previous Treatment, Including List (Items #22a, #41a, #52b)]: However, these attributes might not be the sole determiner of access. For example:¶

• In the case of a file system exported as read-only, the server will deny write access even though an object's file access attributes would grant it.¶
• Server implementations MAY grant ACE4_WRITE_ACL and ACE4_READ_ACL permissions to prevent a situation from arising in which there is no valid way to ever modify the ACL.¶
• All servers will allow a user the ability to read the data of the file when only the execute permission is granted (e.g., if the ACL denies the user the ACE4_READ_DATA access and allows the user ACE4_EXECUTE, the server will allow the user to read the data of the file).¶
• Many servers implement "owner-override semantics" in which the owner of the object is allowed to perform accesses that are denied by the ACL or mode bits This may be helpful, for example, to allow users continued access to open files on which the permissions have changed.¶
• Many servers provide for the existence of a "superuser" that has privileges beyond an ordinary user. The superuser may be able to read or write data or metadata in ways that would not be permitted by the ACL or mode attributes.¶
• A retention attribute might also block access otherwise allowed by ACLs (see Section 5.13 of [RFC8881]).¶

[Consensus Needed, Including List (Item #22a)]: It needs to be noted that, even when an operation is authorized, it may be denied for reasons unrelated to authorization. For example:¶

• In the case of a file system exported as read-only, the server will deny write access even though an object's file access attributes would authorize it.¶
• A retention attribute might also block access otherwise allowed by ACLs (see Section 5.13 of [RFC8881]).¶

[Author aside, including List, (Item #22a)]: Unlike other cases in which previous specs have granted permission to the server to expand allowed behavior, in the case of "owner-override semantics", the need for supercession does not arise from security issues but instead derives from:¶

• The unacceptable implication in the superseded text that the fact that a server chooses to do something, means that the client needs to accept that behavior.¶

• The lack of any definition of the term "owner-override semantics. Subsequent investigation has led to the conclusion that the semantics being referred to derive from the following material in [RFC1813]:¶

  • Another problem arises due to the usually stateful open operation. Most operating systems check permission at open time, and then check that the file is open on each read and write request. With stateless servers, the server cannot detect that the file is open and must do permission checking on each read and write call. UNIX client semantics of access permission checking on open can be provided with the ACCESS procedure call in this revision, which allows a client to explicitly check access permissions without resorting to trying the operation. On a local file system, a user can open a file and then change the permissions so that no one is allowed to touch it, but will still be able to write to the file because it is open. On a remote file system, by contrast, the write would fail. To get around this problem, the server's permission checking algorithm should allow the owner of a file to access it regardless of the permission setting. This is needed in a practical NFS version 3 protocol server implementation, but it does depart from correct local file system semantics. This should not affect the return result of access permissions as returned by the ACCESS¶

  As a result, it appears that NFSv4 servers have implemented semantics different from that provided for by POSIX that were defined in order to deal with lack of an open operation in NFsv3 in the context of NFSv4, which does have an open operation.¶

• The need to make it clear that an alternate approach to the issue of permission change after open is to allow the OPEN's permission check to be dispositive as long as the appropriate security infrastructure is in place to allow client stateids to be trusted.¶

[Consensus Needed, (Item #22a)]: There are also cases in which the converse issue arises, so that an operation which is not authorized as specified by the mode and ACL attributes is, nevertheless, executed as if it were authorized. Because previous NFSv4 specifications have cited the cases listed below without reference to the security problems that they create, it is necessary to discuss them here to provide clarification of the security implications of following this guidance, which might now be superseded. These cases are listed below and discussed in more detail in Section 18.1.3.¶

[Consensus Needed, Including List (Item #22a, #41a, #52b)]: In the following list, the treatment used in [RFC8881] is quoted, while the corresponding text in [RFC7530] is essentially identical.¶

• [RFC8881] contains the following, which is now superseded:¶

  • Server implementations MAY grant ACE4_WRITE_ACL and ACE4_READ_ACL permissions to prevent a situation from arising in which there is no valid way to ever modify the ACL.¶

  While, as a practical matter, there do need to be provisions to deal with this issue, the "MAY" above is too broad,in that it describes the motivation without any limits providing appropriate restriction on the steps that might be taken to deal with the issue. See Section 18.1.3 for the updated treatment of this issue.¶

• [RFC8881] contains the following, which is now superseded:¶

  • Many servers implement owner-override semantics in which the owner of the object is allowed to override accesses that are denied by the ACL. This may be helpful, for example, to allow users continued access to open files on which the permissions have changed.¶

  The principal problem with the above statement is the lack of a clear definition of the term "owner-override semantics". Also, it needs to be made clear that the fact that a server manifests a particular behavior does not imply that it is valid according to the protocol specification.¶

  In this case, investigation has led to the conclusion that the semantics being referred to derive from the discussion of NFSv3 semantics appearing Section 4.4 of [RFC1813] and that this handling has been implemented in a number of NFSv4 servers, despite the fact that NFSv4, unlike NFSv3, does have an open operation.¶

  With regard to the second sentence of the quotation above, it is not clear whether it is helpful or hurtful to allow continued access to open files which have become inaccessible due to changes in security and it is not clear that the working group will make a decision on the matter in this document, despite the obvious security implications. In any case, the resolution is unlikely to depend on whether the owner is involved.¶

  Since this divergence from POSIX semantics is unlikely to result in security issues, we can clarify the above by saying that a server MAY diverge from POSIX semantics by always allowing READ or WRITE to be done by the file owner but that this divergence MUST NOT affect the handling of OPEN and ACCESS. It also needs to be noted that servers could address the issue of preventing permission change affecting that handling of READs and WRITEs of open files as described in Section 9.1.¶

• [RFC8881] contains the following, which is now superseded:¶

  • Many servers have the notion of a "superuser" that has privileges beyond an ordinary user. The superuser may be able to read or write data or metadata in ways that would not be permitted by the ACL or mode attributes.¶

  While many (or almost all) systems in which NFSv4 servers are embedded, have provisions for such privileged access to be provided, it does not follow that NFSv4 servers, as such, need to have provision for such access.¶

  Providing such access as part of the NFSv4 protocols, would necessitate a major revision of the semantics of ACL including such troublesome matters as the proper handling of AUDIT and ALARM ACEs in the face of such privileged access.¶

  Because of the effect such unrestricted access might have in facilitating and perpetuating attacks, Section 18.1.3 will the new approach to this issue, while Section 18.4.1, will explain how such access is addressed in the threat analysis.¶

9.3. Client Considerations

[Previous Treatment]: Clients SHOULD NOT do their own access checks based on their interpretation of the ACL, but rather use the OPEN and ACCESS operations to do access checks. This allows the client to act on the results of having the server determine whether or not access is to be granted based on its interpretation of the ACL.¶

[Author Aside]: With regard to the use of "SHOULD NOT" in the paragraph above, it is not clear what might be valid reasons to bypass this recommendation. Perhaps "MUST NOT" or "are not advised to" would be more appropriate.¶

[Consensus Needed (Item #23b)]: Clients are not expected to do their own access checks based on their interpretation of the ACL, but instead use the OPEN and ACCESS operations to do access checks, where this is possible. This allows the client to act on the results of having the server determine whether or not access is to be granted based on its interpretation of the ACL, rather then the client's which might be different. For a full discussion of limitations on the use of ACCESS and appropriate client approaches to deal these limitations, see Section 9.1.¶

[Previous Treatment]: Clients must be aware of situations in which an object's ACL will define a certain access even though the server will not enforce it. In general, but especially in these situations, the client needs to do its part in the enforcement of access as defined by the ACL.¶

[Author Aside]: Despite what is said later, the only such case I know of is the use of READ and EXECUTE where the client, but not the server, has any means of distinguishing these. I don't know of any others. If there were, how could ACCESS or OPEN be used to verify access?¶

[Consensus Needed (Item #23b)]; Clients need to be aware of situations in which an object's ACL will define a certain access even though the server is not in position to enforce it because the server does not have the relevant information, such as knowing whether a READ is for the purpose of executing a file. Because of such situations, the client needs to do be prepared to do its part in the enforcement of access as defined by the ACL.¶

To do this, the client will send the appropriate ACCESS operation prior to servicing the request of the user or application in order to determine whether the user or application is to be granted the access requested.¶

[Previous Treatment (Item #24a)]: For examples in which the ACL may define accesses that the server doesn't enforce, see Section 9.2.¶

[Author Aside]: The sentence above is clearly wrong since that section is about enforcement the server does do. The expectation is that it will be deleted as part of Consensus Item #24a.¶

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 co-ordinated. Despite the fact that these discussions are different, they are compatible and differ in only a small number of areas relating to the existence absence of the set-mode-masked attribute.¶

Such co-ordination is necessary is necessary since it is expected that servers providing both sets of attributes will encounter users who have no or very limited knowledge of one and need to work effectively when other users changes that attribute. As a result, these attributes cannot each be applied independently since that would create an untenable situation in which some users who have the right to control file access would find themselves unable to do so.¶

[Author Aside]: From this point on, all paragraphs in this section, not other annotated are to be considered part of Consensus Item #25b. 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.12. In addition, an NFSv4.2-based extension related to attribute co-ordination will be described in Section 10.13.¶

The current NFSv4.0 and NFSv4.1 descriptions of this co-ordination share an unfortunate characteristic in that they are both written to give server implementations a broad latitude in implementation choices while neglecting entirely the need for clients and users to have a reliable description of what servers are to do in this area.¶

As a result, one of the goals of this new combined treatment will be to limit the uncertainty that the previous approach created for clients, while still taking proper account of the possibility of compatibility issues that a more tightly drawn specification might give rise to.¶

The various ways in which these kinds of issues have been dealt with are listed below together with a description of the needed changes proposed to address each issue.¶

• In some cases, the term "MAY" is used in contexts where it is inappropriate, since the allowed variation has the potential to cause harm in that it leaves the client unsure exactly what security-related action will be performed by the server.¶

  The new treatment will limit use use of MAY to cases in which it is truly necessary, in order to give clients proper notice of cases in which server behavior cannot be determined and limit the work necessary to deal with a large array of possible behaviors.¶

• There are also cases in which no RFC2119-defined keywords are used but it is stated that certain server implementations do a particular thing, leaving the impression that that action is to be allowed, just as if "MAY" had been used.¶

  If the flexibility is necessary, MAY will be used. In other cases, SHOULD will be used with the understanding that maintaining compatibility with clients that have adapted to a particular approach to this issue is a valid reason to bypass the recommendation. However, in no case will it be implied, as it is in the current specifications, that the server MAY do whatever it chooses, with the client having no option but to adapt to that choice.¶

• There was a case, in 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 referred to in this document as "UNIX ACLs", ass described in Section 4.1. A discussion of the issues for support of for these ACLs appears in Section 10.5.¶

  [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 the interpretation of these term in the previous paragraph applies there will be an explicit reference to Consensus Item #25, to draw attention to this change, even in the absence of modified text.¶

10.2. Needed Attribute Coordination

On servers that support both the mode and the acl or dacl attributes, the server needs to keep the two consistent with each other. 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) are to be determined entirely by the value of the ACL, so that use of the mode is never required by ACL-aware clients for anything other than setting and interrogating the three high-order bits. See Sections 10.7 through 10.9 for detailed discussion.¶

[Previous Treatment (Item #25c)]: When a mode attribute is set on an object, the ACL attributes may need to be modified in order to not conflict with the new mode. In such cases, it is desirable that the ACL keep as much information as possible. This includes information about inheritance, AUDIT and ALARM ACEs, and permissions granted and denied that do not conflict with the new mode.¶

[Author Aside]: one the things that this formulation leaves uncertain, is whether, if the ACL specifies permission for a named user group or group, it "conflicts" with the node. Ordinarily, one might think it does not, unless the specified user is the owner of the file or a member of the owning group, or the specified group is the owning group. However, while some parts of the existing treatment seem to agree with this, other parts, while unclear, seem to suggest otherwise, while the treatment in Section 10.7 is directly in conflict.¶

[Previous Treatment (Item #26a)]: The server that supports both mode and ACL must take care to synchronize the MODE4_*USR, MODE4_*GRP, and MODE4_*OTH bits with the ACEs that have respective who fields of "OWNER@", "GROUP@", and "EVERYONE@".¶

[Author Aside]: This sentence ignores named owners and group, giving the impressions that there is no need to change them.¶

[Previous Treatment (Item #26a)]: This way, the client can see if semantically equivalent access permissions exist whether the client asks for the owner, owner_group, and mode attributes or for just the ACL.¶

[Author Aside, Including List:] The above sentence, while hard to interpret for a number a reasons, is worth looking at in detail because it might suggest an approach different from the one in the previous sentence from the initial paragraph for The Previous Treatment of Item #26a.¶

• The introductory phrase "this way" adds confusion because it suggests that there are other valid ways of doing this, while not giving any hint about what these might be.¶

• It is hard to understand the intention of "client can see if semantically equivalent access permissions" especially as the client is told elsewhere that he is not to interpret the ACL himself.¶

• If this sentence is to have any effect at all it, it would be to suggest that the result be the same "whether the client asks for the owner, owner_group, and mode attributes or for just the ACL."¶

  If these are to be semantically equivalent it would be necessary to delete ACEs for named users, which requires a different approach form the first sentence of the original paragraph.¶

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

• When the mode is changed, in most cases, the ACL attributes will need to be modified as described in Section 10.7.¶

• When the ACL is changed, the corresponding mode is determined and used to set the nine low-oder bits of the mode attribute.¶

  This is relatively straightforward in the case of forward-slope modes, but the case of reverse-slope modes needs to be addressed as well. It is RECOMMENDED that the procedure presented in Section 10.3 be used or another one that provides the same results.¶

  The valid reasons to bypass this recommendation together with a alternate procedures to be used are discussed in Section 10.4.¶

{Consensus Needed (Item #26a)]: How other ACEs are dealt with when setting mode is described in Section 10.7. 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.3. 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.4. This is intentional, to avoid invalidating existing implementations that compute the mode according to the withdrawn POSIX ACL draft (1003.1e draft 17), rather than by actual permissions on owner, group, and other.¶

[Consensus (Item #27a)]: In performing the co-ordinarion discussed in this section, the method used to compute the mode from the ACL has an important role. While the approach specified in Section 10.3 is RECOMMENDED, it needs to be noted that the alternate approaches discussed in Section 10.4 are valid in some cases. As discussed in that section, an important reason for allowing multiple ways of doing this is to accommodate server implementations that compute the mode according to the withdrawn POSIX ACL draft (1003.1e draft 17), rather than by actual permissions on owner, group, and other. While, this means that a client, having no way of determining the method the server uses may face interoperability difficulties in moving between servers which approach this matter differently, these problems need to be accepted for the time being. A more complete discussion of handling of the UNIX ACLs is to be found in Section 10.5.¶

[Consensus Needed, Including List (Items #27a, #28a)]: All valid methods of computing the mode from an ACL use the following procedure to derive a set of mode bits from a set of three ACL masks, with the only difference being in how the set of ACL masks is constructed. The calculated mask for for each set of bits in mode are derived from the ACL mask for owner, group, other are derived as follows:¶

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

10.3. Computing a Mode Attribute from an ACL

[Previous Treatment (Item #27b)]: The following method can be used to calculate the MODE4_R*, MODE4_W*, and MODE4_X* bits of a mode attribute, based upon an ACL.¶

[Author Aside]: "can be used" says essentially "do whatever you choose" and would make Section 10 essentially pointless. Would prefer "is to be used" or "MUST", with "SHOULD" available if valid reasons to do otherwise can be found.¶

[Consensus Needed (Items #27b, #28b, #61g)}: 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, based upon an ACL when that ACL is one providing NFSv4 semantics. In this case, one of the valid reasons to bypass the recommendation includes implementor reliance on previous specifications which ignored the cases of the owner having less access than the owning group or the owning group having less access than others. Further, in implementing or the maintaining an implementation previously believed to be valid, the implementor needs to be aware that this will result in invalid values in some uncommon cases. Other reasons to bypass the recommendation are discussed in Section 10.4, along with the case of ACLs providing UNIX ACL semantics.¶

[Author Aside, Including List]: The algorithm specified below, now considered the Previous Treatment associated with Item #24a, has an important flaw in does not deal with the (admittedly uncommon) case in which the owner_group has less access than the owner or others have less access than the owner-group. In essence, this algorithm ignores the following facts:¶

• That GROUP@ includes the owning user while group bits in the mode do not affect the owning user.¶

• That EVERYONE includes the owning group while other bits in the mode do not affect users within the owning group.¶

[Previous Treatment (Item #28b)]: First, for each of the special identifiers OWNER@, GROUP@, and EVERYONE@, evaluate the ACL in order, considering only ALLOW and DENY ACEs for the identifier EVERYONE@ and for the identifier under consideration. The result of the evaluation will be an NFSv4 ACL mask showing exactly which bits are permitted to that identifier.¶

[Previous Treatment (Item #28b)]: Then translate the calculated mask for OWNER@, GROUP@, and EVERYONE@ into mode bits for, respectively, the user, group, and other, as follows:¶

[Consensus Needed, including List(Item #28b)]: First, for each of the sets of mode bits (i.e., user, group other, evaluate the ACL in order, with a specific evaluation procedure depending on the specific set of mode bits being determined. For each set there will be one or more special identifiers considered in a positive sense so that ALLOW and DENY ACE's are considered in arriving at the mode bit. In addition, for some sets of bits, there will be one or more special identifiers to be considered only in a negative sense, so that only DENY ACE's are considered in arriving at the mode it. The users to be considered are as follows:¶

• For the owner bits, "OWNER@" and "EVERYONE@" are to be considered, both in a positive sense.¶

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

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

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

10.4. Alternatives in Computing Mode Bits

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

Some server implementations also add bits permitted to named users and groups to the group bits (MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP).¶

Implementations are discouraged from doing this, because it has been found to cause confusion for users who see members of a file's group denied access that the mode bits appear to allow. (The presence of DENY ACEs may also lead to such behavior, but DENY ACEs are expected to be more rarely used.)¶

[Author Aside]: The text does not seem to really discourage this practice and makes no reference to the need to standardize behavior so the clients know what to expect or any other reason for providing standardization of server behavior.¶

The same user confusion seen when fetching the mode also results if setting the mode does not effectively control permissions for the owner, group, and other users; this motivates some of the requirements that follow.¶

[Author Aside]: The part before the semicolon appears to be relevant to Consensus Item #23 but does not point us to a clear conclusion. The statement certainly suggests that the 512-ACL approach is more desirable but the absence of a more direct statement to that effect suggest that this is a server implementer choice.¶

[Author Aside]: The part after the semicolon is hard to interpret in that it is not clear what "this" refers to or which which requirements are referred to by "some of the requirements that follow". The author would appreciate hearing from anyone who has insight about what might have been intended here.¶

[Consensus Needed, Including List (Item #27c, #61h)]: In cases in which the mode is not computed as described in Section 10.3, one of the following analogous procedures or their equivalents, MUST be used. This includes cases in which the ACL in question is one providing UNIX ACL semantics.¶

• First, for each of the special identifiers OWNER@ and EVERYONE@, evaluate the ACL in order, considering only ALLOW and DENY ACEs for the identifier EVERYONE@ and for the identifier under consideration.¶

  For the special identifier GROUP@, ALLOW and DENY ACEs for GROUP@ and EVERYONE@ are to be considered, together with ALLOW ACEs for named users and groups.¶

  This represents the approach previously recommended to compute mode in previous specification, as modified to reflect the UNIX ACL practice of reflecting permissions for named users and groups. It does not deal properly with reverse-slope modes.¶

• Compute a set of ACL mask according to the procedure in Section 10.3 and then, for the mask associated with GROUP@, or in the masks for all ALLOW ACEs for named users and groups.¶

  This represents the approach currently recommended to compute mode in Section 10.3 as modified to reflect the UNIX ACL practice of reflecting permissions for named users and groups.¶

[Consensus Needed, Including List (Item #27c)]: In both cases, The results of the evaluation will be a set of NFSv4 ACL masks which can be converted to the set on nine low-order mode bits using the procedure appearing in Section 10.2 above.¶

[Consensus Needed, Including List (Item #27c)]: When the recommendation to use Section 10.3 is bypassed, it needs to be understood, that the modes derived will differ from the expected values and might cause interoperability issues. This is particularly the case when clients have no way to determine that the server's behavior is other than standard.¶

10.5. Handling of UNIX ACLs

[Author Aside]: All paragraphs in this section are consider part of Consensus Item #56b.¶

Although the working group did not adopt the acls in the withdrawn POSIX draft, their continued existence in UNIX contexts has created protocol difficulties that need to be resolved. In many cases these ACLS and their associated semantics are the basis for ACL support in UNIX client APIs and in UNIX file systems supported by NFSv4¶

Although the semantic range of UNIX ACLs is a subset of that for NFSv4 ACLs, expecting clients to perform that mapping on their own has not worked well, leading to the following issues which will, at some point, need to be addressed:¶

• There is a considerable uncertainty about the proper mapping from ACLs to modes.¶

• The corresponding mapping from modes to ACLs is dealt with different ways by different sections of the spec.¶

• These individual uncertainties are compounded since it is difficult, in this environment, to ensure that these independently chosen mappings are inverses of one another, as they are intended to be.¶

Some possible approaches to these issues are discussed in Section 17.2,¶

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 #25d.¶

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 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 #25e.¶

Some server implementations may provide for the existence of "objects without ACLs", meaning that all permissions are granted and denied according to the mode attribute and that no ACL attribute is stored for that object. If an ACL attribute is requested of such a server, the server SHOULD return an ACL that does not conflict with the mode; that is to say, the ACL returned SHOULD represent the nine low-order bits of the mode attribute (MODE4_R*, MODE4_W*, MODE4_X*) as described in Section 10.3.¶

For other server implementations, the ACL attribute is always present for every object. Such servers SHOULD store at least the three high-order bits of the mode attribute (MODE4_SUID, MODE4_SGID, MODE4_SVTX). The server SHOULD return a mode attribute if one is requested, and the low-order nine bits of the mode (MODE4_R*, MODE4_W*, MODE4_X*) MUST match the result of applying the method in Section 10.3 to the ACL attribute.¶

10.11. Creating New Objects

[Author Aside]: The handling of SHOULD in this section is considered as part of Consensus Item #25f.¶

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, if supported, 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.12. Use of Inherited ACL When Creating Objects

[Author Aside]: The handling of SHOULD in this section is considered as part of Consensus Item #25g.¶

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

14.1. Identification vs. Authentication

It is necessary to be clear about this distinction which has been obscured in the past, by the use of the term "RPC Authentication Flavor" in connection with situation in which identification without authentication occurred or in which there was neither identification nor authentication involved. As a result, we will use the term "Auth Flavors" instead¶

14.2. Items to be Identified

Some identifier are not security-relevant and can used be used without authentication, given that, in the authorization decision, the object acted upon needs only to be properly identified¶

• File names are of this type.¶

  Unlike the case for some other protocols, confusion of names that result from internationalization issues, while an annoyance, are not relevant to security. If the confusion between LATIN CAPITAL LETTER O and CYRILLIC CAPITAL LETTER O, results in the wrong file being accessed, the mechanisms described in Section 8 prevent inappropriate access being granted.¶

  Despite the above, it is desirable if file names together with similar are not transferred in the clear as the information exposed may give attackers useful information helpful in planning and executing attacks.¶

• The case of file handles is similar.¶

Identifiers that refer to state shared between client and server can be the basis of disruption attacks since clients and server necessarily assume that neither side will change the state corpus without appropriate notice.¶

While these identifiers do not need to be authenticated, they are associated with higher-level entities for which change of the state represented by those entities is subject to peer authentication.¶

• Unexpected closure of stateids or changes in state sequence values can disrupt client access as no clients have provision to deal with this source of interference.¶

  While encryption may make it more difficult to execute such attacks attackers can often guess stateid's since server generally not randomize them.¶

• Similarly, modification to NFSv4.1 session state information can result in confusion if an attacker changes the slot sequence by assuring spurious requests. Even if the request is rejected, the slot sequence is changed and clients may a difficult time getting back in sync with the server.¶

  While encryption may make it more difficult to execute such attacks attackers can often guess slot id's and obtain sessinid's since server generally do not randomize them.¶

• ¶

it is necessary that modification of the higher-levell entities be restricted to the client that created them.¶

• For NFSv4.0, the relevant entity is the clientid.¶

• for NFSv4.1, the relevant entity is the sessionid.¶

Identifiers describing the issuer of the request, whether in numeric or string form always require authentication.¶

14.3. Authentication Provided by specific RPC Auth Flavors

Different auth flavors differ quite considerably, as discussed below;¶

• When AUTH_NONE is used, the user making the request is neither authenticated nor identified to the server.¶

  Also, the server is not authenticated to the client and has no way to determine whether the server it is communicating with is an imposter.¶

• When AUTH_SYS is used, the user making is the request identified but there no authentication of that identification.¶

  As in the previous case, the server is not authenticated to the client and has no way to determine whether the server it is communicating with is an imposter.¶

• When RPCSEC_GSS is used, the user making the request is authenticated as is the server peer responding.¶

14.4. Authentication Provided by other RPC Security Services

Depending on the connection type used, RPC may provide additional means of authentication. In contrast with the case of RPC auth flavors, any authentication happens once, at connection establishment, rather than on each RPC request. As a result, it is the client and server peers, rather than individual users that are authenticated.¶

• For many types of connections such as those created TCP without RPC-with-TLS and RPC-over-RDMA version 1, there is no provision for peer authentication.¶

  As a result use of AUTH_SYS using such connections is inherently problematic.¶

• Some connection types provide for the possibility of mutual peer authentication. These currently include only those established by RPC-with-TLS. However, given the value of peer authentication, there is reason to believe further means of providing such services will be defined.¶

15.1. Data Security Provided by Services Associated with Auth Flavors

The only auth flavor providing these facilities is RPCSEC_GSS. When this auth flavor is used, data security can be negotiated between client and server as described in Section 16. However, when data security is provided for the connection level, as described in Section 15.2, the negotiation of privacy and integrity support, provided by the auth flavor, is unnecessary,¶

Other auth flavors, such as AUTH_SYS and AUTH_NONE have no such data security facilities. When these auth flavors are used, the only data security is provided on a per-connection basis.¶

15.2. Data Security Provided for a Connection by RPC

RPC, in many case, provide data security for all transactions performed on a connection, eliminating the need for that security to be provided or negotiated by the selection of particular auth flavors, mechanisms, or auth-flavor-associated services.¶

16.1. Dealing with Multiple Connections

[Author Aside]: All unannotated paragraphs in this section are considered part of Consensus Item #32b.¶

Because effective security will require both an appropriate auth flavor (and possibly services provide by the auth flavor) together with appropriate connection characteristics, it is often necessary that clients and server be aware of connection characteristics:¶

• When multiple connections with different security-related characteristics, are used to access a server, the clients needs to ensure that each request is issued on an appropriate connection.¶

• Similarly, in such situations, the server needs to be aware of the security-related characteristics for the connection on which each request is received, in order to enforce its security policy.¶

Depending on how the client and server implementations are structured, implementations may have to be changed to accomplish the above.¶

In the case of NFSv4.1 and above, the protocol requires that requests associated with a given session only be issued on connections bound to that session and accepted by the server only when that binding is present. This makes it likely that clients or servers will be able to correctly associate requests with the appropriate connections although additional work might be necessary to enable them to determine, for any given connection, its security characteristics.¶

In the case of NFSv4.0, no such binding is present in the protocol so that, depending on existing implementations' layering, channel binding functionality might have to be added.¶

17.1. Desirable Additional Security Facilities

[Author Aside]: All unannotated paragraphs in this section are to be considered part of Consensus Item #35a.¶

[Author Aside]: This section is basically an outline for now, to be filled out later based on Working Group input, particularly from Chuck Lever who suggested this section and has ideas about many of the items in it.¶

• Security for data-at-rest, most probably based on facilities defined within SAN.¶

• Support for content signing.¶

• Revision/extension of labelled NFS to provide true interoperability and server-based authorization.¶

• Work to provide more security for RDMA-based transports. This would include the peer authentication infrastructure now being developed as part of RPC-over-RDMA version 2. In addition, there is a need for an RDMA-based transport that provides for encryption, which might be provided in number of ways.¶

17.2. Extensions to deal with Authorization-related Server Behavioral Differences

[Author Aside]: All unannotated paragraphs in this section are to be considered part of Consensus Item #56c.¶

This section discusses possible new attributes or related extensions to help deal with the issues described in Section 3.4. As discussed in Section 1.3.2, there are a large set optional behaviors allowed to the server with no means for the client to determine the option chosen by the server. While it is possible that this set of options will be cut back if it is found that no servers use them, there will need to be attributes defined for each case in which the eventual RFC continues to allow muiltple server behaviors.¶

It is possible that a low-level approach would be used if the working group is unable to organize the existing behavioral options into optional features meaningful to the client. This approach would provide a large set of related fs-scoped attributes such as the following:¶

• A new attribute would contain an element for each optional ACE mask bit. The element would indicate whether the mask bit is supported, and, if it is not, how the authorizations normally controlled by that mask bit are determined (e.g. file ownership, a different mask bit).¶

  In cases such as ACE4_APPEND_DATA, where it might not be clear exactly which WRITEs fit under the category of appending operations, there need to be an indication of how this decision is to be made, given uncertainty regarding WRITEs beyond EOF and whether there are WRITEs understood as both appending and modifying existing data.¶

  Although, according to current specifications, all such mask bits are optional, but it is likely that the three masks bits, corresponding to the three masks bits in the mode (read, write, search/execute) can be made mandatory.¶

• A new attribute could contain a mask of ACE flags supported.¶

• In each case in which "SHOULD" is used in current specifications with an interoperability effect similar to the one implied by use of "MAY", there needs to be one bit within the attribute to allow the client to determine when the formally disfavored behavior is provided by the server.¶

  This would be the case even if the working group were to decide that the granting of this flexibility had been a mistake. As long as the server is allowed the variant behavior, there needs to be a way to provide notice to the client, even if is the case that the only valid reasons to bypass the recommendation is to allow time to adjust clients and severs to the necessary change.¶

• Given that it is allowed for servers to choose different algorithms to arrive at a mode corresponding to an ACL, there needs to be an attribute to enable the client to find out which algorithm is used.¶

• The changes that need to be made to ACLs when the mode is set are a further source of server behavioral variation, that an fs-scoped attribute could address While existing specifications indicate that is acceptable to simply drop the ACL and make subsequent authorization decisions solely on the basis of the mode, there are many statements (non-normative) that various aspects of this are undesirable, suggesting that various sorts of alternative behavior are allowed.¶

  One issue concerns the handling of ACEs for named users and groups and for special who values. It is certainly allowed, as stated above, to simply¶

  Regarding AUDIT and ALARM ACEs, the following, appearing in Section 10.7.1 seems to disallow simply dropping the ACL.¶

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

  Even if the working group could clarify this issue, the current specifications could have given rise to existing conflicting implementations requiring one bit (or one bit for each ACE type) indicate whether such ACEs are maintained or dropped.¶

  For mask bits outside the three mode bits (read, write, share/execute), such ACEs can be deleted or not (Dropping the ACL would get rid of them, while Section 10.7.1 says such ALLOW ACEs "MAY be deleted. The corresponding case of DENY ACEs is not discussed. In any case, these behavioral variants need to be addressed¶

  There are also a number of possible variant behaviors related to ACL inheritance. Existing specifications indicate it is "desirable" to leave inherit-only ACEs in place but leaves this as a server choice. The parallel case of converting inheritable ACEs to inherit-only ACEs is not mentioned but this is probably an oversight. In any case, at least two attribute bits are required to specify the handling of inheritance in the event of a SETATTR of mode.¶

This set of attribute values would provide the client an indication of where the server might avail itself of the flexibility currently provided for in the specification of authorization semantics. A principal use would be to allow clients to determine whether it possible to construct an ACL to authorize any particular set of activities according to the NFSv4 ACL model, and if it is, how that ACL is to be constructed. This could provide a necessary complement to the use of ACCESS, which avoids the need for the client to interpret ACLs to determine authorization, which the looseness of the current specifications make impossible.¶

It is possible that the working group might choose, to organize a set of more structured attribute choices reflect the underlying conflict between the NFSv4 ACL model (windows-oriented) and the subset more attuned to the Unix ACL Model. If there are servers who provide extensions to the Unix model that are compatible with the NFSv4 model, they can be defined as optional extensions to the Unix model.¶

This reorganization, which the working group might be able to do in the corresponding RFC would provide interoperability for clients using and servers providing support for Unix ACLs. It would also provide interoperability for clients using the full power of NFSv4 ACLs and servers providing the corresponding server-side implementation. Interoperability between these two classes would be hit-or-miss, as it is now.¶

As most servers capable of supporting the full NFSv4 ACL model, could provide the subset necessary to support clients that expect Unix ACL support, the working group will need to provide means of allowing the support level to be negotiated. Two possibilities are:¶

• Defining a new attribute unix_acl whose definition is a Unix-oriented subset of sacl.¶

• Allowing the choice of Unix or Nfsv4 ACLs as part of the EXCHANGE_ID (adding new flags) or using a new op devoted to security related negotiation.¶

It turns out that multiple elements are probably required. While providing two separate attributes for each of the two ACL semantic models provides for client choice, allowing two read-write attributes results in considerable additional complexity. Allowing negotiated restrictions on the values to be set using a single writable ACL attribute accomplishes the main goal but there are problems in that unix-oriented clients will encounter non-unix ACLs stored by others. For the most part, clients will not access these values, relying on ACCESS. However, there is a need to use such non-Unix ACLs when copying files. As result, we might have the following set of extensions:¶

• Providing for client-negotiated semantic restrictions on values accepted by and returned by the sacl and dacl attributes. To enable unix-oriented clients their normal ACL semantic model, sacl could be restricted to the equivalent of Unix ACLs, with dacl only accepting and returning empty sets of ACE's.¶

• Providing, in addition, new full_sacl and full_dacl attributes, not subject to the restrictions above. The server, in setting such attributes would not be bound to respect them full (e.g. no append-only files) but would make these unsupported features available for use by servers that do not support them, in the fashion that is done now in the case of ACE4_SYNCHRONIZE.¶

There are also a set of behavioral differences that derive from modifications to authorization semantics. These special semantics, which now apply to use of both ACLs and modes, were originally necessary in NFSv2 and NFSv3 to deal with the need to emulate local file semantics using stateless protocols. These semantics were carried over into NFSv4 as allowed behaviors even though they were no longer necessary and can interfere with correct authorization semantics when non-writeable files need to be supported.¶

An attribute could be provided to allow the client to determine whether these alternate semantics are enforced by the server, and, if so, for which operations. Given that some clients might have security reasons to be wary of such non-POSIX authorization semantics, it would be helpful to allow adherence to full POSIX authorization semantics to be negotiated using EXCHANGE_ID or other ops devoted to security-related negotiation.¶

18.1. Changes in Security Considerations

Beyond the needed inclusion of a threat analysis as Section 18.4 and the fact that all minor versions are dealt with together, the Security Considerations in this section differ substantially from those in [RFC7530] and [RFC8881]. These differences derive from a number of substantive changes in the approach to NFSv4 security presented in [RFC7530] and [RFC8881] and that appearing in this document.¶

These changes were made in order to improve the security of the NFSv4 protocols because it had been concluded that the previous treatment of these matters was in error, leading to a situation in which NFSv4's security goals were not met. As a result, this document supersedes the treatment of security in earlier documents, now viewed as incorrect. However, it will, for the benefit of those familiar with the previous treatment of these matters, draw attention to the important changes listed here.¶

• There is a vastly expanded range of threats being considered as described in Section 18.1.1¶

• New facilities provided by RPC on a per-connection basis can be used to deal with security issues, as described in Section 18.1.2. These include the use encryption on a per-connection basis, and the use of peer mutual authentication, to mitigate the security problems that come with the use of AUTH_SYS.¶

• The handling of identities with superuser privileges is no longer part of NFSv4 semantics, even though many platforms on which NFSv4 servers are implemented continue to depend, for local operation, on the existence of such identities.¶

  NFSv4 servers SHOULD NOT provide for such unrestricted access since doing so would provide a means by which an escalation-of-privilege on a client could be used to compromise a server to which it was connected, affecting all clients of that server.¶

  In connection with the use of "SHOULD NOT" above, and similar uses elsewhere, it is to be understood that valid reasons to do other than recommended are limited to the difficulty of promptly changing existing server implementations and the need to accommodate clients that have become dependent upon the existing handling. Further, those maintaining or using such implementations need to be aware of the security consequences of such use as well as the fact that clients who become aware of this characteristic may not be inclined to store their data on such a system.¶

• The appropriate handling of ACL-based authorization and necessary interactions between ACLs and modes is now specified in this standards-track document rather it being assumed that the behavior of server implementations needs to be accepted and deferred to.¶

18.2. Security Considerations Scope

18.3. Major New Recommendations

18.4. Threat Analysis

19.1. New Authstat Values

[Author Aside]: All unannotated paragraphs in this section are to be considered part of Consensus Item #32d.¶

The following new authstat values are necessary to enable a server to indicate that the server's policy does not allows requests to be made on the current connection because of security issues associated with connection type used. In the event they are received, the client needs to establish a new connection.¶

• The value XP_CRYPT indicates that the server will not support access using unencrypted connections while the current connection is not encrypted.¶

• The value XP_CPAUTH indicates that the server will not support access using connections for which the client peer has not authenticated itself as part of connection while the current connection has not been set up in that way.¶

19.2. New Authentication Pseudo-Flavors

[Author Aside]: All unannotated paragraphs in this section are to be considered part of Consensus Item #32e.¶

The new pseudo-flavors described in this section are to be made available to allow their return as part of the response to the SECINFO and SECINFO_NONAME operations. How these operations are to used to negotiate the use of appropriate auth flavors and associated security-relevant connection characteristics is discussed in Section 16.¶

The following pseodo-flavors are to be defined:¶

• PFL_CRYPT is returned to indicate that subsequent secinfo entries are to considered limited to use on connections for which transport-level encryption is provided.¶

• PFL_CRYPTMPA is returned to indicate that subsequent secinfo entries are to be considered limited to use on connections on which mutual peer authentication has been provided at connection setup.¶

• PFL_ANY is returned to indicate that subsequent secinfo entries are not to be considered limited to any particular type of connection.¶

A.1. Fundamental Security Changes

A number of changes reflect the basic motivation for a new treatment of NFSv4 security. These include the ability to obtain privacy and integrity services from RPC on a per-connection basis rather than as a service ancillary to a specific auth flavor.¶

This need to properly accomodate this new ficus motivated a major reorganization of the treatment of security together with further emphasis on the security of data in flight, described in detail in Section 15. In addition, the security negotiation framework for NFSv4 has been enhanced to support the combined negotiation of authentication-related services and connection characteristics, as described in Section 16.¶

Despite these major changes, there are not expected to be troublesome compatibility issues between peers supporting provision of security services on a per-connection basis and those without such support. Clients who are adapted to the new security facilities can use them when the server supports them, but will sometimes choose to use the older facilities when interacting with older servers. Servers who support the new facilities have the option of rejecting client connections from older clients but are encouraged to adopt policies rejecting such connections. Over time, it is expected that use of the older facilities will become less common as the newer facilities become more commonly implemented and the importance of security becomes more generally recognized¶

Another such change was in the treatment of AUTH_SYS, previously described, inaccurately, as an "OPTIONAL means of authentication" with the unfortunate use of the RFC2119 keyword obscuring the negative consequences of the typical use of AUTH_SYS (in the clear, without client-peer authentication) for security by enabling the execution of unauthenticated requests.¶

The new treatment avoids the inappropriate use of term "authentication" for all activities triggered by the use of RPC auth flavors and clearly distinguishes those flavors providing authentication from those providing identification only or neither identification nor authentication. For details, see Section 14.¶

As part of the necessary shift from a narrative focused on justifying security choices already made to evaluating the adequacy of existing security facilities, there has been a need to discuss NFSv4 security gaps, which might be addressed later. See Section 17.1 for a discussion of possible security-related extensions.¶

There are twelve consensus items (described in Appendix B) that are involved in effecting this class of changes. Although it is generally understood that the working group needs to take advantage of RPC-with-TLS, change how use of AUTH_SYS is presented, and include a credible threat analysis, there needs to be further discussion of these items as working group members are likely to disagree about the relative importance of:¶

• accommodating implementations based on previous specifications.¶

• providing a description of the expected path toward secure implementations¶

• maintaining and improving implementation performance¶

For each of the following items, there may need to be extensive discussion to arrive at a consensus text.¶

• Consensus Item #32 concerns extension of the process of SECINFO negotiation to accommodate the use of facilities such as rpc-with-tls, in addition to the current approach which directs only the choice of a suitable auth flavor.¶

  In the current document, pseudoflavors are added to allow the specification of connection characteristics, lthough it would be possible to avoid use and select connection characteristics by a process of trial and error.¶

• Consensus Item #52 concerns the handlinng of superuser semantics within NFSv4.¶

  There is a long tradition, within NFS, of treating superusr semantic, involving the elimination of file authorization checks, as part of protocol semantics. The security problems that this creates have been dealt with via "root-squashing", outside the protocol specification. Given that a threat analysis would essentially make such suppression of superuser semantics unavoidable, the current document deals with such semantics outside of the NFSv4 protocol.¶

• Consensus Item #36 concerns how to deal with the troublesome legacy of use of AUTH_SYS without client authentication and the common transmission of requests and responses without encryption.¶

  The specification now makes it clear that this has the potential to cause harm, while needing to deal ith the fact that it is a long time before this could be forbidden or recommmended against without allowances being made for current implementations. The ways that this issue needs to be dealt with require further discussion.¶

• Consensus Item #38 concerns temporary accommodations to deal with previous implementations which are unsafe.¶

  This is a consequence of existing implemenations based on current RFCs. The wording will require extensive discussion.¶

• Consensus Item #39 defines the new safer approach to AUTH_SYS.¶

  There needs to be discussion about how this safety should be characterized, given that you are trusting the client OS.¶

• Consensus Item #40 concerns the scope for the threat analysis in the Security Considerations section.¶

  Will need to reach a consensus on this as there appears to be no way we can make allowances in which physical isolation makes a significant difference, since this ssentially ignores insider threats.¶

• Consensus Item #41 discusses the major new security recommendations regarding protection of data in flight and client peer authentication. Also, covers the circumstances under which such recommendations can be bypassed.¶

  Will have to address concerns about performance effects.¶

• Consensus Item #47 concerns dubious paragraph regarding AUTH_NONE in SECINFO response which should be deleted if there are no compatibility issues that make that impossible.¶

  Will have to ascertain whether this is in fact supported by any server or relied on by any client.¶

• Consensus Item #35 discusses possible work on future security needs.¶

  Need to discuss whether there is too much or too little forward-looking material.¶

• Consensus Item #53 concerns the possible use of multi-factor authentication.¶

• Consensus Item #54 discusses prevention of code on a compromised client from hijacking the client machine's peer authentication.¶

  This relates to getting clarity about the safety of the client peer authentication available in rpc-with-tls.¶

• Consensus Item #55 discusses issues related to potential use of Kerberos in cloud environments.¶

  We will have to be sure we have a strog case here, since ther may be a feeling within the IESG that AUTH_SYS is per se unacceprable.¶

A.2. Need for Clarifying Changes

The need to make the major changes discussed in Appendix A.1 has meant that much text dealing with security has needed to be significantly revised or rewritten. As a result of that process, many issues involving unclear, inconsistent, or otherwise inappropriate text were uncovered and now need to be dealt with.¶

One important reason that such extensive changes are now necessary derives from a disagreement among working group partucipants as to the purpose of ACL support with one group of participants requiring new functionallity matching that of Windows ACLs with another major group uninterested in such features and unwilling to devote the effort involved in providing server-side support for them.¶

Within the NFSv4 architecture, such situations are normally dealt by defining one or more optional features, allowing different servers to provide different levels of support, with the client able to determine whether a selected server has the desired level of support.¶

Unfortunately, for reasons that remain unclear, this approach was not followed in writing RFCs 3530, 5661, 7530, and 8881. Instead, the full definition of the ACL was defined as an OPTIONAL attribute with no clear definition of useful support subsets or way of testing the support level. Essentially each ACE mask bit was made its own optional feature. To further complicate things the keyword "SHOULD" was frequenlt used, raising the possibility that the support might be other than described. This made it impossible for clients to determine the level of ACL suppport provided, or to elect to use a server based on the level of support provided.¶

While the author believes that changes in this situation are necessary, the fact that we are changing a document adopted by consensus requires the working group to be clear about the acceptability of the changes. This applies to both the troublesome issues discussed in Section 3.4 and to the other changes included below.¶

The primary source of these not-clearly specified elements is the disparate goals of many participants in the specification process:¶

• For many participants, the ACL definition needed to include a large part of Windows-oriented semantics, including elements clearly distinct from the Unix semantics supported by earlier versions of NFS.¶

• For other participants, such semantic extensions were of little interest.¶

While the author believes such changes are necessary, the fact that we are changing a document adopted by consensus requires the working group to be clear about the acceptability of the changes. This applies to both the troublesome issues discussed in Section 3.4 and to the other changes included below.¶

Because of the need for re-organization of subjects relating to authorization, the ordering of the list follows the text of the current version which may differ considerably from that in earlier versions of the I-D.¶

The subjects related to authorization needed to be reorganized because of the following complexities:¶

• There are three kinds of authorization to deal with.¶

• The most important kind of authorization, file access authorization, is controlled by mode attributes and ACL-related attributes, creating multiple authorization models and the need to coordinate them.¶

• ACLs, besides their prominent role with regard to file access authorization, provide control of alarm and audit facilities.¶

As a result, these matters are dealt with in the eight top-level sections from 5 through 13.¶

• Section 5,a new top-level section, describes all the authorization-related attributes.¶

• Section 6, a new top-level section, describes the the structure of ACLs with their uses described later in sections 8 through 10 and in Section 13.¶

• In Section 7, there is a discussion of authorization in general. This includes a discussion of user-based file authentication, NFSv4's approach to mandatory access control, and a discussion of locking state authorization, each of which is described in later top-level sections.¶

• File access authorization is described primarily in Section 8. Because this authorization can be controlled by either the mode attribute or various ACL-related attributes, there is an introduction to these authorization- determining attributes in Section 8.1.¶

  Because file access authorization can be controlled by the posix-related authorization attributed decribed in Section 5.3 and by ACL-related attributes described in Section 5.4, there is an introduction to how these relate in Section 8.2 followed by discussion of the semantics of the two kinds of supported ACLs in Section 8.4.¶

  Issues related to the existence of two separate file access are dealt with in Sections 9, dealing with the similarities between these two, and 10 dealing with their co-existence and potential conflict.¶

• Sections 11 through 13 deal with, labelled NFS authorization, state modification authorization, and the uses of ACLs outside authorization.¶

Beyond the reorganization described above, there are numerous matters to be dealt with, reflecting the previous inability to clearly specify two sets of authorization behaviors and their potential interactions.¶

• Also in Section 8.2, there is added clarity in the discussion of support for multiple authorization approaches by eliminating use of the subjective term "reasonable semantics".¶

  In connection with this clarification, we have switched from describing the needed co-ordination between modes and acls as "goals" to describing them as "requirements" to give clients some basis for expecting interoperability in handling these issues.¶

  As a result of this shift to a prescriptive framework applying to all minor versions it becomes possible to treat all minor versions together. In existing RFCs and some earlier versions of this document, it had been assumed that NFSv4.0 was free to ignore the relevant prescriptions first put forth in RFC 5661 and only needed to address the "goals" for this co-ordination.¶

A.3. Addressing the Need for Clarifying Changes

Unlike the issues discussed in Appendix A.1, for which the path to make the necessary changes is laid out in that same section, the changes discussed in Appendix A.2, are discussed here, because resolving them is a more involved matter.¶

The difficulty derives principally from the fact that there are existing clients and server with very different approaches to these matters, making it difficult or impossible to reach a consensus that will make some existing clients non-compliant.¶

In such a situation, we need to allow a set of possibitlities, as has been done for internationalization of file names in [RFC7530] for NFSv4.0 and in [I-D.ietf-nfsv4-internationalization], for all minor versions.¶

As in the case of the internationalization of file names, we will have to accommodate a range of possible server implementations, but the task will, in this case, involve a lot more work. To see why, we will first explore the situation for internationalization of file names and later see how the situation for these issues poses greater difficulties and how they might be addressed. Some of these dificulties match other internationalization issues, such as the handling of internationalized domain names and the proper treatment of case-insensitive handling of file names that dealt with incorrectly or not at all in [RFC7530].¶

• The treatment of internationalization of file names in [RFC7530] and [RFC5661] was so divorced from the needs of implementations that it was necessary to be ignore it.¶

  On the other hand, the treatment of internationalization of file names in the obsoleted document [RFC3010] was available as a base and had been implemented by many clients and servers.¶

• The vast majority of clients and servers implemented the same approach to internationalization, even though it was not limited to the use of UTF-8.¶

  Despite the general aversion to this approach within the IESG, it was accepted, most likely because we were describing NFSv4 internationalization on "as-implemented" basis.¶

• Overall, we wound up allowing a total of three sorts of server behaviors, two of which were UTF-8-aware.¶

  One UTF-8-aware option that had been implemented, simply considred canonically equivalent names as deignating the same file with changing the name to a different canonically equivalent name. Although this approach diverged from IESG expectations regarding normalization, it was accepted.¶

  Another UTF-8-aware option was allowed, despite the absence of any implementations. It allowed servers to normalize file names while forbidding them from rejecting unormalized names. This was allowed because it would cause no difficulties for clients and because forbidding it might have caused problems for IESG acceptance.¶

• We were able, where necessary, to give the client the ability to detrmine which form of internationalization supported provided by the server for any particular file system, using an OPTIONAL attribute made available in NFSv4.1.¶

The situation with regard to the clarifying changes needed in this document is different for the reasons listed below.¶

• Rather than three valid choices for acceptable server behavior, with authorization we have a vast number.¶

  Given that there are nine ACE mask bits, each of whick might not be supported, there are at least 512 possible valid behaviors, even if none of the dubious instances of SHOULD creates additional valid behavioral patterns.¶

  Added to that are multiple (at least two) ways of mapping ACLs to modes and at leat three different behaviors in mdifying ACLs to reflect changes in mode.¶

  As a result, existing RFCs allow at least three thousand different server behaviors.¶

• There is little information available about the particular behaviors manifested by existing server-fs combinations.¶

  It may be difficult to get this informarion because the implementations were done by people no longer participating in the working or who were never involved in the working group¶

• There are no existing attributes that might be used to communicates server/fs choices to the client.¶

This creates a difficult situation. To fully resolve it will require substantial work as follows:¶

• Determining whether each of the dubious instances of "SHOULD" is in fact relied on by existing servers or might be needed by future servers.¶

• Determining which ACE mask bits are supported by all existing servers or not supported by any existing server to further limit the set of OPTIONAL features that clients need to be made aware of.¶

  There might also be cases where some set of mask bits are are always either supported or unsupported together.¶

• Determining the set of mappings from acls to modes that are actually and making each such OPTIONAL as opposed to the current situation in which an "intentional" "SHOULD" is used despite the mismatch between this use and [RFC2119].¶

• Making a similar determination of the actions actually applied to acl when the mode is changed.¶

Once we have the above information, it will be clear how we could create adress these issues inn either of the ways discused below:¶

• Have a way of determining whether support of NFSv4 ACL semaniics or UNIX ACL semantics is provided by any particular vil systtem, such as that proposed by consensus item #61.¶

  This approach wiuld address the motive for the current under-specfication but would not address possible negative coonsequences arising from that under-specification.¶

• providing an appropriate extension as described in Section 17.2 to provide clients with an adequate description of expected server behavior. This document will be limited to providing client implementation guidance about dealing with the uncertinty in cases in which new attributes is not available. The situation will be similar to that described in Section 15 of [I-D.ietf-nfsv4-internationalization].¶