ACLs within the NFSv4 Protocols
draft-dnoveck-nfsv4-acls-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | David Noveck | ||
| Last updated | 2024-02-29 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dnoveck-nfsv4-acls-00
NFSv4 D. Noveck, Ed.
Internet-Draft NetApp
Updates: 8881, 7530 (if approved) 29 February 2024
Intended status: Standards Track
Expires: 1 September 2024
ACLs within the NFSv4 Protocols
draft-dnoveck-nfsv4-acls-00
Abstract
This document describes the structure of NFSv4 ACLs and their role in
the NFSv4 security architecture. While their role in providing a
more flexible approach to file access authorization than is made
available by the POSIX-derived authorization-related attributes, the
potential provision of other security-related functionality is
covered as well.
While the goals of the description are similar to that used in
previous specficaion, the approach taken is substantally different,
in that a core set of functionality, derived form the the now-
withdrawn POSIX draft ACLs is the conceptual base of the feature set
while extensions to that functionality are made available as OPTIONAL
extensions to that core.
The current version of the document is intended, in large part, to
result in working group discussion regarding existing NFSv4 security
issues and to provide a framework for addressing these issues and
obtaining working group consensus regarding necessary changes.
When the resulting document is eventually published as an RFC, it
will supersede the descriptions of ACL structure and semantics
appearing in existing minor version specification documents such as
RFCs 7530 and 8881, thereby updating RFC7530 and RFC8881.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Noveck Expires 1 September 2024 [Page 1]
Internet-Draft Nfsv4 ACLs February 2024
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Relationship to the Overall Security Document . . . . . . 4
1.2. Changes to the Description of ACLs in this Document . . . 5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
2.1. Keyword Definitions . . . . . . . . . . . . . . . . . . . 6
2.2. Special Considerations . . . . . . . . . . . . . . . . . 6
3. ACL-based Authorization-related Attributes . . . . . . . . . 7
3.1. Table of ACL-related Attributes . . . . . . . . . . . . . 7
3.2. Types of ACLs . . . . . . . . . . . . . . . . . . . . . . 7
3.3. The Acl Attribute (v4.0) . . . . . . . . . . . . . . . . 8
3.4. The Aclsupport Attribute (v4.0) . . . . . . . . . . . . . 10
3.5. The Aclfeature Attribute (v4.2 extension) . . . . . . . . 12
3.6. The Dacl Attribute (v4.1) . . . . . . . . . . . . . . . . 12
Noveck Expires 1 September 2024 [Page 2]
Internet-Draft Nfsv4 ACLs February 2024
3.7. The Sacl Attribute (v4.1) . . . . . . . . . . . . . . . . 12
4. Structure and Function of NFSv4 Access Control Lists . . . . 13
4.1. ACL Semantics Choices . . . . . . . . . . . . . . . . . . 14
4.2. Discovery of ACL Semantics . . . . . . . . . . . . . . . 16
4.3. Inferring ACL Semantics . . . . . . . . . . . . . . . . . 16
5. Structure of Access Control Entries . . . . . . . . . . . . . 17
6. ACE Type . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. ACE Access Mask . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Changes in Descriptions of Mask Bits . . . . . . . . . . 21
7.2. Role of Sticky Bit in ACL-based Auhorization . . . . . . 22
7.2.1. Uses of Core Mask Bits . . . . . . . . . . . . . . . 23
7.2.2. Uses of Finer-grained Mask Bits Derived from Write . 27
7.2.3. Uses of Other Additional Mask Bits . . . . . . . . . 29
7.2.4. Possible Uses of Additional Mask Bits . . . . . . . . 31
8. Handling of Deletion . . . . . . . . . . . . . . . . . . . . 33
8.1. Previous Handling of Deletion . . . . . . . . . . . . . . 34
9. ACE flag bits . . . . . . . . . . . . . . . . . . . . . . . . 35
10. Details Regarding ACE Flag Bits . . . . . . . . . . . . . . . 36
11. ACE Who . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
12. Automatic Inheritance Features . . . . . . . . . . . . . . . 40
13. Processing Access Control Entries . . . . . . . . . . . . . . 42
14. Combining Authorization Models . . . . . . . . . . . . . . . 44
14.1. Background for Combined Authorization Model . . . . . . 45
14.2. Needed Attribute Coordination . . . . . . . . . . . . . 47
14.3. Computing a Mode Attribute from an ACL . . . . . . . . . 50
14.4. Alternatives in Computing Mode Bits . . . . . . . . . . 52
14.5. Handling of UNIX ACLs . . . . . . . . . . . . . . . . . 54
14.6. Setting Multiple ACL Attributes . . . . . . . . . . . . 54
14.7. Setting Mode and not ACL (overall) . . . . . . . . . . . 54
14.7.1. Setting Mode and not ACL (vestigial) . . . . . . . . 54
14.7.2. Setting Mode and not ACL (Discussion) . . . . . . . 55
14.7.3. Setting Mode and not ACL (Proposed) . . . . . . . . 57
14.8. Setting ACL and Not Mode . . . . . . . . . . . . . . . . 62
14.9. Setting Both ACL and Mode . . . . . . . . . . . . . . . 62
14.10. Retrieving the Mode and/or ACL Attributes . . . . . . . 62
14.11. Use of Inherited ACL When Creating Objects . . . . . . . 64
14.12. Combined Authorization Models for NFSv4.2 . . . . . . . 64
15. Other Uses of Access Control Lists . . . . . . . . . . . . . 65
16. Security Considerations . . . . . . . . . . . . . . . . . . . 65
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 65
18.1. Normative References . . . . . . . . . . . . . . . . . . 65
18.2. Informative References . . . . . . . . . . . . . . . . . 66
Appendix A. Issues for which Consensus Needs to be
Ascertained . . . . . . . . . . . . . . . . . . . . . . . 66
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 74
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 75
Noveck Expires 1 September 2024 [Page 3]
Internet-Draft Nfsv4 ACLs February 2024
1. Introduction
This document describes the ACL-related features of the NFsv4
protocol, all of which are accessed through the use of a set of
OPTIONAL attribuutes described in Section 3. These attributes
provide:
* Additional means of specifying file access authorization
constraints that are more flexible than those provided by the
authorization model inherited from POSIX, based on the attributes
Mode, Owner, and OwnerGroup.
* A number of security-related facilities separate from
authorization that use ACLs to identify sets of actions that might
be subject to vrious forms of montoring as described in
Section 15.
1.1. Relationship to the Overall Security Document
This document is best understood when it is read together with
[I-D.dnoveck-nfsv4-security] which dicusses, as a whole, security
features provided that are not connected with ACLs, and which is a
complete description in cases in which the OPTIONAL ACL-related
attributes are not implemented.
In many cases, the overall ecurity document will have abbreviated
descriptions that serve as an introduction to material in this
document and reference sections within this document. Similarly,
there will be occasions where it is necessary for this document to
reference general features of NFSv4 security documented in
[I-D.dnoveck-nfsv4-security].
For the most part, these two documents are indepenendent, except for
the inter-document reference discussed above. However, the following
execptions should be noted:
* Section 1 of [I-D.dnoveck-nfsv4-security], in its entirety,
applies to both document, even in the absence of explicit inter-
document references.
* The terminology defined in Section 4.1 of
[I-D.dnoveck-nfsv4-security] can be used in either document,
without en explcit reference
* The sections dealing with Security Considerations and IANA
Considerations appearing in [I-D.dnoveck-nfsv4-security], i.e.,
Sections 18 and 19 apply to the security-related changes being
made in the current update as a whole, i.e. to both documents.
Noveck Expires 1 September 2024 [Page 4]
Internet-Draft Nfsv4 ACLs February 2024
* Appendix A of [I-D.dnoveck-nfsv4-security], in describing the
security-related changes made from previous specifications,
includes change made in both this document and the overall
security document.
* The Appendices devoted to tracking Consensus Items, i.e.,
Appendix A of this document and Apppendex B of
[I-D.dnoveck-nfsv4-security], need to be considered together, even
though each appendix applies only to the document in which it
appears.
This is because there are related consensus items in the several
document whose resolution might affect one another, including some
that result from consensus items affecting material now in muliple
documents.
1.2. Changes to the Description of ACLs in this Document
This document has the same goals as previous descriptions of ACLs in
earlier specifications and earlier drafts of the security document
[I-D.dnoveck-nfsv4-security]. The most important of these is how to
address the need to support multiple semantic models for
ACLs,including UNIX ACLs, NFSv4 ACLs and various hybrids of the two.
In this document we shift between the two approaches listed below:
* Prevuously the NFSv4 ACL model has been presented as canonical,
while the inability of many servers to provide such support
addressed by a pervasive laxness about descriptions of the
semantics.
This approach did not give clients any way to determine which ACL
model was supported by a given server, sharply limiting the actual
value of the additional elements added to UNIX ACLs.
* [Author Aside (Item #10Da)]: This shift, elements of which affect
Large parts of this docement will be identified as Consensus Item
#10D. In this document the more limited UNIX ACL Model is
presented aa foundational, while the elements necessary to provide
support for NFSv4 ACLs are treated as OPTIONAL to the UNIX ACL
model.
[Author Aside (#Item #10Ea)]: The apparatous referred to is
defined in later sections of this document where it is identified
as Conensus Item #10E. To allow clients to determine which
elements of the more flexible model are present an additional
OPTIONAL attribute Aclfeature is defined and supplemented by means
of inferring the extensions availble when it is not present/
Noveck Expires 1 September 2024 [Page 5]
Internet-Draft Nfsv4 ACLs February 2024
2. Requirements Language
2.1. Keyword Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as specified in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown
here.
2.2. Special Considerations
Because this document needs to revise previous treatments of its
subject, it will need to cite previous treatments of issues that now
need to be dealt with in a different way. This will take the form of
quotations from documents whose treatment of the subject is being
obsoleted, most often direct but sometimes indirect as well.
Paragraphs headed "[Previous Treatment] or otherwise annotated as
having that status, as described in Section 1 of
[I-D.dnoveck-nfsv4-security], can be considered quotations in this
context.
Such treatments in quotations will involve use of these BCP14-defined
terms in two noteworthy ways:
* The term may have been used inappropriately (i.e not in accord
with [RFC2119]), as has been the case for the "RECOMMENDED"
attributes, which are in fact OPTIONAL.
In such cases, the surrounding text will make clear that the
quoted text does not have a normative effect.
* The term may 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.
Noveck Expires 1 September 2024 [Page 6]
Internet-Draft Nfsv4 ACLs February 2024
3. 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 4 and its subsections.
3.1. Table of ACL-related Attributes
3.2. Types of ACLs
The ACL allows authorization schemes outside those conforming to the
POSIX approach to be specified and applied to file objects. This
provides additional flexibility in a number of ways:
1. There may be multiple users or sets of users assigned different
privileges to address cases in which the appropriate privilege
assignments do not conform to the POSIX model in that they are
different for users in the same group or different for two groups
outside the owning group.
ACLs support this by allowing an array of Access Control Entries,
each of which specifies handling for a user or user group.
2. For partcular users or sets of users, the set of operations to be
allowed might not be expressible using the three bits provided by
POSIX as supplemented by special privileges for operations
reserved to file owner.
NFSv4 ACLs, as described in Section 4, addresss both issues by
defining, within the Access Control Entry, a large set of distinct
privilege bits, modeled on those provided by Windows ACLs.
ACLs based on the withdrawn POSIX ACL draft, (i.e. UNIX ACLs) make a
more limited change to the POSIX authorization model and are
represented by the same sorts of structures as NFSv4 ACLs, altough
there are restrictions imposed by the UNIX ACL model.
Although these two have some common goals, they are substantially
different, in that:
Noveck Expires 1 September 2024 [Page 7]
Internet-Draft Nfsv4 ACLs February 2024
* The draft POSIX ACLs addresses only the first of the motivations
for extension, while the NFSv4 ACL model is intended to address
both of them, by defining a large range of bits in the ACE mask,
rather than the three POSIX bits.
* NFSv4 ACLs, by supporting DENY entries allow specfic privileges to
be allowed for some member of a group and be denied to some
particular users.
* NFSv4 ACLs provide additional security-related facilities in
addition to authorization control, through the use of AUDIT and
alarm ACEs.
{Author Aside (Item #61a)]: In order to justify a shift of the acl
and dacl attributes back to be OPTIONAL, it is necessary to define
for each file system, the type of ACL semantics provided. In so
doing, we will have to mke provision for various hybrids if such
implementations actually exist, while not necessarily seeking to
preserve the ability to generate other such potential hybrids.
[Consensus Needed, Including List (Item #61a)]: The determination of
the type of ACL semantics proceeds as follows:
* If the aclsupport attribute indicates that either AUDIT or ALARM
ACEs are supported, then it can be assumed that NFSv4 ACL
semantics are provided.
* If the aclsupport attribute is not supported, then if the sacl
attribute is supported then it also can be assumed that NFSv4 ACL
semantics are provided.
* Otherwise, If the aclsupport attribute is supported then the
presence of support for DENY ACEs determines whether support is
NFSv4 ACL semantics is provided.
* In the case in which neiter the aclspport attribute not the SACL
attribute is supported, then it can also be assumed thatsupport is
NFSv4 ACL semantics is provided.
As a conequence, server implementations providing support for UNIX
ACLs only, need to support the aclsupport attribute.
3.3. The Acl Attribute (v4.0)
This per-object attribute consists of an array of Access Control
Entries which apply to operations performed on the current object,
controlling authorization and monitoring of attempted operations.
Noveck Expires 1 September 2024 [Page 8]
Internet-Draft Nfsv4 ACLs February 2024
This attribute, as opposed to the sacl and dacl attributes, consists
only of an ACE array and does not support automatic inheritance.
The acl attribute is OPTIONAL and there is no requirement that a
server support it. However, when the dacl attribute is supported, it
is a good idea to provide support for the acl attribute as well, in
order to accommodate clients that have not been upgraded to use the
dacl attribute.
{Consenses needed, Including List (Item #65a)]: While the original
intention was to define a usable OPTIONAL attribute based on the
NFSv4 ACLs defined previous specfications, it is now more appropriate
to designate this under-specified attribute as experiemental although
still formally OPTIONAL, until the items below have been addressed.
* The intention to support, as values of this attribute two
different ACL approaches, each with its own semantics. These
include both the NFSv4 ACLs based on the Windows ACL model and a
subset based on the more restricted semantics provided by the
withdrawn POSIX ACL document with a straightforward mapping of
those into the format of NFSv4 ACLs.
The association of two such different semantic models without
giving the client a way to determine which semantic model is in
effect.
* The potential interoperability problems are vastly expanded by the
specific method by which these two models are supported.
Instead of allowing servers to choose between these two
approaches, e.g. by using the term "MAY", most statements
regarding ACL semactics use the term "SHOULD", described in the
text as "intentional", apparently assuming that the result is
essentially equivalent to the use of "MAY". Even apart from the
misuse of the terms defined in [RFC2119], this has the effect of
replacing a single choice by allowing a large number of unco-
ordinated choices, exponentially raising the number of possibly
valid semantic models that clients and users have to accmmodate.
* It is not clear how far this pick-and-choose approach extends. In
the case of the ace mask bits which are finer-grained than the
three bits in the mode and in POSIX ACLs, there is no explicit
text indicating how the coarser-grained approach would be
supported by a server built to support POSIX ACLs, leaving the
actual requirements uncertain.
Noveck Expires 1 September 2024 [Page 9]
Internet-Draft Nfsv4 ACLs February 2024
* Although some efforts have been made to limit the damage caused by
this specification uncertainty by urging clients to determine
authorization decisions using ACCESS rather than by examining the
ACL itself, this only addresses half of the problem and the
question of what ACL to set to effect a particular authorization
regime remains unaddressesd, limiting the usefulness of the ACL-
related features.
Although significant efforts have been made to widen the
information returned by ACCESS beyond the three-bit POSIX model,
ther are still cases in which it is insufficiently fine-grained.
For example, adding a new file and a new sub-directory which have
dfferent ACE mask bits are both represented by a single bit in
ACCESS.
[Author Aside]: Although it has generally been assumed that changes
to sacl and dacl attributes are to be visible in the acl and vice
versa, NFSv4.1 specification do not appear to document this fact.
[Consensus Item, Including List (Item #16a)]: For NFSv4.1 servers
that support Both the acl attribute and one or more of the sacl and
dacl attributes, changes to the ACE's need to be immediately
reflected in the other supported attributes:
* The result of reading the dacl attribute MUST consist of a set of
ACEs that are exactly the same as the ACEs ALLOW and DENY ACEs
within the the acl attribute, in the same order.
* The result of reading the sacl attribute MUST consist of a set of
ACEs that are exactly the same as the ACEs AUDIT and ALARM ACEs
within the the acl attribute, in the same order.
* The result of reading the acl attribute MUST consist of a set of
ACEs that are exactly the same as the union of ACEs within the
sacl and dacl attributes. Two ACEs that both appear in one of the
sacl or dacl attributes will appear in the same order in the acl
attribute.
3.4. The Aclsupport Attribute (v4.0)
A server need not support all of the ACE types described in
Section 6.1. This attribute indicates which ACE types are supported
for the current file system by any of the acl, sacl, or dacl
attributes.
The bitmask constants used to represent the abovementioned
definitions within the aclsupport attribute are as follows:
Noveck Expires 1 September 2024 [Page 10]
Internet-Draft Nfsv4 ACLs February 2024
const ACL4_SUPPORT_ALLOW_ACL = 0x00000001;
const ACL4_SUPPORT_DENY_ACL = 0x00000002;
const ACL4_SUPPORT_AUDIT_ACL = 0x00000004;
const ACL4_SUPPORT_ALARM_ACL = 0x00000008;
[Author Aside (Item #14b)]: Even though support aclsupport is
OPTIONAL, there has been no mention of the possibility of it not
being supported.
[Consensus Needed (Item #14b)]: If this attribute is not supported
for a server or filesystem, the client is entitled to assume that, if
the acl attribute is supported, support for ALLOW ACEs is present.
Thus, if such a server supports the the sacl attribute, clients are
not likely to use it if aclsupport is not supported by the server.
[Previous Treatment (Item #61a)]: Servers that support either the
ALLOW or DENY ACE type SHOULD support both ALLOW and DENY ACE types.
[Author Aside, Including List: (Items #61a, #62b)]: The use of
"SHOULD" in the preceding is unhelpful for the following reasons:
* While it is unclear what the intention is, it is certainly is not
in accord with RFC2119 since there is no indication of potential
harm or what might be valid reasons to do otherwise.
* While it might be one of "intentional" SHOULDs, that would make
the paragraph meaningless since such SHHOULds are essentially
equal to MAYs.
* The most likely source of divergence in the support for ALLOW and
DENY ACEs is not mentioned at all.
[Consensus Needed (Item #61b)]: Servers that support either the DENY
ACE type MUST support the ALLOW and ACE type as well.
[Consensus Needed, Including list (#61b)]: Clients should not attempt
to set an ACE unless the server claims support for that ACE type.
The server MUST reject requests with NFS4ERR_ATTRNOTSUPP if any of
the following apply:
* If the server receives a request to set an ACE type that is not
allowed as part of the acl attribute being set.
* If the server receives a request to set an ACE, it cannot store.
Support for any of the ACL attributes is OPTIONAL. However, certain
restrictions apply regarding the interaction of support for these
attributes, A server that supports either of the new ACL attributes
Noveck Expires 1 September 2024 [Page 11]
Internet-Draft Nfsv4 ACLs February 2024
(dacl or sacl) MUST support use of the new ACL attributes to access
all of the ACE types that it supports. In other words, if such a
server supports ALLOW or DENY ACEs and the sacl attribute, then it
MUST support the dacl attribute and any ALLOW or DENY ACE tyopes
supported by the tha acl attribute MUST be supported in the dacl
attribute as well. Similarly, if it supports AUDIT or ALARM ACEs and
the dacl attribute, then it MUST support the sacl attribute any AUDIT
or ALARM ACE types supported by the tha acl attribute MUST be
supported in the dacl attribute as well.
3.5. The Aclfeature Attribute (v4.2 extension)
3.6. The Dacl Attribute (v4.1)
The dacl attribute was added in NFSv4.1 in order to divide ACLs so
that the authorization-related entries (i.e. ALLOW and DENY entries)
were no longer combined in the same attribute as AUDIT and ALARM
entries.
{Consensus needed, Thru rest of Section (Item #65b)]: While the
original intention was to define a usable OPTIONAL attribute based on
the NFSv4 ACLs defined previous specifications, it is now more
appropriate to designate this under-specified attribute as
exprimental although still formally OPTIONAL until the issues
discussed in Section 3.3 are addressed
Athough the issues applying to the acl attribute apply equally to the
dacl attribute, given the description in earlier specifications, it
may be easier to resolve them in the case of the dacl attribute for
the following reasons:
* Implementaions of POSIX ACLs might not have been updated to
support the sacl attriute, since doing so would add no value.
* Even if such POSIX-ACL-oriented implentations of the sacl
attribute did exist, it might be easier to get agreement on
regularizing the sacl attribute since, if acl were left as it is,
the POSIX ACL support would still be available.
3.7. The Sacl Attribute (v4.1)
The sacl attribute is like the acl attribute, but sacl allows only
AUDIT and ALARM ACEs. The sacl attribute supports automatic (see
Section 12).
{Consensus needed, Thru rest of Section (Item #65c)]: While the
original intention was to define a usable OPTIONAL attribute based on
the NFSv4 ACLs definedin previous specifications, it is now more
Noveck Expires 1 September 2024 [Page 12]
Internet-Draft Nfsv4 ACLs February 2024
appropriate to designate this under-specified attribute as
exprimental although still formally OPTIONAL until the issues
discussed in Section 3.3 are addressed
The sacl attribute was added in NFSv4.1 in order to divide ACLs so
that the non-authorization-related entries (i.e. AUDIT and ALARM
entries) would no longer be combinded in the same attribute with the
ALLOW and DENY entries.
[Author Aside, Including List (Item #61c)]: Athough the exsting
discussion of ACE structure results in the same sortof lack of
clarity affecting the acl and dacl attributes, it us more likely that
these will resolved in the case of the sacl attribute as compared to
the acl or dacl attributes, even though the problems with the
existing text are essentially the same.
* There are no AUDIT or ALARM entries, in POSIX ACLs, so there would
be no need accommodate existing implementations of these that
embody a more POSIX-oriented semantic model.
As a result, it is likely to be easier to get WG approval for
changes that clearly state that the ACE mask bits are to followed
strictly for the these types of ACEs.
* Since such entries have no role in compute a corresponding mode
attribute, the effect of this issue for the sacl attribute is not
problematic.
4. Structure and Function of NFSv4 Access Control Lists
NFSv4 Access Control Lists consisting of multiple Access Control
Elements. While originally designed to support a more flexible
authorization model, these lists have multiple uses within NFSv4,
with the use of each element depending on its type, as defined in
Section 6.
* ACLs may be used to provide a more flexible authorization model as
described in Section 8.4 of [I-D.dnoveck-nfsv4-security]. This
involves use of Access Control Entries of the ALLOW and DENY
types.
* They may be used to provide the security-related services
described in Section 15. This involves use of Access Control
Entries of the AUDIT and ALARM types.
Noveck Expires 1 September 2024 [Page 13]
Internet-Draft Nfsv4 ACLs February 2024
[Consensus Needed (Item #61d)]: Subsections of this section and of
Section 5 define the structure of and semantics of NFSv4 ACLs,
whether they are used to represent UNIX ACLs or various extensions
thereof, upto the full set of extensions provided by NFSv4 ACL
semantics.
Matters that relate only to extensions provided to support NFSv4 ACLs
including the definition of the NFSv4.1-specific attribute Sacl, are
discussed in 15 and smmarized in Section 8.4 of
[I-D.dnoveck-nfsv4-security].
4.1. ACL Semantics Choices
[Consensus Needed, Including List (Item #61e)]: There are a range of
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, and a number of features
related to ACL inheritance.
* UNIX ACLs, based on the withdrawn POSIX ACL draft.
This approach retains the three bits typical of POSIX semantics
and maps them, with a number of implied restrictions, to a subset
of the more expansive set of ACE mask bits defined in Section 7.
* Various hybrids of the two models, supporting some, but mot all of
the extensions to UNIX ACLs introduced in earlier minor version
specifications.
The new Aclfeature attribute, available as an extension in
NFSv4.2, allow the client to determine which extensions are
implemented for a particular file system. See xref target="ACL-
sem-discovery"/> for further discussion.
Where this feature is not available, including NFSv4.0 and
NFSv4.1, information on the extensions supported can be inferred
based on the value of the Aclsupport attribute. See xref
target="ACL-sem-inference"/> for details.
In all of these cases the client can rely on the fact that the
core features derived from UNIX ACLs are always available when the
Acl or Dacl attributes are supported.
Noveck Expires 1 September 2024 [Page 14]
Internet-Draft Nfsv4 ACLs February 2024
[Author Aside, Including List (Items #30a, #61e)]: Earlier
specifications of the ACL feature allowed servers to provide any of
these semantic models. Unfortunately, the server was not given an
explicit choice and the client has no way of determing the semantics
associated with the ACL and adapting accordingly. Instead the
approach was to widen the range of permissible server behavior to be
implemented for ACLs, so it included both sorts of ACL semantics,
various hybrids unlikely to be implemented, as welll as a lot of
miscellaneous variants, many probably unintende, 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 often stated that these uses of "SHOULD" were
"intentional" without explicitly providing any reason that would
justify not performing the recommended action or discussion of the
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.
Noveck Expires 1 September 2024 [Page 15]
Internet-Draft Nfsv4 ACLs February 2024
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.
4.2. Discovery of ACL Semantics
The OPTIONAL attribute Aclfeature defined as an NFSv4.2 extension
(see Section 3.5 provides a way for the client to determine what
extensions to the UNIX ACL model are supported on a given file
system. The specific extensions that may be supported include the
following:
* The support for ACE mask bits (see Section 7 in addition to the
three that represent the POSIX-derived privilege bits: Read,
Write, and Execute, which are always supported. In addition to
these coarse-grained mask bits, which are discussed in
Section 7.2.1, there are flags withing the Aclfeature attribute
that indicates whether the additional mask bits defined in
Sections 7.2.2 and 7.2.3 are supported as well.
* The inclusion of support for ACE types in addition to
ACE4_ACCESS_ALLOWED_ACE_TYPE is deteminabe using the Aclsupport
attribute. In addition, the AclFeature attribute allows the
client to determine the of ACE types that, while not supported,
can be stored
* flags
* who
4.3. Inferring ACL Semantics
In cases in which the Aclfeature attribute is not supported,
including minor version for which it is not defined (i.e. minor
versions below two), there are way to determine the extensions
supported but sets of extensions are more limited and the client
might require more effort to adapt in order to use the extensions
while andling gor clients that are not prepared to use the extensions
is dealt with trivially, since the core elements of UNIX ACL are
always present. The following limitations should be noted:
Noveck Expires 1 September 2024 [Page 16]
Internet-Draft Nfsv4 ACLs February 2024
5. Structure of Access Control Entries
The attributes acl, sacl (v4.1 only) and dacl (v4.1 only) each
contain an array of Access Control Entries (ACEs) that are associated
with the file system object. The client can set and get these
attributes while the server is responsible for using the ACL-related
attributes to perform access control. The client can use the OPEN or
ACCESS operations to check access without modifying or explicitly
reading data or metadata.
The NFS ACE structure is defined as follows:
typedef uint32_t acetype4;
typedef uint32_t aceflag4;
typedef uint32_t acemask4;
struct nfsace4 {
acetype4 type;
aceflag4 flag;
acemask4 access_mask;
utf8str_mixed who;
};
6. 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 are used in the Sacl attribute.
+==============================+==============+====================+
| Value | Abbreviation | Description |
+==============================+==============+====================+
| ACE4_ACCESS_ALLOWED_ACE_TYPE | ALLOW | Explicitly grants |
| | | the ability to |
| | | perform the action |
| | | specified in |
| | | acemask4 to the |
| | | file or directory. |
| | | |
Noveck Expires 1 September 2024 [Page 17]
Internet-Draft Nfsv4 ACLs February 2024
| | | When all such |
| | | actions to be done |
| | | by a given |
| | | operation are |
| | | explcitly allowed, |
| | | the operation is |
| | | authorized and |
| | | scanning of the |
| | | ACL to dtermine |
| | | authorization |
| | | stops. |
+------------------------------+--------------+--------------------+
| ACE4_ACCESS_DENIED_ACE_TYPE | DENY | Explicitly denies |
| | | the ability to |
| | | perform the action |
| | | specified in |
| | | acemask4 to the |
| | | file or directory. |
| | | |
| | | When any of the |
| | | actions to be done |
| | | by a given |
| | | operation are |
| | | explcitly denied, |
| | | the operation is |
| | | unauthorized and |
| | | scanning ofthe ACL |
| | | to determine |
| | | authoriztion |
| | | stops. |
+------------------------------+--------------+--------------------+
| ACE4_SYSTEM_AUDIT_ACE_TYPE | AUDIT | Log (in a system- |
| | | dependent way) any |
| | | attempt to |
| | | perform, for the |
| | | file or directory, |
| | | any of the actions |
| | | specified in |
| | | acemask4. |
+------------------------------+--------------+--------------------+
| ACE4_SYSTEM_ALARM_ACE_TYPE | ALARM | Generate (in a |
| | | system-dependent |
| | | way) an alarm upon |
| | | any attempt to |
| | | perform, for the |
| | | file or directory, |
| | | any of the actions |
| | | specified in |
Noveck Expires 1 September 2024 [Page 18]
Internet-Draft Nfsv4 ACLs February 2024
| | | acemask4. |
+------------------------------+--------------+--------------------+
Table 1
The "Abbreviation" column denotes how the types will be referred to
throughout the rest of this document.
7. ACE Access Mask
The bitmask constants that might be used within 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, or are treated
differently when used with different types of object. For example,
ACE4_READ_DATA and ACE4_LIST_DIRECTORY designate the same mask bit
which is treated differently depeding on whether the object is a
directory or other type of object. Note that,
* The mask values ACE4_ADD_FILE, ACE4_ADD_SUBDIRECTORY, and
ACE4_DELETE_CHILD are intended to be used with directory objects
and are not supported when used with objects of other types.
* The mask value ACE4_APPEND_DATA is intended to be used with non-
directory objects.
Noveck Expires 1 September 2024 [Page 19]
Internet-Draft Nfsv4 ACLs February 2024
* The mask value used for ACE4_READ_DATA and ACE4_LIST_DIRECTORY
designate the same mask bit is which treated differently depeding
on whether the object is a directory or other type of object.
* The mask bit designated by ACE4_EXECUTE controls two different
sets of action depending on whether the underlying object is a
directory.
[Consensus Needed (Items #10Ba, #10Ca), through end of list]: These
mask bit are explained in more detail in the sections mentioned below
based on their relationshup to the three POSIX-derived permission
bits: Read, Write, and Execute. Changes include material in multiple
subsections of Section 7.
* Mask bits whose set of authorized actions corresponds to a single
POSIX-drived permission bit are explained in Section 7.2.1.
These mask bits are always supported although the set of
authorized is smaller when other mask bits covering a smaller set
of actions are supported.
* Mask bits whose set of authorized actions is a subset of those
normally controlled by a single POSIX-drived permission bit are
explained in Section 7.2.2.
These mask bits are not always supported, but depends on ACL
extensions supported by the server. For detailed guidance
regarding how the client can determine which mask bits are
supported, see Sections 4.2 and 4.3.
* Most Mask bits whose set of authorized actions is neither
identical to nor a subset of those controlled by a single POSIX-
drived permission bit are explained in Section 7.2.3.
This section covers mask bits for which we have found existing
implementations. These mask bits are not always supported, but
clients need to prepared for support actually present depending on
the set of ACL extensions supported
* Mask bits defined in existing specfication but for which no
corresponding imlementation has yet been found are explained in
Section 7.2.4.
[Consensus Needed (Item #5a) The descriptions in the section below
relevant to both authoriztion and for recognizing operations whose
success or failure are to be recorded when ACL are used for the non-
authorization functions described in Section 15. With regard to
Noveck Expires 1 September 2024 [Page 20]
Internet-Draft Nfsv4 ACLs February 2024
ACCESS whose returned bits are affected, it is not necessarily the
case that the occurrence of ACCESS in these lists implies that such
operations are recordable events.
Revisions in handling of the masks WRITE_RETENTION and
WRITE_RETENTION_HOLD. These are parts of consensus items #10.
7.1. Changes in Descriptions of Mask Bits
[Author Aside, Through end of section]: The material in this section
identiies changes it has been necessary to make in the description of
the ACE mask bits. It is ikely that it will be removed before the
successor document is published as an RFC
The following items should be noted as cases in which a change
related to the description of ACE mask bits. In soome cases, there
will be corresponding annotations near the actual text change,nut
this is not always the case. Nevertheless, there will need to be
consensus regarding the following changes:
* [Author Aside (Item #3a)]: Because the following sections have
been moved to be part of a general description of ACEs, not
limited to authorization, the descriptions no longer refer to
permissions but rather to actions. This coud be considered a
purely editorial change, but, to allow for possible disagreement
on the matter, it will be considered, here and in Appendix A, as
consensus item #3.
* [Author Aside (Item #4a)]: In a large number of places, SHOULD is
used inappropriately, since there appear to be no valid reasons to
allow a server to ignore what might well be a requirement. Such
changes are not always noted individually below. However, they
will be considered, here and in Appendix A, as part of consensus
item #4.
* [Author Aside (Item #5)}: In a significant number of cases the
ACCESS operation had not been listed as an operation affected by
the mask bit where logic suggests it needs to be. These
individuall additions are not noted individually below, although
there is, in each affected section, an annotation indicating that
section requires consensus on this point. In all cases, they will
be considered, here, in the affected sections and in Appendix A,
as part of consensus item #5.
When ACCESS is included as an affected operation, the description
identifies the returned bits that are to affected.
Noveck Expires 1 September 2024 [Page 21]
Internet-Draft Nfsv4 ACLs February 2024
When ACCESS is listed as affected, this is only with regard to
authorization. Non-authorization uses are discussed elsewhere, as
part of this consensus item.
* [Author Aside, Including entite bulleted item]: In a number of
cases, there are additional changes which go beyond editorial or
arguably do so. These will be marked as their own consensus items
usually with an accompanying author aside but without necessarily
citing the previous treatment. These include the following:
[Author Aside (Item #7a)]: Revisions were necessary to clarify the
relationship between READ_DATA and EXECUTE.
[Author Aside (Item #8a)]: Revisions were necessary to clarify the
relationship between WRITE_DATA and APPEND_DATA. These are part
of consensus item #8.
[Author Aside (Item #9a)]: Clarification of the handling of RENAME
by ADD_FILE, ADD_SUBDIRECTORY.
7.2. Role of Sticky Bit in ACL-based Auhorization
[Author Aside (Item #62a)]: Because of the need to address sticky-bit
issue as part of of the ACE mask descriptions, it is appropriate to
introduce the subject here.
[Author Aside (Item #20bA)]: 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 8.
[Consensus Item, Including List (Item #62a): The full description of
the role of the sticky-bit appears in Section 5.3.2 of
[I-D.dnoveck-nfsv4-security]. In evaluating and understanding the
relationship between the handling of this bit when NFSv4 ACLs are
used and when they are not, the following points need to be kept in
mind:
* This is troublesome in that it combines data normally assigned to
two different authorization models and breaks the overall
architectural arrangement in which the mask bits represent the
mode bits but provide a finer granularity of control.
Noveck Expires 1 September 2024 [Page 22]
Internet-Draft Nfsv4 ACLs February 2024
* It might have been possible to conform to the existing
architectural model if a new mask bit were created to represent
the directory sticky bit. It is probably too late to do so now,
even though it would be allowed, from the protocol point of view,
as an NFSv4.2 extension.
* The new treatment in Section 8 is more restrictive than the
previous one appearing in Section 8.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.2 of [I-D.dnoveck-nfsv4-security]. The reason for
doing so, is that, given the Unix orientation of the mode
attribute, it is likely that servers currently implement this,
even though there is no NFSv4 documentation of this semantics
This treatment needs to be checked for compatibility issues and
also to establish a model that we might adapt to the case of NFSv4
ACLs.
* In the long term, it would make more sense to allow the client
rather than the server to have the primary role in determining the
semantics for things like this. That does not seem possible right
now but it is worth considering.
7.2.1. Uses of Core Mask Bits
[Consensus Needed (Items #4b, #5a, #7a, #8a, #10Aa, #10Fa, #10Ga,
#10Ha), Throughout section]
ACE4_READ_DATA (for non-directory objects)
Operation(s) affected:
READ
[Consensus Needed (Item #10Aa)]: READLINK
OPEN (for read or read-write)
ACCESS (ACCESS4_READ)
Noveck Expires 1 September 2024 [Page 23]
Internet-Draft Nfsv4 ACLs February 2024
Discussion:
The action of reading the data of the file, or, in some cases,
providing necessary preparation to do so.
[Previous Treatment (Items #4b, #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 (Item #7a)]: The treatment needs to be clarified
to make it appropriate to all ACE types.
[Consensus Needed (Items #4b, #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 (for directories)
Operation(s) affected:
READDIR
ACCESS (ACCESS_READ)
Discussion:
The action of enumerating the contents of a directory, as
opposed to searching for a particlar name.
ACE4_WRITE_DATA (for non-directory objects)
Operation(s) affected:
WRITE
OPEN (for write or read-write)
ACCESS (ACCESS_MODIFY)
ACCESS (ACCESS_EXTEND)
- Only when ACE4_EXTEND_DATA in not supported.
ACCESS (ACCESS_DELETE)
- Only when ACE4_DELETE in not supported.
SETATTR of size (extension)
Noveck Expires 1 September 2024 [Page 24]
Internet-Draft Nfsv4 ACLs February 2024
- Only when ACE4_EXTEND_DATA in not supported.
SETATTR of size (truncation)
Discussion:
[Author Aside (Item #8a)]: 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. When ACE4_APPEND_DATA
is not supported, the action of extending a file's, data (e.g.
by a WRITE which extends EOF, is included as well
[Consensus Needed (Item #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 bits, in identical
fashion. The result of ACCESS will reflect the individal
authorizations to write existing bytea and to extend the file.
[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 bytes in the file,
whether the file is extended or not.
ACE4_WRITE_DATA (directories)
Operation(s) affected:
CREATE
- Will require ACE4_ADD_FILE, ACE4_ADD_SUBDIRECTORY, when
these are supported.
LINK
OPEN (which creates file in the directory)
ACCESS (ACCESS4_EXTEND)
REMOVE (may require ACE4_DELETE_CHIILD, when supported
RENAME (on the target drectory)
Noveck Expires 1 September 2024 [Page 25]
Internet-Draft Nfsv4 ACLs February 2024
Discussion:
Operations which modify a directory
Many of these operations may controlled at a finer granularity,
when the appropriate mask bits are supported.
ACE4_EXECUTE (for non-diectory objects)
Operation(s) affected:
READ
OPEN (for read or read-write)
ACCESS (ACCESS4_EXECUTE)
REMOVE
RENAME
LINK
CREATE
Discussion:
The action of reading a file in order to execute it.
Servers MUST allow a user the ability to read the data of the
file when only the ACE4_EXECUTE access mask bit is allowed.
This is because there is no way to execute a file without
reading the contents. Though a server may treat ACE4_EXECUTE
and ACE4_READ_DATA bits identically when deciding to permit a
READ or OPEN operation, it MUST still allow the two bits to be
set independently in NFSv4 ACLs, and distinguish between them
when replying to ACCESS operations. In particular, servers
MUST NOT silently turn on one of the two bits when the other is
set, as that would make it impossible for the client to
correctly enforce the distinction between read and execute
permissions.
As an example, following a SETATTR of the following NFSv4 ACL:
nfsuser:ACE4_EXECUTE:ALLOW
A subsequent GETATTR of acl attribute for that file will
return:
nfsuser:ACE4_EXECUTE:ALLOW
Noveck Expires 1 September 2024 [Page 26]
Internet-Draft Nfsv4 ACLs February 2024
and MUST NOT return:
nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW
ACE4_EXECUTE (for directories)
Operation(s) affected:
LOOKUP
ACCESS(ACCESS4_LOOKUP)
Discussion:
The action of traversing directory by searching for a
particular named item.
7.2.2. Uses of Finer-grained Mask Bits Derived from Write
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 is always affected and
RENAME is affected when a file/directory is moved betweewn
directories, with ACE4_ADD_SUBDIRECTORY covering the case when
a directory is renmed.
ACE4_APPEND_DATA
Operation(s) affected:
WRITE
ACCESS
OPEN
SETATTR of size
Noveck Expires 1 September 2024 [Page 27]
Internet-Draft Nfsv4 ACLs February 2024
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."
Noveck Expires 1 September 2024 [Page 28]
Internet-Draft Nfsv4 ACLs February 2024
[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_DELETE_CHILD
Operation(s) affected:
REMOVE
RENAME
Discussion:
The action of deleting a file or directory within a directory.
See Section 8 for information on now ACE4_DELETE and
ACE4_DELETE_CHILD are to interact.
ACE4_DELETE
Operation(s) affected:
REMOVE
Discussion:
The action of deleting the associated file or directory. See
Section 8 for information on how ACE4_DELETE and
ACE4_DELETE_CHILD are to interact.
7.2.3. Uses of Other Additional Mask Bits
The mask bits discussed in this section all authorize actions, that,
in the absence of support for that bit mask bit, are not resolved by
one of the three POSIX-derived permission bits.
Where these bits are not supported, the authorization decision will
be arrived at, in one of the ways listed below, with the specifics
prsented below as part of the discussion of that particular bit.
* The authorization can be controlled by file ownershiip.
* The authorization can be controlled by some boolean combination of
multiple permission bits
* The authorization can be controlled by some boolean combination
file ownership
Noveck Expires 1 September 2024 [Page 29]
Internet-Draft Nfsv4 ACLs February 2024
[Consensus Needed (Item #10Ba)]: The default authorization prsented
here is based on the only known implementtion of the speicfied bit.
Dacilties need to be discussed to allow the specific to be derived as
part of mask support discovery.
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_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.
Noveck Expires 1 September 2024 [Page 30]
Internet-Draft Nfsv4 ACLs February 2024
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.
7.2.4. Possible Uses of Additional Mask Bits
The mask bits discusssed in this section all have definitions in
exising specificsation, but, so far, no substantive support for them
has been found.
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
Noveck Expires 1 September 2024 [Page 31]
Internet-Draft Nfsv4 ACLs February 2024
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_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_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 need to be discussed.
Noveck Expires 1 September 2024 [Page 32]
Internet-Draft Nfsv4 ACLs February 2024
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 need to be discussed.
8. 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 8.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.
Noveck Expires 1 September 2024 [Page 33]
Internet-Draft Nfsv4 ACLs February 2024
[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.
8.1. Previous Handling of Deletion
[Author Aside]: This section contains the former content of
Section 8. All unannotated paragraphs within it are to be considered
the Previous Treatment associated with consensus item #12b.
[Author Aside, Including List]: Listed below are some of the reasons
that I have tried to replace the existing treatment rather than
address the specific issues mentioned here and in later asides.
* The fact that there is no clear message about what servers are to
do and about whether behavior clients might rely rely on. This
derives in turn from the use of "SHOULD" in contexts in which it
is clearly not appropriate, combined with non-normative reports of
what some systems do, and the statement that the approach
suggested is a way of providing "something like traditional UNIX-
like semantics".
* The complexity of the approach without any indication that there
is a need for such complexity makes me doubtful that anything was
actually implemented, especially since the text is so wishy-washy
about the need for server implementation. The probability that it
would be implemented so widely that clients might depend on it is
even more remote.
* The fact that how audit and alarm issues are to be dealt with is
not addressed at all.
* The fact that this treatment combines ACL data with mode bit
information in a confused way without any consideration of the
fact that the mode attribute is OPTIONAL.
Two access mask bits govern the ability to delete a directory entry:
ACE4_DELETE on the object itself (the "target") and ACE4_DELETE_CHILD
on the containing directory (the "parent").
Noveck Expires 1 September 2024 [Page 34]
Internet-Draft Nfsv4 ACLs February 2024
Many systems also take the "sticky bit" (MODE4_SVTX) on a directory
to allow unlink only to a user that owns either the target or the
parent; on some such systems the decision also depends on whether the
target is writable.
Servers SHOULD allow unlink if either ACE4_DELETE is permitted on the
target, or ACE4_DELETE_CHILD is permitted on the parent. (Note that
this is true even if the parent or target explicitly denies one of
these permissions.)
If the ACLs in question neither explicitly ALLOW nor DENY either of
the above, and if MODE4_SVTX is not set on the parent, then the
server SHOULD allow the removal if and only if ACE4_ADD_FILE is
permitted. In the case where MODE4_SVTX is set, the server may also
require the remover to own either the parent or the target, or may
require the target to be writable.
This allows servers to support something close to traditional UNIX-
like semantics, with ACE4_ADD_FILE taking the place of the write bit.
9. 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
Noveck Expires 1 September 2024 [Page 35]
Internet-Draft Nfsv4 ACLs February 2024
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 10. When a server which does
not support all the flags bits receives a request to set an NFSv4 ACL
containing an ACE with an unsupported flag bit set the server MUST
reject the request with NFS4ERR_ATTRNOTSUPP.
Consensus Needed (Item #13a)]: The case of servers which do not
provide support for particular flag combinations is to be treated
similarly. If a server supports a single "inherit ACE" flag that
applies to both files and directories, receives a request set an
NFSv4 ACL with ACE ACE4_FILE_INHERIT_ACE set but
ACE4_DIRECTORY_INHERIT_ACE not set, it MUST reject the request with
NFS4ERR_ATTRNOTSUPP.
10. Details Regarding ACE Flag Bits
ACE4_FILE_INHERIT_ACE
Any non-directory file in any sub-directory will get this ACE
inherited.
Noveck Expires 1 September 2024 [Page 36]
Internet-Draft Nfsv4 ACLs February 2024
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.
Noveck Expires 1 September 2024 [Page 37]
Internet-Draft Nfsv4 ACLs February 2024
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 11.
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.
11. 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
Noveck Expires 1 September 2024 [Page 38]
Internet-Draft Nfsv4 ACLs February 2024
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,
+===============+==============================================+
| Who | Description |
+===============+==============================================+
| OWNER | The owner of the file. |
+---------------+----------------------------------------------+
| GROUP | The group associated with the file. |
+---------------+----------------------------------------------+
| EVERYONE | [Previous treatment (Item #50a)]: The world, |
| | including the owner and owning group. |
| | |
| | [Consensus Needed (Item #50a)]: All |
| | requesters, including the owner, members of |
| | the owning group, and requests for which no |
| | user information is available. |
+---------------+----------------------------------------------+
| INTERACTIVE | Accessed from an interactive terminal. |
+---------------+----------------------------------------------+
| NETWORK | Accessed via the network. |
+---------------+----------------------------------------------+
| DIALUP | Accessed as a dialup user to the server. |
+---------------+----------------------------------------------+
| BATCH | Accessed from a batch job. |
+---------------+----------------------------------------------+
| ANONYMOUS | [Consensus Needed (Item #50a)]: Accessed |
| | without any authentication of the user |
| | principal. |
+---------------+----------------------------------------------+
| AUTHENTICATED | [Consensus Needed (Item #50a)]: Any |
| | authenticated user (opposite of ANONYMOUS). |
+---------------+----------------------------------------------+
| SERVICE | Accessed from a system service. |
+---------------+----------------------------------------------+
Table 2
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@.
Noveck Expires 1 September 2024 [Page 39]
Internet-Draft Nfsv4 ACLs February 2024
{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.
12. Automatic Inheritance Features
The acl attribute consists only of an array of ACEs, but the sacl
(Section 3.7) and dacl (Section 3.6) 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.
Noveck Expires 1 September 2024 [Page 40]
Internet-Draft Nfsv4 ACLs February 2024
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.
Noveck Expires 1 September 2024 [Page 41]
Internet-Draft Nfsv4 ACLs February 2024
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.
13. Processing Access Control Entries
To determine if a request succeeds, the server processes each nfsace4
entry of type ALLOW or DENY in turn as ordered in the array. Only
ACEs that have a "who" that matches the requester are considered. An
ACE is considered to match a given requester if at least one of the
following is true:
Noveck Expires 1 September 2024 [Page 42]
Internet-Draft Nfsv4 ACLs February 2024
* The "who' designates a specific user which is the user making the
request.
* The "who" specifies "OWNER@" and the user making the request is
the owner of the file.
* The "who" designates a specific group and the user making the
request is a member of that group.
* The "who" specifies "GROUP@" and the user making the request is a
member of the group owning the file.
* The "who" specifies "EVERYONE@".
* The "who" specifies "INTERACTIVE@", "NETWORK@", "DIALUP@",
"BATCH@", or "SERVICE@" and the requester, in the judgment of the
server, feels that designation appropriately describes the
requester.
* The "who" specifies "ANONYMOUS@" or "AUTHENTICATED@" and the
requestor's authentication status matches the who, using the
definitions in Section 11
Each ACE is processed until all of the bits of the requester's access
have been ALLOWED. Once a bit (see below) has been ALLOWED by an
ACCESS_ALLOWED_ACE, it is no longer considered in the processing of
later ACEs. If an ACCESS_DENIED_ACE is encountered where the
requester's access still has unALLOWED bits in common with the
"access_mask" of the ACE, the request is denied. When the ACL is
fully processed, if there are bits in the requester's mask that have
not been ALLOWED or DENIED, access is denied.
Unlike the ALLOW and DENY ACE types, the ALARM and AUDIT ACE types do
not affect a requester's access, and instead are for triggering
events as a result of a requester's access attempt. AUDIT and ALARM
ACEs are processed only after processing ALLOW and DENY ACEs if any
exist. This is necessary since the handling of AUDIT and ALARM ACEs
are affected by whether the access attempt is successful.
[Previous Treatment]: The NFSv4.1 ACL model is quite rich. Some
server platforms may provide access-control functionality that goes
beyond the UNIX-style mode attribute, but that is not as rich as the
NFS ACL model. So that users can take advantage of this more limited
functionality, the server may support the acl attributes by mapping
between its ACL model and the NFSv4.1 ACL model. Servers must ensure
that the ACL they actually store or enforce is at least as strict as
the NFSv4 ACL that was set. It is tempting to accomplish this by
rejecting any ACL that falls outside the small set that can be
Noveck Expires 1 September 2024 [Page 43]
Internet-Draft Nfsv4 ACLs February 2024
represented accurately. However, such an approach can render ACLs
unusable without special client-side knowledge of the server's
mapping, which defeats the purpose of having a common NFSv4 ACL
protocol. Therefore, servers should accept every ACL that they can
without compromising security. To help accomplish this, servers may
make a special exception, in the case of unsupported permission bits,
to the rule that bits not ALLOWED or DENIED by an ACL must be denied.
For example, a UNIX-style server might choose to silently allow read
attribute permissions even though an ACL does not explicitly allow
those permissions. (An ACL that explicitly denies permission to read
attributes should still be rejected.)
[Author Aside]: While the NFSv4.1 provides that many might not need
or use, it is the one that the working group adopted by the working
group, and I have to assume that alternatives, such as the withdrawn
POSIX ACL proposal were considered but not adopted. The phrase
"unsupported permission bits" with no definition of the bit whose
support might be dispensed with, implies that the server is free to
support whatever subset of these bits it chooses. As a result,
clients would not be able to rely on a functioning server
implementation of this OPTIONAL attribute. If there are specific
compatibility issues that make it necessary to allow non-support of
specific mask bits, then these need to be limited and the client
needs guidance about determining the set of unsupported mask bits.
[Previous Treatment]: The situation is complicated by the fact that a
server may have multiple modules that enforce ACLs. For example, the
enforcement for NFSv4.1 access may be different from, but not weaker
than, the enforcement for local access, and both may be different
from the enforcement for access through other protocols such as SMB
(Server Message Block). So it may be useful for a server to accept
an ACL even if not all of its modules are able to support it.
[Author Aside]: The following paragraph does not provide helpful
guidance and takes no account of the need of the the client to be
able to rely on the server implementing protocol-specifying semantics
and giving notice in those cases in which it is unable to so
[Previous Treatment]: The guiding principle with regard to NFSv4
access is that the server must not accept ACLs that appear to make
access to the file more restrictive than it really is.
14. Combining Authorization Models
Noveck Expires 1 September 2024 [Page 44]
Internet-Draft Nfsv4 ACLs February 2024
14.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 #63a.
The description in this section of changes to be made reflects the
author's proposal to address this issue and related issues. It might
have to be adjusted based on working group decisions.
As a result, in this document, we will have a single treatment of
this issue, in Sections 14.2 through 14.11. In addition, an
NFSv4.2-based extension related to attribute co-ordination will be
described in Section 14.12.
The current NFSv4.0 and NFSv4.1 descriptions of this co-ordination
share an unfortunate characteristic in that they are both written to
give server implementations a broad latitude in implementation
choices while neglecting entirely the need for clients and users to
have a reliable description of what servers are to do in this area.
As a result, one of the goals of this new combined treatment will be
to limit the uncertainty that the previous approach created for
clients, while still taking proper account of the possibility of
compatibility issues that a more tightly drawn specification might
give rise to.
The various ways in which these kinds of issues have been dealt with
are listed below together with a description of the needed changes
proposed to address each issue.
* In some cases, the term "MAY" is used in contexts where it is
inappropriate, since the allowed variation has the potential to
cause harm in that it leaves the client unsure exactly what
security-related action will be performed by the server.
Noveck Expires 1 September 2024 [Page 45]
Internet-Draft Nfsv4 ACLs February 2024
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 14.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", as described in Section 4.1 of
[I-D.dnoveck-nfsv4-security]. A discussion of the issues for
support of for these ACLs appears in Section 14.5.
[Author Aside]: Despite the statement, now cited in Section 14.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 14.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.
Noveck Expires 1 September 2024 [Page 46]
Internet-Draft Nfsv4 ACLs February 2024
* 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 14
and included subsections, which have no clear motivation, it is to
be assumed that the valid reasons to act contrary to the
recommendation given are the difficulty of changing
implementations based on previous analogous guidance, which may
have given the impression that the server was free to ignore the
guidance for any reason the implementer chose. This allows the
possibility of more individualized treatment of these instances
once compatibility issues have been adequately discussed.
[Author Aside]: In each subsection in which the the interpretation
of these term in the previous paragraph applies there will be an
explicit reference to Consensus Item #63, to draw attention to
this change, even in the absence of modified text.
14.2. Needed Attribute Coordination
On servers that support acl or dacl attributes, to gether with the
mode attribute, the server needs to keep the two attributes
consistent with one another. The value of the mode attribute (with
the exception of the high-order bits reserved for client use as
described in Section 5.3.2 of [I-D.dnoveck-nfsv4-security], 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
14.7 through 14.9 for detailed discussion.
[Previous Treatment (Item #63b)]: When a mode attribute is set on an
object, the ACL attributes may need to be modified in order to not
conflict with the new mode. In such cases, it is desirable that the
ACL keep as much information as possible. This includes information
about inheritance, AUDIT and ALARM ACEs, and permissions granted and
denied that do not conflict with the new mode.
Noveck Expires 1 September 2024 [Page 47]
Internet-Draft Nfsv4 ACLs February 2024
[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 14.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.
Noveck Expires 1 September 2024 [Page 48]
Internet-Draft Nfsv4 ACLs February 2024
{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 14.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 14.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 14.4.
{Consensus Needed (Item #26a)]: How other ACEs are dealt with when
setting mode is described in Section 14.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 14.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 14.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.
Noveck Expires 1 September 2024 [Page 49]
Internet-Draft Nfsv4 ACLs February 2024
[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 14.3 is
RECOMMENDED, it needs to be noted that the alternate approaches
discussed in Section 14.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 14.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.
14.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 14 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
Noveck Expires 1 September 2024 [Page 50]
Internet-Draft Nfsv4 ACLs February 2024
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 14.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.
Noveck Expires 1 September 2024 [Page 51]
Internet-Draft Nfsv4 ACLs February 2024
* 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 14.2 above.
14.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.
Noveck Expires 1 September 2024 [Page 52]
Internet-Draft Nfsv4 ACLs February 2024
[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 14.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 14.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 14.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 14.2 above.
[Consensus Needed, Including List (Item #27c)]: When the
recommendation to use Section 14.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.
Noveck Expires 1 September 2024 [Page 53]
Internet-Draft Nfsv4 ACLs February 2024
14.5. Handling of UNIX ACLs
[Author Aside]: All paragraphs in this section are consider part of
Consensus Item #63c.
Although the working group did not adopt the acls in the withdrawn
POSIX draft, their continued existence in UNIX contexts has created
protocol difficulties that need to be resolved. In many cases these
ACLS and their associated semantics are the basis for ACL support in
UNIX client APIs and in UNIX file systems supported by NFSv4
Although the semantic range of UNIX ACLs is a subset of that for
NFSv4 ACLs, expecting clients to perform that mapping on their own
has not worked well, leading to the following issues which will, at
some point, need to be addressed:
* There is a considerable uncertainty about the proper mapping from
ACLs to modes.
* The corresponding mapping from modes to ACLs is dealt with
different ways by different sections of the spec.
* These individual uncertainties are compounded since it is
difficult, in this environment, to ensure that these independently
chosen mappings are inverses of one another, as they are intended
to be.
Some possible approaches to these issues are discussed in
MAINSPEC(FUTURE-acl).
14.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.
14.7. Setting Mode and not ACL (overall)
14.7.1. Setting Mode and not ACL (vestigial)
[Author Aside]: All unannotated paragraphs are to be considered the
Previous treatment of Consensus Item #30b.
[Previous Treatment (Item #?a)]: When any of the nine low-order mode
bits are subject to change, either because the mode attribute was set
or because the mode_set_masked attribute was set and the mask
included one or more bits from the nine low-order mode bits, and no
Noveck Expires 1 September 2024 [Page 54]
Internet-Draft Nfsv4 ACLs February 2024
ACL attribute is explicitly set, the acl and dacl attributes must be
modified in accordance with the updated value of those bits. This
must happen even if the value of the low-order bits is the same after
the mode is set as before.
Note that any AUDIT or ALARM ACEs (hence any ACEs in the sacl
attribute) are unaffected by changes to the mode.
In cases in which the permissions bits are subject to change, the acl
and dacl attributes MUST be modified such that the mode computed via
the method in Section 14.3 yields the low-order nine bits (MODE4_R*,
MODE4_W*, MODE4_X*) of the mode attribute as modified by the
attribute change. The ACL attributes SHOULD also be modified such
that:
1. If MODE4_RGRP is not set, entities explicitly listed in the ACL
other than OWNER@ and EVERYONE@ SHOULD NOT be granted
ACE4_READ_DATA.
2. If MODE4_WGRP is not set, entities explicitly listed in the ACL
other than OWNER@ and EVERYONE@ SHOULD NOT be granted
ACE4_WRITE_DATA or ACE4_APPEND_DATA.
3. If MODE4_XGRP is not set, entities explicitly listed in the ACL
other than OWNER@ and EVERYONE@ SHOULD NOT be granted
ACE4_EXECUTE.
Access mask bits other than those listed above, appearing in ALLOW
ACEs, MAY also be disabled.
Note that ACEs with the flag ACE4_INHERIT_ONLY_ACE set do not affect
the permissions of the ACL itself, nor do ACEs of the type AUDIT and
ALARM. As such, it is desirable to leave these ACEs unmodified when
modifying the ACL attributes.
Also note that the requirement may be met by discarding the acl and
dacl, in favor of an ACL that represents the mode and only the mode.
This is permitted, but it is preferable for a server to preserve as
much of the ACL as possible without violating the above requirements.
Discarding the ACL makes it effectively impossible for a file created
with a mode attribute to inherit an ACL (see Section 14.11).
14.7.2. Setting Mode and not ACL (Discussion)
[Author Aside]: All unannotated paragraphs are to be considered
Author Asides relating to Consensus Item #30c.
Noveck Expires 1 September 2024 [Page 55]
Internet-Draft Nfsv4 ACLs February 2024
Existing documents are unclear about the changes to be made to an
existing ACL when the nine low-order bits of the mode attribute are
subject to modification using SETATTR.
A new treatment needs to apply to all minor versions. It will be
necessary to specify that, for all minor versions, setting of the
mode attribute, subjects the low-order nine bits to modification.
One important source of this lack of clarity is the following
paragraph from Section 14.7.1, which we refer to later as the
trivial-implementation-remark".
Also note that the requirement may be met by discarding the acl
and dacl, in favor of an ACL that represents the mode and only the
mode. This is permitted, but it is preferable for a server to
preserve as much of the ACL as possible without violating the
above requirements. Discarding the ACL makes it effectively
impossible for a file created with a mode attribute to inherit an
ACL (see Section 14.11).
The only "requirement" which might be met by the procedure mentioned
above is the text quoted below.
In cases in which the permissions bits are subject to change, the
acl and dacl attributes MUST be modified such that the mode
computed via the method in Section 14.3 yields the low-order nine
bits (MODE4_R*, MODE4_W*, MODE4_X*) of the mode attribute as
modified by the attribute change.
While it is true that this requirement could be met by the specified
treatment, this fact does not, in itself, affect the numerous
recommendations that appear between the above requirement and the
trivial-implementation-remark.
It may well be that there are are implementations that have treated
the trivial-implementation-remark as essentially allowing them to
essentially ignore all of those recommendations, resulting in a
situation in which were treated as if it were a trivial-
implementation-ok indication. How that issue will be dealt with in a
replacement for Section 14.7.1 will be affected by the working
group's examination of compatibility issues.
The following specific issues need to be addressed:
* Handling of inheritance.
Noveck Expires 1 September 2024 [Page 56]
Internet-Draft Nfsv4 ACLs February 2024
Beyond the possible issues that arise from the trivial-
implementation-ok interpretation, the treatment in Section 14.7.1,
by pointing specifically to existing INHERIT_ONLY ACEs obscures
the corresponding need to convert ACE's that specify both
inheritance and access permissions to be converted to INHERIT_ONLY
ACEs.
* Reverse-slope modes
* Named users and groups.
* The exact bounds of what within the ACL is covered by the low-
order bits of the mode.
It appears that for many of the issues, there are many possible
readings of the existing specs, leading to the possibility of
multiple inconsistent server behaviors. Furthermore, there are cases
in which none of the possible behaviors described in existing
specifications meets the needs.
As a result of these issues, the existing specifications do not
provide a reliable basis for client-side implementations of the ACL
feature which a Proposed Standard is normally expected to provide.
14.7.3. Setting Mode and not ACL (Proposed)
[Author Aside]: This proposed section is part of Consensus Item #30d
and all unannotated paragraphs within it are to be considered part of
that Item. Since the proposed text includes support for reverse-
slope modes, treats all minor versions together and assumes decisions
about handling of ACEs for named users and groups, the relevance of
consensus items #26, #28, and #29 needs to be noted.
[Author Aside]: As with all such Consensus Items, it is expected that
the eventual text in a published RFC might be substantially different
based on working group discussion of client and server needs and
possible compatibility issues. In this particular case, that
divergence can be expected to be larger, because the author was
forced to guess about compatibility issues and because earlier
material, on which it is based left such a wide range of matters to
the discretion of server implementers. It is the author's hope that,
as the working group discusses matters, sufficient attention is
placed on the need for client-side implementations to have reliable
information about expected server-side actions.
This section describes how ACLs are to be updated in response to
actual or potential changes in the mode attribute, when the
attributes needed by both of the file access authorization models are
Noveck Expires 1 September 2024 [Page 57]
Internet-Draft Nfsv4 ACLs February 2024
supported. It supersedes the discussions of the subject in [RFC7530]
and [RFC8881], each of which appeared in Section 6.4.1.1 of the
corresponding document.
It is necessary to approach the matter differently than in the past
because:
* Organizational changes are necessary to address all minor versions
together.
* Those previous discussions are often internally inconsistent
leaving it unclear what specification-mandated actions were being
specified..
* In many cases, servers were granted an extraordinary degree of
freedom to choose the action to take, either explicitly or via an
apparently unmotivated use of "SHOULD", leaving it unclear what
might be considered "valid" reasons to ignore the recommendation.
* There appears to have been no concern for the problems that
clients and applications might encounter dealing ACLs in such an
uncertain environment.
* Cases involving reverse-slope modes were not adequately addressed.
* The security-related effects of SVTX were not addressed.
While that sort of approach might have been workable at one time, it
made it difficult to devise client-side ACL implementations, even if
there had been any interest in doing so. In order to enable this
situation to eventually be rectified, we will define the preferred
implementation here, but in order to provide temporary compatibility
with existing implementations based on reasonable interpretations of
[RFC7530] [RFC8881]. To enable such compatibility the term "SHOULD"
will be used, with the understanding that valid reasons to bypass the
recommendation, are limited to implementers' previous reliance on
these earlier specifications and the difficulty of changing them now.
When the recommendation is bypassed in this way, it is necessary to
understand, that, until the divergence is rectified, or the client is
given a way to determine the detail of the server's non-standard
behavior, client-side implementations may find it difficult to
implement a client-side implementation that correctly interoperates
with the existing server.
Noveck Expires 1 September 2024 [Page 58]
Internet-Draft Nfsv4 ACLs February 2024
When mode bits involved in determining file access authorization are
subject to modification, the server MUST, when ACL-related attributes
have been set, modify the associated ACEs so as not to conflict with
the new value of the mode attribute.
The occasions to which this requirement applies, vary with the
attribute being set and the type of object being dealt with:
* For all minor versions, any change to the mode attribute, triggers
this requirement
* When the set_mode_masked attribute is being set on an object which
is not a directory, whether this requirement is triggered depends
on whether any of the nine low-order bits of the mode is included
in the mask.
* When the set_mode_masked attribute is being set on a directory,
whether this requirement is triggered depends on whether any of
the nine low-order bits of the mode or the SVTX bit is included in
the mask of bit whose values are to be set.
When the requirement is triggered, ACEs need to be updated to be
consistent with the new mode attribute. In the case of AUDIT and
ALARM ACEs, which are outside of file access authorization, no change
is to be made.
For ALLOW and DENY ACEs, changes are necessary to avoid conflicts
with the mode in a number of areas:
* The handling of ACEs that have consequences relating to ACL
inheritance.
* The handling of ACEs with a who-value of OWNER@, GROUP@, or
EVERYONE@ need to be adapted to the new mode.
* ACEs whose who-value is a named user or group, are to be retained
or not based on the mode being set as described below.
* ACEs whose who-value is one of the other special values defined in
Section 11 are to be left unmodified.
In order to deal with inheritance issues, the following SHOULD be
done:
* ACEs that specify inheritance-only need to be retained, regardless
of the value of who specified, since inheritance issues are
outside of the semantic range of the mode attribute.
Noveck Expires 1 September 2024 [Page 59]
Internet-Draft Nfsv4 ACLs February 2024
* ACEs that specify inheritance, in addition to allowing or denying
authorization for the current object need to be converted into
inheritance-only ACEs. This needs to occur irrespective of the
value of who appearing in the ACE.
For NFSv4 servers that support the dacl attribute, at least the first
of the above MUST be done.
Other ACEs are to be treated are classified based on the ACE's who-
value:
* ACEs whose who-value is OWNER@, GROUP@, or EVERYONE@ are referred
to as mode-directed ACEs and are subject to extensive
modification.
* ACEs whose who-value is a named user or group are either left
alone or subject to extensive modification, as described below.
* ACEs whose who-value is one of the other special values defined in
Section 11 are left as they are.
Mode-directed ACEs need to be modified so that they reflect the mode
being set.
In effecting this modification, the server will need to distinguish
mask bits deriving from mode attributes from those that have no such
connection. The former can be categorized as follows:
* For non-directory objects, the mask bits ACE4_READ_DATA (from the
read bit in the mode), ACE4_EXECUTE (from the execute bit in the
mode), and ACE4_WRITE_DATA together with ACE4_APPEND_DATA (from
the write bit in the mode) are all derived from the set of three
mode bits appropriate to the current who-value.
* For directories, analogous mask bits are included:
ACE4_LIST_DIRECTORY (from the read in the mode), ACE4_EXECUTE
(from the execute bit in the mode), and ACE4_ADD_FILE together
with ACE4_ADD_SUBDIRECTORY and ACE4_DELETE_CHILD> (from the write
bit in the mode) are all included based on the set of three mode
bits appropriate to the current who-value.
When the SVTX bit is set, ACE4_DELETE_CHILD is set, regardless of
the values of the low-order nine bit of the mode.
Noveck Expires 1 September 2024 [Page 60]
Internet-Draft Nfsv4 ACLs February 2024
* When named attributes are supported for the object whose mode is
subject to change, ACE4_READ_NAMED_ATTRIBUTES is set based on the
read bit and ACE4_WRITE_NAMED_ATTRIBUTES is set based on the write
bit based on the set of three mode bits appropriate to the current
who-value.
* In the case of OWNER@, ACE4_WRITE_ACL, ACE4_WRITE_ATTRIBUTES
ACE4_WRITE_ACL, ACE4_WRITE_OWNER are all set.
The union of these groups of mode bit are referred to as the mode-
relevant mask bits.
[Author Aside]: Except for the case of ACE4_SYNCHRONIZE, the handling
of mask bits which are not mode-relevant is yet to be clarified. For
tracking purposes, the handling of mask bits ACE4_READ_ATTRIBUTES,
ACE4_WRITE_RETENTION, ACE4_WRITE_RETENTION_HOLD, ACE4_READ_ACL will
be dealt with as Consensus Item #31.
If the mode is of forward-slope, then each set of three bits is
translated into a corresponding set of mode bits. Then, for each
ALLOW ACE with one of these who values, all mask bits in this class
are deleted and the computed mode bits for that who-value
substituted. For DENY ACEs, all mask bits in this class are reset,
and, if none remain, the ACE MAY be deleted.
In the case of reverse-slope modes, the following SHOULD be done:
* For mode-directed ACEs all mode-relevant mask bits are reset, and,
if none remain, the ACE MAY be deleted.
* Then, proceeding from owner to others, ALLOW ACEs are generated
based on the computed mode-relevant mask bits.
At each stage, if the mode-relevant mask bits for the current
stage includes mask bits not set for the previous stage, then a
DENY ACE needs to be added before the new ALLOW ACE. That ACE
will have a who-value based on the previous stage and a mask
consisting of the bit included in the current stage that were not
included in the previous stage.
In cases in which the above recommendation is not followed, the
server MUST follow a procedure which arrives at an ACL which behaves
identically for all cases involving forward-slope mode values.
When dealing with ACEs whose who-value is a named user or group, they
SHOULD be processed as follows:
* DENY ACEs are left as they are.
Noveck Expires 1 September 2024 [Page 61]
Internet-Draft Nfsv4 ACLs February 2024
* ALLOW ACES are subject to filtering to effect mode changes that
deny access to any principal other than the owner.
To determine the set of mode bits to which this filtering applies,
the mode bits for group are combined with those for others, to get
a set of three mode bits to determine which of the mode privileges
(read, write, execute) are denied to all principals other than the
owner, i.e. the set of bits not present in either the bits for
group or the bits for others.
Those three bits are converted to the corresponding set of mask
bits, according to the rules above.
All such mask bits are reset in the ACE, and, if none remain, the
ACE MAY be deleted.
In cases in which the above recommendation is not followed, the
server MUST follow a procedure which arrives at an ACL which behaves
identically for all cases involving forward-slope mode values. This
would be accomplished if the mask bits were reset based on the group
bits alone, as had been recommended in earlier specifications.
14.8. Setting ACL and Not Mode
[Author Aside]: The handling of SHOULD in this section is considered
as part of Consensus Item #63d.
When setting the acl or dacl and not setting the mode or
mode_set_masked attributes, the permission bits of the mode need to
be derived from the ACL. In this case, the ACL attribute SHOULD be
set as given. The nine low-order bits of the mode attribute
(MODE4_R*, MODE4_W*, MODE4_X*) MUST be modified to match the result
of the method in Section 14.3. The three high-order bits of the mode
(MODE4_SUID, MODE4_SGID, MODE4_SVTX) SHOULD remain unchanged.
14.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 14.8.
14.10. Retrieving the Mode and/or ACL Attributes
[Author Aside]: The handling of SHOULD in this section is considered
as part of Consensus Item #63e.
Noveck Expires 1 September 2024 [Page 62]
Internet-Draft Nfsv4 ACLs February 2024
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 14.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 14.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 14.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 14.3, with the
Noveck Expires 1 September 2024 [Page 63]
Internet-Draft Nfsv4 ACLs February 2024
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.
14.11. Use of Inherited ACL When Creating Objects
[Author Aside]: The handling of SHOULD in this section is considered
as part of Consensus Item #63f.
If the object being created is not a directory, the inherited ACL
SHOULD NOT inherit ACEs from the parent directory ACL unless the
ACE4_FILE_INHERIT_ACE flag is set.
If the object being created is a directory, the inherited ACL is to
inherit all inheritable ACEs from the parent directory, that is,
those that have the ACE4_FILE_INHERIT_ACE or
ACE4_DIRECTORY_INHERIT_ACE flag set. If the inheritable ACE has
ACE4_FILE_INHERIT_ACE set but ACE4_DIRECTORY_INHERIT_ACE is clear,
the inherited ACE on the newly created directory MUST have the
ACE4_INHERIT_ONLY_ACE flag set to prevent the directory from being
affected by ACEs meant for non-directories.
When a new directory is created, the server MAY split any inherited
ACE that is both inheritable and effective (in other words, that has
neither ACE4_INHERIT_ONLY_ACE nor ACE4_NO_PROPAGATE_INHERIT_ACE set),
into two ACEs, one with no inheritance flags and one with
ACE4_INHERIT_ONLY_ACE set. (In the case of a dacl or sacl attribute,
both of those ACEs SHOULD also have the ACE4_INHERITED_ACE flag set.)
This makes it simpler to modify the effective permissions on the
directory without modifying the ACE that is to be inherited to the
new directory's children.
14.12. Combined Authorization Models for NFSv4.2
The NFSv4 server implementation requirements described in the
subsections above apply to NFSv4.2 as well and NFSv4.2 clients can
assume that the server follows them.
NFSv4.2 contains an OPTIONAL extension, defined in [RFC8257], which
is intended to reduce the interference of modes, restricted by the
umask mechanism, with the acl inheritance mechanism. The extension
allows the client to specify the umask separately from the mask
attribute.
Noveck Expires 1 September 2024 [Page 64]
Internet-Draft Nfsv4 ACLs February 2024
15. Other Uses of Access Control Lists
Whether the acl or sacl attributes are used, AUDIT and ALARM ACEs
provide security-related facilities separate from the the file access
authorization provided by ALLOW and DENY ACEs
* AUDIT ACEs provide a means to audit attempts to access a specified
file by specified sets of principals.
* ALARM ACEs provide a means to draw special attention to attempts
to access specified files by specified sets of principals.
16. Security Considerations
There are no Security considerations specific to this document.
Security considerations for NFSv4 as a whole are dealt with in the
Security Considerations section of [I-D.dnoveck-nfsv4-security].
17. IANA Considerations
This document requires no actions from IANA>
18. References
18.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
March 2015, <https://www.rfc-editor.org/info/rfc7530>.
[RFC8881] Noveck, D., Ed. and C. Lever, "Network File System (NFS)
Version 4 Minor Version 1 Protocol", RFC 8881,
DOI 10.17487/RFC8881, August 2020,
<https://www.rfc-editor.org/info/rfc8881>.
Noveck Expires 1 September 2024 [Page 65]
Internet-Draft Nfsv4 ACLs February 2024
[I-D.dnoveck-nfsv4-security]
Noveck, D., "Security for the NFSv4 Protocols", Work in
Progress, Internet-Draft, draft-dnoveck-nfsv4-security-07,
14 November 2023, <https://datatracker.ietf.org/doc/html/
draft-dnoveck-nfsv4-security-07>.
18.2. Informative References
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
and G. Judd, "Data Center TCP (DCTCP): TCP Congestion
Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257,
October 2017, <https://www.rfc-editor.org/info/rfc8257>.
Appendix A. Issues for which Consensus Needs to be Ascertained
This section helps to keep track of specific changes which the author
has made or intends to make to deal with issues found in RFCs 7530
and 8881. The changes listed here exclude those which are clearly
editorial but includes some that the author believes are editorial
but for which the issues are sufficiently complicated that working
group consensus on the issue is probably necessary.
These changes are presented in the table below, organized into a set
of "Consensus Items" identified by the numeric code appearing in
annotations in the proposed document text. For each such item, a
type code is assigned with separate sets of code define for pending
items and for those which are no longer pending.
The following codes are defined for pending consensus items:
* "NM" denotes a change which is new material that is not purely
editorial and thus requires Working Group consensus for eventual
publication.
* "BE" denotes a change which the author believes is editorial but
for which the change is sufficiently complex that the judgment is
best confirmed by the Working Group.
* "BC" denotes a change which is a substantive change that the
author believes is correct. This does not exclude the possibility
of compatibility issues becoming an issue but is used to indicate
that the author believes any such issues are unlikely to prevent
its eventual acceptance.
Noveck Expires 1 September 2024 [Page 66]
Internet-Draft Nfsv4 ACLs February 2024
* "CI" denotes a change for which the potential for compatibility
issues is a major concern with the expected result that working
group discussion of change will focus on clarifying our knowledge
of how existing clients and server deal with the issue and how
they might be affected by the change or the change modified to
accommodate them.
* "NS" denotes a change which represents the author's best effort to
resolve a difficulty but for which the author is not yet confident
that it will be adopted in its present form, principally because
of the possibility of troublesome compatibility issues.
* "NE" denotes change based on an existing issue in the spec but for
which the replacement text is incomplete and needs further
elaboration.
* "WI" denotes a potential change based on an existing issue in the
spec but for which replacement text is not yet available because
further working group input is necessary before drafting. It is
expected that replacement text will be available in a later draft
once that discussion is done.
* "LD" denotes a potential change based on an existing issue in the
spec but for which replacement text is not yet available due to
the press of time. It is expected that replacement text will be
available in a later draft.
* "EV" denote a potential change which is tentative or incomplete
because further details need to be provide or because the author
is unsure that he has a correct explanation of the issue. It is
expected that replacement text will be available in a later draft.
The following codes are defined for consensus items which are no
longer pending.
* "RT" designates a former item which has been retired, because it
has been merged with another one or otherwise organized out of
existence.
Such items no longer are referred to the document source although
the item id is never reassigned. They are no longer counted among
the set of total items.
* "CA" designates a former item for which consensus has been
achieved in the judgment of the author, although not by any
official process.
Noveck Expires 1 September 2024 [Page 67]
Internet-Draft Nfsv4 ACLs February 2024
Items reaching this state are effected in the document source
including the deletion of annotations and the elimination of
obsoleted previous treatments.
Items in this state are still counted among the total of item but
are no longer considered pending
* "CV" designates a former item for which consensus has been
achieved and officially verified.
Even though the author is a Working Group co-chair,it is probably
best if he is not involved in this process and intends to leave it
to the other co-chairs, the Document Shepherd and the Area
Director.
Items in this state are not counted among the item totals. They
may be kept in the table but only to indicate that the item id is
still reserved.
* "DR" designates a former item which has been dropped, because it
appears that working group acceptance of it, even with some
modification, is unlikely.
Such items no longer are referred to the document source although
the item id is never reassigned. They are no longer counted among
the set of total items.
When asterisk is appended to a state of "NM", "BC" or "BE" it that
there has been adequate working group discussion leading one to
reasonably expect it will be adopted, without major change, in a
subsequent document revision.
Such general acceptance is not equivalent to a formal working group
consensus and it not expected to result in major changes to the draft
document,
On the other hand, once there is a working group consensus with
regard to a particular issue, the document will be modified to remove
associated annotations, with the previously conditional text
appearing just as other document text does. The issue will remain in
this table as a non-pending item. It will be mentioned in Appendix A
of [I-D.dnoveck-nfsv4-security], to summarize the changes that have
been made.
It is to be expected that these designations will change as
discussion proceeds and new document versions are published. It is
hoped that most such shifts will be upward in the above list or
result in the deletion of a pending item, by reaching a consensus to
Noveck Expires 1 September 2024 [Page 68]
Internet-Draft Nfsv4 ACLs February 2024
accept or reject it. This would enable, once all items are dealt
with, an eventual request for publication as an RFC, with this
appendix having been deleted.
The consensus item in the followig table can be divided into three
groups, based on the ssociated numeric id.
* Those with ids less than 62 were created as part of the security
and transferred to this on as part of the doument split.
* Those with ids between 62 and 65 are the result of splitting item
created as part of the security that now adress issues in bo both
documents
* Those with id 100 and aboved were created after the document
split. In most case, there is no connection to material within
the security document.
+===+====+==================+=======================================+
|# |Type| ...References... | Substance |
+===+====+==================+=======================================+
|3 |BE | #3a in S 7 | Conversion of mask bit descriptions |
| | | | from being about "permissions" to |
| | | | being about the action permitted, |
| | | | denied, or specified as being |
| | | | audited or generating alarms. |
+---+----+------------------+---------------------------------------+
|4 |CI | #4a in S 7 | Elimination of uses of SHOULD |
| | | | believed inappropriate in Section 7. |
+---+----+------------------+---------------------------------------+
|5 |NI | #5a in S 7 | Changes needes in treatment of |
| | | | ACCESS, including the following: |
| | | #5b in S 7.1 | |
| | | | * ACCESS is listed as an operation |
| | | | in all cases in which one of the |
| | | | bits returned by the operation |
| | | | ould be affected. |
| | | | |
| | | | * There is now explcit indication |
| | | | of which bit(s) returned by |
| | | | ACCESS might be affected. |
| | | | |
| | | | * There is now a discussion of |
| | | | differences between the effect on |
| | | | authorization and that on other |
| | | | uses of the associated mask biks |
| | | | for ACEs not conncted with |
| | | | authorization. |
Noveck Expires 1 September 2024 [Page 69]
Internet-Draft Nfsv4 ACLs February 2024
| | | | |
| | | | Given the inability of the server |
| | | | to determine which bits are being |
| | | | tested by the client, determiing |
| | | | when success or failure has |
| | | | occurred is impossible. As a |
| | | | result it appears best to given |
| | | | the server freedom, in any |
| | | | particular case, to decide |
| | | | whether ACCESS constitutes a |
| | | | recordable evenr |
| | | | |
+---+----+------------------+---------------------------------------+
|14 |BC | #14a in S 3 | Explicit discussion of the case in |
| | | | which aclsupport is not supported. |
| | | #14b in S 3.4 | |
+---+----+------------------+---------------------------------------+
|15 |BC | #15a in S 3.4 | Handling of the proper relationship |
| | | | between support for ALLOW and DENY |
| | | | ACEs. |
+---+----+------------------+---------------------------------------+
|16 |NM | #16a in S 3.3 | Discussion of coherence of acl, |
| | | | sacl, and dacl attributes. |
+---+----+------------------+---------------------------------------+
|62 |NI | #62a in S 7.2 | New/revised description of the role |
| | | | of the "sticky bit" for directories, |
| | | | with respect to ACL/ACE handling. |
| | | | |
| | | | Needs to be considered together with |
| | | | Item #6 in the security document |
| | | | proper. |
+---+----+------------------+---------------------------------------+
|63 |CI | #63a in S 14.1 | Revised description of co-ordination |
| | | | of acl and mode attributes to apply |
| | | #63b in S 14.2 | to NFSv4 as a whole. While this |
| | | | includes many aspects of the shift |
| | | #63c in S 14.5 | to be more specific about the co- |
| | | | ordination requirements including |
| | | #63d in S 14.8 | addressing apparently unmotivated |
| | | | uses of the terms "SHOULD" and |
| | | #63e in S 14.10 | "SHOULD NOT", it excludes some |
| | | | arguably related matters dealt with |
| | | #63f in S 14.11 | as Consensus Items #26 and #27. |
| | | | |
| | | | Needs to be considered together with |
| | | | Item #25 in the security document |
| | | | proper. |
+---+----+------------------+---------------------------------------+
Noveck Expires 1 September 2024 [Page 70]
Internet-Draft Nfsv4 ACLs February 2024
|64 |WI | #64a in S 14.5 | Discussion of issues related to the |
| | | | handling of allowed variants of the |
| | | | NFSv4 ACL model, including subsets |
| | | | based on the Unix ACL model. |
| | | | |
| | | | Needs to be considered together with |
| | | | Item #56 in the security document |
| | | | proper. |
+---+----+------------------+---------------------------------------+
|65 |NS | #65a 3.3 | Designation of the acl, dacl, and |
| | | | sacl attributes as Experimental, |
| | | #65b 3.6 | even though still formally OPTIONAL. |
| | | | |
| | | #65c 3.7 | Note that this is separate from the |
| | | | possibility of sufficiently |
| | | | clarifying the description of the |
| | | | acl, dacl, and sacl attributes to |
| | | | make the Experimental designation |
| | | | unnecessary, which will be covered |
| | | | as Item #XX. |
| | | | |
| | | | Needs to be considered together with |
| | | | Item #58 in the security document |
| | | | proper. |
+---+----+------------------+---------------------------------------+
|100|NI | | Needs to be considered together with |
| | | | Item #66 in the security document |
| | | | wich deal with parallel issues |
| | | | regarding POSIX-based authorization. |
| | | | |
| | | | Address issues regarding |
| | | | ACE4_{READ,WRITE}_NAMED_ATTRIBUTES. |
+---+----+------------------+---------------------------------------+
|10A|NM | #10Aa in S 7.2.1 | Inclusion of the action of READLINK |
| | | | as authorized by ACE4_READ_DATA |
+---+----+------------------+---------------------------------------+
|10B|BC | #10Ba in S 7 | Specification of one set of mask |
| | | | bits as always supported. |
+---+----+------------------+---------------------------------------+
|10C|NM | #10Ca in S 7 | Classification of masks bits based |
| | | | on relationship to permission bits |
| | | | and existence of implementations. |
+---+----+------------------+---------------------------------------+
|10D|NI | #10Da in S 1.2 | Presentation of UNIX ACLs as the |
| | | | basis of the feature, rather than |
| | | | the possibly aspirational NFSv4 ACLs |
| | | | |
| | | | Includes work to mention of |
Noveck Expires 1 September 2024 [Page 71]
Internet-Draft Nfsv4 ACLs February 2024
| | | | Extension features that were never |
| | | | implemented, where the WG agrees |
+---+----+------------------+---------------------------------------+
|10E|NI | #10Ea in S 1.2 | Support for discovety of ACL |
| | | | extensions using the Aclfeature |
| | | | attribute or inference rules, to |
| | | | help in those case in which it is |
| | | | not supported. |
+---+----+------------------+---------------------------------------+
|10F|BC | | More detail about cases in which |
| | | | OPEN is affected by ACE mask bits, |
| | | | including the dependence on the type |
| | | | of OPEN. |
+---+----+------------------+---------------------------------------+
|10G|BC | | More detail about use of |
| | | | ACE4_WRITE_DATA and the dependence |
| | | | on the support for finer-grained |
| | | | bits in descriptions of ACE mask |
| | | | bits. |
+---+----+------------------+---------------------------------------+
|10H|BC | | Distinguish mask bit treatments |
| | | | depending on the type of the objects |
+---+----+------------------+---------------------------------------+
|10I|BC | | More detail about cases in which |
| | | | RENAME is affected by ACE mask bits |
| | | | including the dependence on the |
| | | | directories for wich the mask bits, |
| | | | distinguising the within-directory |
| | | | and cross-directory cases, and |
| | | | dealing appropiately with the |
| | | | rename-over case. |
+---+----+------------------+---------------------------------------+
|20B|NI | | Needs to be considered together with |
| | | | Item #6 in the security document |
| | | | wich deal with parallel issues |
| | | | regarding POSIX-based authorization. |
| | | | |
| | | | New/revised description of the role |
| | | | of the "sticky bit" for directories, |
| | | | with respect to ACL handling. |
+---+----+------------------+---------------------------------------+
Table 3
Noveck Expires 1 September 2024 [Page 72]
Internet-Draft Nfsv4 ACLs February 2024
The following table summarizes the issues in each particular pending
state, dividing them into those associated with the motivating
changes for this new document and those that derive from other
issues, that were uncovered later, once work on a new treatment of
NFSv4 security had begun.
+========+=====+============================+
| Type | Cnt | Issues |
+========+=====+============================+
| BC(M) | 1 | 32 |
+--------+-----+----------------------------+
| CI(M) | 5 | 36, 38, 39, 40, 41 |
+--------+-----+----------------------------+
| WI(M) | 1 | 47 |
+--------+-----+----------------------------+
| NE(M) | 1 | 35 |
+--------+-----+----------------------------+
| EV(M) | 3 | 53, 54, 55 |
+--------+-----+----------------------------+
| All(M) | 11 | As listed above. |
+--------+-----+----------------------------+
| NM(O) | 1 | 16 |
+--------+-----+----------------------------+
| NS(O) | 1 | 52 |
+--------+-----+----------------------------+
| BE(O) | 4 | 3, 5, 7, 24 |
+--------+-----+----------------------------+
| BC(O) | 14 | 9, 10, 12, 13, 14, 15, 17, |
| | | 18, 21, 22, 23, 29, 50, 51 |
+--------+-----+----------------------------+
| CI(O) | 10 | 4, 6, 8, 11, 19, 25, 26, |
| | | 27, 30, 37 |
+--------+-----+----------------------------+
| WI(O) | 4 | 20, 28, 31, 56 |
+--------+-----+----------------------------+
| All(O) | 34 | As described above |
+--------+-----+----------------------------+
| *All* | 45 | Grand total for above |
| | | table. |
+--------+-----+----------------------------+
Table 4
The following table summarizes the issues in each particular non-
pending state, dividing them into those associated with the
motivating changes for this new document and those that derive from
other issues, that were uncovered later, once work on a new treatment
of NFSv4 security had begun.
Noveck Expires 1 September 2024 [Page 73]
Internet-Draft Nfsv4 ACLs February 2024
+========+=====+==============================+
| Type | Cnt | Issues |
+========+=====+==============================+
| CA(M) | 2 | 1, 2 |
+--------+-----+------------------------------+
| RT(M) | 5 | 42, 43, 44, 45, 46 |
+--------+-----+------------------------------+
| RJ(M) | 4 | 33, 34, 48, 49 |
+--------+-----+------------------------------+
| All(M) | 11 | As listed above. |
+--------+-----+------------------------------+
| All(O) | 0 | Nothing yet. |
+--------+-----+------------------------------+
| *All* | 11 | Grand total for above table. |
+--------+-----+------------------------------+
Table 5
Acknowledgments
The author wishes to thank Tom Haynes for his helpful suggestion to
deal with security for all NFSv4 minor versions in the same document.
The author wishes to draw people's attention to Nico Williams' remark
that NFSv4 security was not so bad, except that there was no
provision for authentication of the client peer. This perceptive
remark, which now seems like common sense, did not seem so when made,
but it has served as a beacon for those working on putting NFSv4
security on a firmer footing. We appreciate Nico's perceptive
guidance.
The author wishes to thank Bruce Fields for his helpful comments
regarding ACL support which had a major role in the evolution of this
document.
The author wishes to acknowledge the important role of the authors of
RPC-with-TLS, Chuck Lever and Trond Myklebust, in moving the NFS
security agenda forward and thank them for all their efforts to
improve NFS security.
The author wishes to thank Chuck Lever for his many helpful comments
about nfsv4 security issues, his explanation of many unclear points,
and much important guidance he provided that is reflected in this
document, including his work to streamline the security negotiation
process by the definition of new pseudo-flavors.
Noveck Expires 1 September 2024 [Page 74]
Internet-Draft Nfsv4 ACLs February 2024
The author wishes to thank Rick Macklem for his help in resolving
NFSv4 security issues. These include clarifying possible server
policies regarding RPC-with-TLS, helping to clarify "owner-override
semantics" and bringing to the Working Group's attention the
possibility of deriving limited principal identification from client
peer authentication while still staying within the boundaries of RPC-
with-TLS.
Author's Address
David Noveck (editor)
NetApp
201 Jones Road, Suite 16
Waltham, MA 02451
United States of America
Phone: +1-781-572-8038
Email: davenoveck@gmail.com
Noveck Expires 1 September 2024 [Page 75]