ACLs within the NFSv4 Protocols
draft-dnoveck-nfsv4-acls-01
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | David Noveck | ||
| Last updated | 2024-04-26 | ||
| 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-01
NFSv4 D. Noveck, Ed.
Internet-Draft NetApp
Updates: 8881, 7530 (if approved) 26 April 2024
Intended status: Standards Track
Expires: 28 October 2024
ACLs within the NFSv4 Protocols
draft-dnoveck-nfsv4-acls-01
Abstract
This document describes the structure of NFSv4 ACLs and their role in
the NFSv4 security architecture. While the focus of this document is
on the role of ACLs in providing a more flexible approach to file
access authorization than is made available by the POSIX-derived
authorization-related attributes, the potential provision of other
security-related functionality is covered as well.
While the goals of the description are similar to that used in
previous specifications, the approach taken is substantally
different, in that the relationship of the multiple ACL models
supported has changed. A core set of functionality, derived form the
the now-withdrawn POSIX draft ACLs is presented as the conceptual
base of the feature set. Additional features used to provide the
functionality within the NFSv4 ACL model are presented as OPTIONAL
extensions to that core.
The current version of the document is intended, in large part, to
result in working group discussion regarding repairing problems with
previous specifications of ACL-related features and to enable work to
provide a greater degree of interoperability than has been available
heretofore. The drafts a framework for addressing these issues and
obtaining working group consensus regarding necessary changes.
When the resulting document is eventually published as an RFC, it
will supersede the descriptions of ACL structure and semantics
appearing in existing minor version specification documents for
NFSv4.0 and NFSv4.1, thereby updating RFC7530 and RFC8881.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Noveck Expires 28 October 2024 [Page 1]
Internet-Draft Nfsv4 ACLs April 2024
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/.
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 28 October 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 . . . . . . 5
1.2. Dealing with the Previous Uncertinty regading ACL
Semantics . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Changes to the Description of ACLs in this Document . . . 9
1.3.1. New ACL Description Framework . . . . . . . . . . . . 10
1.3.2. Providing Implementation Information to the Client . 11
1.3.3. Limiting Implementation Choices . . . . . . . . . . . 11
Noveck Expires 28 October 2024 [Page 2]
Internet-Draft Nfsv4 ACLs April 2024
1.3.4. ACLs in various Minor Versions . . . . . . . . . . . 13
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 15
2.1. Keyword Definitions . . . . . . . . . . . . . . . . . . . 15
2.2. Special Considerations . . . . . . . . . . . . . . . . . 15
2.3. Use of the Term "SHOULD . . . . . . . . . . . . . . . . . 16
3. ACL-based Authorization-related Attributes . . . . . . . . . 18
3.1. Definition to Support ACL-related attributes . . . . . . 18
3.2. Table of ACL-related Attributes . . . . . . . . . . . . . 18
3.3. Types of ACLs . . . . . . . . . . . . . . . . . . . . . . 19
3.4. The Acl Attribute (v4.0) . . . . . . . . . . . . . . . . 21
3.5. The Aclsupport Attribute (v4.0) . . . . . . . . . . . . . 23
3.6. The Aclfeature Attribute (v4.2 extension) . . . . . . . . 24
3.7. The Dacl Attribute (v4.1) . . . . . . . . . . . . . . . . 26
3.8. The Sacl Attribute (v4.1) . . . . . . . . . . . . . . . . 26
4. Structure and Function of NFSv4 Access Control Lists . . . . 27
4.1. Need to More Clearly Address ACL Semantics Choices . . . 28
4.2. ACL Semantics Choices . . . . . . . . . . . . . . . . . . 33
4.3. Discovery of ACL Semantics . . . . . . . . . . . . . . . 35
4.4. Inferring ACL Semantics . . . . . . . . . . . . . . . . . 37
5. Structure of Access Control Entries . . . . . . . . . . . . . 39
5.1. ACE Type . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.1. Existing ACE Types . . . . . . . . . . . . . . . . . 39
5.1.2. ACE Type Support Discovery . . . . . . . . . . . . . 41
5.1.3. ACE Type Extensiion . . . . . . . . . . . . . . . . . 42
5.2. ACE Access Mask . . . . . . . . . . . . . . . . . . . . . 43
5.2.1. Changes in Descriptions of Mask Bits . . . . . . . . 45
5.2.2. Role of Sticky Bit in ACL-based Auhorization . . . . 47
5.2.3. Uses of Core Mask Bits . . . . . . . . . . . . . . . 48
5.2.4. Uses of Finer-grained Mask Bits Derived from Write . 53
5.2.5. Uses of Other Additional Mask Bits . . . . . . . . . 57
5.2.6. Possible Uses of Additional Mask Bits . . . . . . . . 60
5.2.7. ACE Mask Support Discovery . . . . . . . . . . . . . 63
5.2.8. ACE Mask Bit Support Inference . . . . . . . . . . . 70
5.2.9. ACE Mask Bit Extension . . . . . . . . . . . . . . . 72
5.2.10. Handling of Deletion . . . . . . . . . . . . . . . . 72
5.2.11. Handling of Deletion (Vestigial) . . . . . . . . . . 73
5.3. ACE flag bits . . . . . . . . . . . . . . . . . . . . . . 74
5.3.1. Details Regarding ACE Flag Bits . . . . . . . . . . . 76
5.3.2. ACE Flag Support Discovery . . . . . . . . . . . . . 78
5.3.3. ACE Flag Extension . . . . . . . . . . . . . . . . . 81
5.4. ACE Who . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.4.1. ACE Who Value Support Discovery . . . . . . . . . . . 85
5.4.2. ACE Who Value Extensiion . . . . . . . . . . . . . . 87
6. Automatic Inheritance Features . . . . . . . . . . . . . . . 88
7. Processing Access Control Entries . . . . . . . . . . . . . . 90
8. Combining Authorization Models . . . . . . . . . . . . . . . 92
8.1. Background for Combined Authorization Model . . . . . . . 93
8.2. Needed Attribute Coordination . . . . . . . . . . . . . . 95
Noveck Expires 28 October 2024 [Page 3]
Internet-Draft Nfsv4 ACLs April 2024
8.3. Computing a Mode Attribute from an ACL . . . . . . . . . 98
8.4. Alternatives in Computing Mode Bits . . . . . . . . . . . 100
8.5. Handling of UNIX ACLs . . . . . . . . . . . . . . . . . . 101
8.6. Setting Multiple ACL Attributes . . . . . . . . . . . . . 102
8.7. Setting Mode and not ACL (overall) . . . . . . . . . . . 102
8.7.1. Setting Mode and not ACL (vestigial) . . . . . . . . 102
8.7.2. Setting Mode and not ACL (Discussion) . . . . . . . . 103
8.7.3. Setting Mode and not ACL (Proposed) . . . . . . . . . 105
8.7.4. Setting Mode and not ACL in the Unix ACL Case
(Proposed) . . . . . . . . . . . . . . . . . . . . . 111
8.7.5. Setting Mode and not ACL in the NFSv4 ACL Case
(Proposed) . . . . . . . . . . . . . . . . . . . . . 113
8.7.6. Setting Mode and not ACL in Certain Hybrid ACL Cases
(Proposed) . . . . . . . . . . . . . . . . . . . . . 114
8.8. Setting ACL and Not Mode . . . . . . . . . . . . . . . . 115
8.9. Setting Both ACL and Mode . . . . . . . . . . . . . . . . 115
8.10. Retrieving the Mode and/or ACL Attributes . . . . . . . . 115
8.11. Use of Inherited ACL When Creating Objects . . . . . . . 117
8.12. Combined Authorization Models for NFSv4.2 . . . . . . . . 117
9. Other Uses of Access Control Lists . . . . . . . . . . . . . 118
10. XDR to Support an NFSv4.2 Aclfeature Extension . . . . . . . 118
10.1. Extraction of XDR . . . . . . . . . . . . . . . . . . . 118
10.2. Code Components Licensing Notice . . . . . . . . . . . . 119
10.3. XDR For Aclfeature Extesion . . . . . . . . . . . . . . 120
11. Security Considerations . . . . . . . . . . . . . . . . . . . 124
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 125
13.1. Normative References . . . . . . . . . . . . . . . . . . 125
13.2. Informative References . . . . . . . . . . . . . . . . . 125
Appendix A. Issues for which Consensus Needs to be
Ascertained . . . . . . . . . . . . . . . . . . . . . . . 126
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 137
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 138
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 attributes 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 owner_group.
Noveck Expires 28 October 2024 [Page 4]
Internet-Draft Nfsv4 ACLs April 2024
* A number of security-related facilities separate from
authorization that use ACLs to identify sets of actions that might
be subject to various forms of monitoring as described in
Section 9.
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 security features
provided that are not connected with ACLs, and which is a complete
description in cases in which the OPTIONAL ACL-related attributes are
not implemented.
In many cases, the overall security document will have abbreviated
descriptions that serve as an introduction to material in this
document and reference sections within this document. Similarly,
there will be occasions where it is necessary for this document to
reference general features of NFSv4 security documented in
[I-D.dnoveck-nfsv4-security].
For the most part, these two documents are indepenendent, except for
the inter-document references discussed above. However, the
following execptions should be noted:
* Section 1 of [I-D.dnoveck-nfsv4-security], in its entirety,
applies to both documents, even in the absence of explicit inter-
document references.
* The terminology defined in Section 4.1 of
[I-D.dnoveck-nfsv4-security] can be used in either document,
without an explcit inter-document reference.
* The sections dealing with Security Considerations and IANA
Considerations appearing in [I-D.dnoveck-nfsv4-security], i.e.,
Sections 18 and 19 of that document apply to the security-related
changes being made in the current update as a whole, i.e., to both
documents.
* Appendix A of [I-D.dnoveck-nfsv4-security], in describing the
security-related changes made from previous specifications,
includes changes made in both this document and the overall
security document.
* The Appendices devoted to tracking Consensus Items, i.e.,
Appendix A of this document and 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.
Noveck Expires 28 October 2024 [Page 5]
Internet-Draft Nfsv4 ACLs April 2024
This is because there are related consensus items in the several
documents whose resolution might affect one another, including
some that result from consensus items affecting material now in
muliple documents.
1.2. Dealing with the Previous Uncertinty regading ACL Semantics
In the case of ACLs, previous specifications have left us with a
difficult situation that now needs to be resolved. Inevitably, this
will involve changing exxisting text while trying to avoid
compatibility issues. In this particular case, instead of having a
small set of individual mistakes which can now be recognized as such,
we need to address a complex set of issues together. We now have a
situation in which the existing specifications have created an
unacceptable interoperability situation in relation to ACL
implementations. Existing specifications have not paid proper
attention to the need to make decisions in the face of disagreements
regarding proper server behavior and have in various ways avoided the
need to compromise and reach a reasonable consensus but instead have
made it the job of the specifications to consider valid any remotely
similar server implementations as valid, leaving clients little that
they could do other than to accept a wide range of server behavior as
valid, simply because it was chosen by some particular server.
The working group did not provide any definition of a restricted
level of ACL support that Unix servers could provide and that would
address the needs of Unix clients. Instead, the only definition of
ACL support was one that met the needs of Windows clients while
providing a large set of facilities that did not fit within ACL needs
of Unix systems, not all of of which were expected to be implemented
by UNIX systems.
As it became clear that considerable pieces of the ACL functionality
were only of value to Windows clients and were difficult to provide
on Unix servers, the working group declined to draw that line but
instead haphazardly opened the spec to a wide variety of possible
server behaviors by the following methods:
* Essentially made each ACL mask bit its own optional feature with
each server free to choose to implement that bit or not.
Unfortunately, unlike most cases in which an optional feature is
provided for, there was no means for the client to find out
whether the server provided support a for particular mask bit or,
if it did not, how it was to deal with authorizations normally
controlled by the unsupportd mask bit.
* Similarly, all ACL flags were essentially made optional.
Noveck Expires 28 October 2024 [Page 6]
Internet-Draft Nfsv4 ACLs April 2024
This was done, as in the case above, without using the terms
"OPTIONAL" or "MAY" which might have suggested the need to provide
a means for clients to find out about the choices that servers
were allowed to make.
* Used "SHOULD" in situations in which it was not clear why the term
was used or was it possible to determine what might be considered
valid reasons to bypass the recommendation.
Since clients have no means to find out whether these unspecified
reasons apply, they find themselves in a position similar the one
that would exist if "MAY" were used.
Again a range of server behavior was allowed without any analysis
of the question of whether allowing such variability was
necessary, its effect on client interoperability, or how the
client might find out about the server's choices.
* While building many aspects of the interactions of the mode
attribute and ACLs around a mapping from ACLs to modes, the
existing specifications allowed at least two different such
mappings to be used, creating a difficult interoperability
situation for clients.
The preferred mapping is introduced using "SHOULD", again being
unclear about possible reasons to bypass the recommendation, if
that is what it is. It is sometimes stated that the use of
"SHOULD" is "intentional", leaving one to wonder how to deal with
the presumably unintentional other uses of "SHOULD".
Although, it is claimed that the intention was "to avoid
invalidating existing implementations that compute the mode
according to the withdrawn POSIX ACL draft (1003.1e draft 17)", it
is unclear how this choice relates to the working group's decision
to base NFSv4 ACL on Windows ACLs rather than on the withdrawn
POSIX draft ACLs. It is possible that there were different
opinions on the proper mapping and that, instead of resolving the
issue, the working group avoided the need to resolve this
disagreement, by simply allowing both methods, ignoring the effect
on interoperability.
The effect of "invalidating " such implementations would be to
make it clear that they are implementations of a different sort of
ACL, rather then of the NFSv4 ACL model, adopted by the working
group. Instead, the specification allowed these implementations
as well as many possible hybrids of both models.
Noveck Expires 28 October 2024 [Page 7]
Internet-Draft Nfsv4 ACLs April 2024
A case can be made that clients, who often support only ACL-
related APIs based on the Unix ACL model are entitled to matching
ACL support, but the hybrid approach adopted makes no provision
for client choice and does not even allow the client to find out
the characteristics of the particular hybrid implementation,
chosen by the server.
* The updating of ACLs in response to changes in the mode attribute
is another area in which previous specifications have chosen, for
reasons which remain unclear, to allow a wide range of server
behavior.
Only a single part of the necessary ACL change is clearly
specified as compliant with the spec.
On the other hand, use of this approach is discouraged using non-
normative terms
The combination of all the above has created a difficult
interoperability situation. While it is often noted that clients are
working in this environment, without complaining about the situation,
we have to understand the reasons why this might be so:
* Unix clients have good reason to stay away from ACLs that use
features, such as ACLs defining extend-only files, or ACLs whose
set of users with permission to modify ACLs is different from the
single owning user. This leaves them no occasion to discover that
the handling of these is not clearly specified.
Some clients have ACL-related APIs (e.g. those appropriate to UNIX
ACLs) while for clients that have APIs oriented to NFSv4 ACLs, any
incompatibilities will be perceived by the applications, leading
to a situation in which problems cannot be brought to the
attention on the working group in any context in which a
reasonably prompt resolution can be expected.
* By discouraging direct client access to the ACLs, the need for
clear specification of ACL semantics was obviated to a degree.
On the other hand, clients were given no corresponding way to
avoid clear specification of ACL semantics when deciding on the
ACL to effect a given pattern of authorization for a file.
* There has been no interoperability testing of this feature.
* There are very low expectations in the ACL support area, as a
result of choices made and not made decades ago.
Noveck Expires 28 October 2024 [Page 8]
Internet-Draft Nfsv4 ACLs April 2024
Given the importance of security, this unfortunate situation cannot
be allowed to persist indefinitely even if it might not be possible
to fully resolve it for some existing minor versions. For a
discussion of how we intend to improve the situation, both for
earlier unchangeable minor versions and others, see Section 1.3.
1.3. 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], in that it seeks to support two
different ACL modela and reasonable hybrid of the two.
Previously the NFSv4 ACL model had been presented as canonical, while
the inability of many servers to provide such support was dealt with
by a pervasive laxness about descriptions of the intended semantics.
This laxness included the following unfortunate elements, which have
been removed:
* In many cases, it was suggested that the fact that servers behave
in a particular way necessarily implies that clients have to
accept this behavior.
These have all been removed.
* In many cases, "SHOULD" was used used without any clear
indications of valid reasons to ignore a recommendation.
In such cases "MAY" or an equivalent is desirable but, to avoid
existing implementtions being retrospectively defined as non-
compliant, we continue to use "SHOULD" with the clear
understanding that reliance on Proposed Standards (even those
subsequently obsoleted) is valid reason to bypass the
recommendation in such cases.
* Eliminate, to the degree possible, situation in which, multiple
behaviors are allowed, with no clear understanding why allowing
such freedom is needed.
This approach did not give clients any way to determine which ACL
model was supported by a given server, sharply limiting the actual
value of the additional elements added to UNIX ACLs to establish the
semantics of full NFSv4 ACLs.
The ways in which the current description differs frompevious ones
are as follows:
Noveck Expires 28 October 2024 [Page 9]
Internet-Draft Nfsv4 ACLs April 2024
* The way in which alternatives are presented has been revised is
described in Section 1.3.1. This change in the description
framework is useful for all minor versions.
* The changed framework provides a basis for limiting permissible
hybrids as described in Section 1.3.3. This limitation will use
knowledge of existing implementations to limit acceptable hybrids
to those which actually implemented or otherwise need to be
accommodated. The effect may be different for different minor
versions but is expected to provide significant clarifiction for
all.
* We describe reliable means by which the client can determine which
ACL model is spported or the nature of the hybrid support provided
as decribed in Section 1.3.2.
1.3.1. New ACL Description Framework
There are a number of significant changes in the desriptive framework
used to describe the semantics of ACLs, although the XDR description
remains the same. The most important concern how to address the need
to support multiple semantic models for ACLs,including UNIX ACLs,
NFSv4 ACLs and various hybrids of the two.
[Author Aside (Item #104a)]: In this document, we adapt a very
different approach frm that used previously. This shift, elements of
which affect large parts of this document will be identified as
Consensus Item #104.
In this document the more limited UNIX ACL Model is presented aa
foundational, while the elements necessary to provide support for
NFSv4 ACLs are treated as OPTIONAL extensions to the UNIX ACL model.
[Author Aside (#Item #105a)]: The apparatus provided to inform the
client of the semantics provided by the server is described in
Section 1.3.2 and other later sections of this document where it is
identified as Consensus Item #105.
To help better support existing unchangeable minor versions, some
elements of the semantic model provided can be inferred from the set
of ACE types supported. For NFSv4.2 and future minor versions an
additional OPTIONAL attribute Aclfeature is defined as an extension
of NFSv4.2.
Noveck Expires 28 October 2024 [Page 10]
Internet-Draft Nfsv4 ACLs April 2024
1.3.2. Providing Implementation Information to the Client
The task of fully providing information about the ACL semantics
supported by the server to the client is made complicated because of
the lack of clear semantic descriptions in previous specifications.
This lack of clarity goes beyond what would be necessary to allow use
of the two supported ACL models and reasonable hybrids of the two.
Previous versions of NFS avoided the need for detailed descriptions
of file system semantics by relying on POSIX semantics, with slight
modifications to deal with NFSv3 peculiarities such as the lack of
over-the-wire open. As a result, the working group had no experience
with provding semantic descriptions at the needed level of detail
when NFSv4 included additional filesytem semantics for features not
covered by POSIX. As a result what emrged was more like a rough plan
to develop a complete specfication rather than the specification that
should have been part of NFSv4 specifications.
As a result of this lack of clear semantic description and the
attempt to support two different models without clearly delineating
the choices to be made, the Aclfeature attribute described in
Section 3.6 is considerably more complex than a small set of bits,
one for each potential extension to UNIX ACLs to arive at a full
implementation of the NFSv4 ACL model.
In many cases, a large number of possible variants of one potentitial
feature are likely to exist in different implementations given the
lack of detailed semantic description in existing specfifications and
the common belief that it is not the job of the implementation to
conform to the specification, making it the job of the protocol to
serve as an intermediary bewteen clients who are meant to be unaware
of these details and servers who are not to be constrained in this
regard. As a result, the Aclfeaure attribute, as the only available
vehicle to communicate server implementation choices, will provide
for all reasonable choices to be commnicated, although there is the
prospect of constraining those choces, as described in Section 1.3.3,
as we find out whether the lack of deails in existing specfications
resulted in substantally different implementations.
1.3.3. Limiting Implementation Choices
Although our ultimate goal of defining a clear set of individual
extensions to UNIX ACLs that servers can choose and communicate will
not be immediately available, we can make progress toward that goal
based on the approach taken here and its gradual refinement as we
work to move this document forward, taking into account what we learn
about existing client and servers that contain ACL support. Note
that the reslts will vary based on the minor versions used and the
Noveck Expires 28 October 2024 [Page 11]
Internet-Draft Nfsv4 ACLs April 2024
existing use, if any, of many of the extensions to the UNIX ACL model
that collectivly constitute the NFSv4 ACL model.
Because of the nature of current ACL specifications and the
consequent lack of attention to interoperability, we are not, in the
initial specification of this attriute, able to communicate the
implementation choices made by servers in a compact way, as a small
set of individual features that server can choose to implement or
not.
As a result, the initial specification of the AclFeature attribute
provides many choices that exist only because of a lack of detail and
clarity in existing specfications.
Even if no server implementations implement that initial
specifcation, the options that it provides can be used within the
working group as a language defining the choices particular
implmentations have made, whether made explicitly or by as a
consequence of adapting to existing implemetations. Similarly, the
expectations of clients could be expressed in terms of the Aclfeature
values that particular clients are prepared to deal with.
As work proceeds on this document, there are number of ways that the
Aclfeature attribute could be refined to more closely approximate the
desirable situation dsecibed above, in which the choices are limited
to things like the choice of ACL model, support for DENY ACEs,
extend-only files and finer-grained directory operation authorization
all together with separate choices regarding the set of ACLs to be
stored but not necessarily fully supported. As part of that procees,
the group will try to delete presentation of choices that could
conceivably result from different implementers making different
choices to deal with lack of specification detail, but where there is
no actual divergence of behavior. Some illustrative examples follow:
* Cases where the way in which the default setting for a particular
mask bit is not specified or, similarly, where autnorization
constraints for actions associated with an unsupported mask bits
is not clearly specified.
* Two choices that might appear independent are always made
together, allowing them the associated options to be coalesced, if
otherwise appropriate.
* Some extensions, although anticipated as possibilities, might
never have been realized in any impementation, allowing the
corresponding options to be deleted.
Noveck Expires 28 October 2024 [Page 12]
Internet-Draft Nfsv4 ACLs April 2024
There might also be a few situations which Aclfeature might be
extended as in the examples below:
* The handling of within-directory RENAME might follow the
prsentation in th original specification in which it assumes it
requires both ACE4_ADD_FILE (ACE4_ADD_SUBDIRECTORY if one is
renaming a subdirectory) and ACE4_DELETE_CHILD.
To have this difference in handling have any visible effects would
require servers which support distinct permissions for adding and
removing files from a drectory (only one has been found so far)
together with clients tht set ACLs that have distinct permissions
for these two operations (none found so far).
* The handling of the mask bits ACE4_{READ,WRITE}_NAMED_ATTRIBUTES
might follow the original prsentation, which focused solely on
permission to execute the OPENATTR operation, or the one in this
document, which, in line with the POSIX-BASED approach to
authorization of operations on named attribute directories, has
these bit covering the reading and writing of the named attributes
directories.
So far no seve implementations have been found supporting this
features. If one does and it follows the older approach, the
working group will have to decide which approachs needs to be
considered recommendd.
1.3.4. ACLs in various Minor Versions
[Author Aside (Item #105b), through end of bulleted list]: This
sections role is primarily to guide use and development of the
Aclfeature attribute. As such, the current version is directed to
the Working Group rather than the larger it would have as an approved
standards-track doument. In light of it is likely that some of the
following changes might be needed.
* If the original goals for the Aclfeature attribute are met and the
resuling RFC candidate enters WGLC, then sections would need to be
feavily revised. Material relating to the earlier stages of
attribute development would be eliminated. The description of the
situation for various minor vesions would stay pretty much as it
is.
* If the development of the Aclfeature does not proceed in a timely
fashion, and it became necessary to disconnect the development of
the Aclfeature from the rfc5661bis effort, the RFC to be included
as part of rfc5661bis, while derived from this document will be
substantially different:
Noveck Expires 28 October 2024 [Page 13]
Internet-Draft Nfsv4 ACLs April 2024
As part of the deletion of the Aclfeure attribute, this section
and a number of other sub-sections of Section 1.3 would be
deleted.
* If the disconnect described above does occur, the work on the
Aclfeature attribute would proceed in a separate document whose
iitial draft would derived from this one. We will refer to that
document as aclv2, with its handling of this section as described
immediately below
The list of stages will be pruned to eliminate those no longer
relevant. The description of the situation for various minor
vesions would stay pretty much as it is.
* When aclv2 was nearly ready for WGLC, another set of changes would
be requied
Material relating to the earlier stages of attribute development
would be eliminated. The description of the situation for various
minor vesions would be lminet to NFSv2 and NFSv3.
We can define the various stages of ACL handling as they relate to
the development of the aAclfeature attribute as follows:
* Stages where the Aclfeature extension is not available.
During this stage we only have the ability to infer the ACL model
supported from the set of ACE types supported, with no provision
for hybrids.
* Stages where the Aclfeature extension is made available for
experimental use.
It is expected that this stage would begin when this docuument or
a successsor is published as a Working Group Document. At that
point the working group would be able
* Stages where the Aclfeature extension is first made available for
production use.
* Stages where the Aclfeature extension is available and other
extensions can be made.
* Stages where it is possible to further restrct server ehavior or
to create additional REQUIRED attributes.
This stage would only be available in a new minor version (e.g.
NFsv4.3)
Noveck Expires 28 October 2024 [Page 14]
Internet-Draft Nfsv4 ACLs April 2024
These stages apply to various minor vesrsions as follows:
* NFSv4.0 implementations have no realistic propect of diretly
benefiting from the Aclfeature attribute.
However,
* While NFSv4.1 implementations cannot support the Aclfeature
attribute, it is relatively easy to convert an NFSv4.1 server
implementation to a NFSv4.2 server implementation that supports no
v4.2 OPTIONAL feature other that the Aclfeature attribute.
Similarly, an NFSv4.1 client implementation can be easily
converted to an NFSv4.2 cliet implementtion that use no v4.2
OPTIONAL feature other that the Aclfeature attribute.
* Existing NFsv4.2 client and server implementations could add
support for the AclFeature attribute once this is published as
part of the set of rfc5661bis-related RFCs.
* When and if there is a new NFSv4 minor version that could add
REQUIRED attributes or further limit expected ACL behavior (e.g.
NFSv4.3), we could limits servers to either of the existing ACL
models (with one clear definition of each) or reasonable hybrids
thereof.
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.
Noveck Expires 28 October 2024 [Page 15]
Internet-Draft Nfsv4 ACLs April 2024
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.
2.3. Use of the Term "SHOULD
[Consensus Needed (Item #4a), Through end of Section]: The use of the
BCP14-defined term "SHOULD" merits particular attention beause of its
mistaken common use in earlier discussions of matters addressed in
this document and because of its central role in defining
interoperability for client and server implementations. In
particular, we will use the BCP14-defined term "SHOULD" in order to
designate recommended implementation characteritics without
retrospectively defining existing implementations as non-compliant.
In previous treatments of ACLs this term was used extensively in
contexts in which it was not made clear what might be valid reasons
to bypass the implied recommendation, as required by [RFC2119].
* In some cases, specific uses of the term were described as
"intentional", with the apparent implication that the reasone for
the use of this term was to allow implementations to ignore the
recommended ation simply bcause it was felt to be inconvenient.
The effect was that such uses of "SHOULD" were intepreted as "MAY"
with the added expectation that implemtations bypassing the
recommendation should be expected.
This left uncertain the question of how an "unintentional" use
should be interpreted but it made quite clear that this term was
not being used in accordance with BCP14.
* The majority of uses of this term, presumably unintentional ones,
do not seem to be in accord with [RFC2119] either in that it is
not made clear what might be valid reasons to bypass the
Noveck Expires 28 October 2024 [Page 16]
Internet-Draft Nfsv4 ACLs April 2024
recommendation. The only conclusion that can be reached at this
point is that the author felt that there might be valid reasons to
bypass the recommendation but was unsure if any existed. However,
it appears likely that, in most cases the threshhold for
considering a reason valid in this context were quite low, most
likely because it was often assumed that the possible existence of
existing software components (e.g. file systems designed without
regard to NFSv4's needs) which made it difficult ro conform to the
recommendation would sonstiute a valid reason to bypass the
recommendation, the feect on feature interoprability
notwithstaning.
As might be expected, this pattern and other cases of excessive
deference to server implementation choices created a difficult
interoperability situation, which it is now the job of the working
group to correct. As part of doing so, we will, as was done in the
companion security document [I-D.dnoveck-nfsv4-security], when using
"SHOULD" without reference to specific valid reasons to bypass the
recommendation, the understanding is that, in this context, reliance
on an earlier specification which allowed behavior now recommended
against is a valid reason to continue to behave in that manner even
if the allowance was communicated through the mistaken use of
RFC2119-define keywords,
Also, with regard to such residual uses of "SHOULD", it needs to be
understood that:
* With regard to new server implementations, there are no furtther
valid reasons to bypass the recommndation unless those are
explicitly mentioned.
* That when reporting implementation characterisics (e.g. by use of
the Aclfeature attribute) the right to bypass a recommendation is
not to be accepted does not allow an implementer to report the
recommendation as adhered to.
* That clients are under an obligation to accept such variances from
these recommendations and MAY, as the implementors judge prudent,
to not use the ACL feature or to restrict its use to avoid
reliance on particular troublesome instance of recommendations
being bypassed.
Noveck Expires 28 October 2024 [Page 17]
Internet-Draft Nfsv4 ACLs April 2024
3. ACL-based Authorization-related Attributes
[Author Aside: (Items #14a, #15a... ), Applies to entire top-level
section]: The treatment of the various ACL-based attributes in the
included subsections replaces the corresponding sections in earlier
documents, in which the attribute descriptions were not consolidated
in one place and were disbursed among a number of top-level sections.
Where it has been necessary to make significant changes, the
annotations for those changes, including author asides and proposed
text, appear here while vestigial text that is now superseded has not
been brought forward.
The per-object attributes Acl, Dacl, and Sacl all contain an ACL
object as described in Sections 4 and 5 and their subsections.
3.1. Definition to Support ACL-related attributes
The definition of the acemask4, which appears immediately below,
needs to be done earlier than others since it is used directly in the
definition of ACL-related attributes as well as within the definition
of the ACE structure in Section 5.
typedef uint32_t acemask4;
The definition of the individual bits within these mask words appears
in Section 5.2
3.2. Table of ACL-related Attributes
The following table summarizess all the ACL-related attributes,
including:
* Attributes to support ACL-based authentication: Acl, Dacl.
* Attributes to provide other security-related services: Sacl.
* Attributes to provide information regarding the level of ACL
support provided: Aclfeature, Aclsupport.
Noveck Expires 28 October 2024 [Page 18]
Internet-Draft Nfsv4 ACLs April 2024
+============+============+======+===========+=====+=============+
| Name | Id | Ver | Data Type | Acc | Defined in: |
+============+============+======+===========+=====+=============+
| Acl | 12 | 4.0 | nfsace4<> | R W | Section 3.4 |
+------------+------------+------+-----------+-----+-------------+
| Aclfeature | [TBD-ACLF] | 4.2x | nfsaclf4 | R | Section 3.6 |
+------------+------------+------+-----------+-----+-------------+
| Aclsupport | 13 | 4.0 | uint32_t | R | Section 3.5 |
+------------+------------+------+-----------+-----+-------------+
| Dacl | 58 | 4.1 | nfsacl41 | R W | Section 3.7 |
+------------+------------+------+-----------+-----+-------------+
| Sacl | 59 | 4.1 | nfsacl41 | R W | Section 3.8 |
+------------+------------+------+-----------+-----+-------------+
Table 1
3.3. Types of ACLs
The ACL allows authorization schemes outside those conforming to the
POSIX approach to be specified and applied to file objects. This
provides additional flexibility in a number of ways:
1. There may be multiple users or sets of users assigned different
privileges to address cases in which the appropriate privilege
assignments do not conform to the POSIX model in that they are
different for users in the same group or different for two groups
outside the owning group.
ACLs support this additional flexibility by allowing an array of
Access Control Entries, each of which specifies handling for a
user or user group.
2. For 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 and are prsented in a
common XDR framwork, they are substantially different, in that:
Noveck Expires 28 October 2024 [Page 19]
Internet-Draft Nfsv4 ACLs April 2024
* The draft POSIX ACLs address only the first of the motivations for
extension, while the NFSv4 ACL model is intended to address both
of them, by defining a large range of bits in the ACE mask, rather
than the three POSIX bits.
* NFSv4 ACLs, by supporting DENY entries allow specfic privileges to
be allowed for most members of a group and be denied to some
particular users.
* NFSv4 ACLs provide additional security-related facilities in
addition to authorization control, through the use of AUDIT and
alarm ACEs.
{Author Aside (Item #61a)]: In order to justify an eventual shift of
the Acl and Dacl attributes back to be truly OPTIONAL, it is
necessary to define for each file system, the type of ACL semantics
provided, using information such as that provided by the Aclsupport
attribute. In so doing, we will have to make provision for various
hybrids if such implementations actually exist, while not necessarily
seeking to preserve the ability to generate other such potential
hybrids, in all cases.
[Consensus Needed, Including List (Item #61a)]: The determination of
the type of ACL semantics proceeds as follows:
* If the aclsupport attribute indicates that either AUDIT or ALARM
ACEs are supported, then it can be assumed that, in general, NFSv4
ACL semantics are provided, although some OPTIONAL ACE mask might
not supported.
* If the Aclsupport attribute is not supported, then if the Sacl
attribute is supported then it also can be assumed, as above, that
NFSv4 ACL semantics are provided.
* Otherwise, If the Aclsupport attribute is not supported then the
presence of support for DENY ACEs determines whether support for
NFSv4 ACL semantics is provided. However, it is required that
clients determine whether support for DENY ACEs is provide by
attenpting to set ACLs ontaining such ACEs
* In the case in which neither the aclspport attribute nor the SACL
attribute is supported, then it can also be assumed that support
for NFSv4 ACL semantics is provided.
As a conequence, server implementations providing support for UNIX
ACLs only, need to support the aclsupport attribute. This is
because, if they do not, the client could legitamately assume that
support for the NFSv4 ACL model in present.
Noveck Expires 28 October 2024 [Page 20]
Internet-Draft Nfsv4 ACLs April 2024
3.4. The Acl Attribute (v4.0)
This per-object attribute consists of an array of Access Control
Entries which apply to operations performed on the current object,
controlling authorization and monitoring of attempted operations.
This attribute, as opposed to the sacl and dacl attributes, consists
only of an ACE array and does not support automatic inheritance,
although some inheritance features might be supported, altough not
when the UNIX ACL model is the one supported.
The acl attribute is OPTIONAL and there is no requirement that a
server support it. However, when the dacl attribute is supported, it
is a good idea to provide support for the acl attribute as well, in
order to accommodate clients that have not been modified to use the
dacl attribute.
{Consenses needed, Including List (Item #65a)]: While the original
intention was to define a usable OPTIONAL attribute based on the
NFSv4 ACLs defined previous specfications, it is now more appropriate
to designate this under-specified attribute as experiemental although
still formally OPTIONAL, until the items below have been addressed.
* The intention to support, as values of this attribute two
different ACL approaches, each with its own semantics. These
include both the NFSv4 ACLs based on the Windows ACL model and a
subset based on the more restricted semantics provided by the
withdrawn POSIX ACL document with a straightforward mapping of
those into the format of NFSv4 ACLs.
The association of two such different semantic models without
giving the client a way to determine which semantic model is in
effect makes interoperability ssentially impossible to provide.
* The potential interoperability problems are vastly expanded by the
specific method by which these two models are supported.
Instead of allowing servers to choose between these two
approaches, e.g. by using the term "MAY", most statements
regarding ACL semactics use the term "SHOULD", described in the
text as "intentional", apparently assuming that the result is
essentially equivalent to the use of "MAY". Even apart from the
misuse of the terms defined in [RFC2119], this has the effect of
replacing a single choice by allowing a large number of unco-
ordinated choices, exponentially raising the number of possibly
valid semantic models that clients and users have to accmmodate.
Noveck Expires 28 October 2024 [Page 21]
Internet-Draft Nfsv4 ACLs April 2024
* It is not clear how far this pick-and-choose approach extends. In
the case of the ace mask bits which are finer-grained than the
three bits in the mode and in POSIX ACLs, there is no explicit
text indicating how the coarser-grained approach would be
supported by a server built to support POSIX ACLs, leaving the
actual requirements uncertain.
* Although some efforts have been made to limit the damage caused by
this specification uncertainty by urging clients to determine
authorization decisions using ACCESS rather than by examining the
ACL itself, this only addresses half of the problem and the
question of what ACL to set to effect a particular authorization
regime remains unaddressesd, limiting the usefulness of the ACL-
related features.
Although significant efforts have been made to widen the
information returned by ACCESS beyond the three-bit POSIX model,
there are still cases in which it is insufficiently fine-grained.
For example, adding a new file and a new sub-directory which have
different ACE mask bits are both represented by a single bit in
ACCESS.
[Author Aside]: Although it has generally been assumed that changes
to sacl and dacl attributes are to be visible in the acl and vice
versa, NFSv4.1 specification do not appear to document this fact.
[Consensus Item, Including List (Item #16a)]: For NFSv4.1 servers
that support Both the acl attribute and one or more of the sacl and
dacl attributes, changes to the ACE's need to be immediately
reflected in the other supported attributes:
* The result of reading the dacl attribute MUST consist of a set of
ACEs that are exactly the same as the ACEs ALLOW and DENY ACEs
within the the acl attribute, in the same order.
* The result of reading the sacl attribute MUST consist of a set of
ACEs that are exactly the same as the AUDIT and ALARM ACEs within
the the acl attribute, in the same order.
* The result of reading the acl attribute MUST consist of a set of
ACEs that are exactly the same as the union of ACEs within the
sacl and dacl attributes. Two ACEs that both appear in one of the
sacl or dacl attributes will appear in the same order in the acl
attribute.
Noveck Expires 28 October 2024 [Page 22]
Internet-Draft Nfsv4 ACLs April 2024
3.5. The Aclsupport Attribute (v4.0)
A server need not support all of the ACE types described in
Section 6.1. This attribute indicates which ACE types are supported
for the current file system by any of the acl, sacl, or dacl
attributes.
[Consensus Needed (Item #61b)]: Although this attribute is OPTIONAL,
there are important reasons, in certain cases, to provide support, as
described in Section 3.3.
The bitmask constants used to represent the abovementioned
definitions within the aclsupport attribute are as follows:
const ACL4_SUPPORT_ALLOW_ACL = 0x00000001;
const ACL4_SUPPORT_DENY_ACL = 0x00000002;
const ACL4_SUPPORT_AUDIT_ACL = 0x00000004;
const ACL4_SUPPORT_ALARM_ACL = 0x00000008;
[Author Aside (Item #14b)]: Even though support aclsupport is
OPTIONAL, there has been no mention of the possibility of it not
being supported.
[Consensus Needed (Item #14b)]: If this attribute is not supported
for a server or filesystem, the client is entitled to assume that, if
the acl attribute is supported, support for ALLOW ACEs is present.
Thus, if such a server supports the the sacl attribute, clients are
not likely to use it if aclsupport is not supported by the server.
[Previous Treatment (Item #110a)]: Servers that support either the
ALLOW or DENY ACE type SHOULD support both ALLOW and DENY ACE types.
[Author Aside, Including List: (Item #110a)]: The use of "SHOULD" in
the preceding is unhelpful for the following reasons:
* While it is unclear what the intention is, it is certainly is not
in accord with RFC2119 since there is no indication of potential
harm or what might be valid reasons to do otherwise.
* While it might be one of "intentional" SHOULDs, that would make
the paragraph meaningless since such SHHOULds are essentially
equal to MAYs.
* The most likely source of divergence,the fact that UNIX ACLs do
not suport DENY ACEs is not mentioned at all.
[Consensus Needed (Item #110a)]: Servers that support the DENY ACE
type MUST support the ALLOW ACE type as well.
Noveck Expires 28 October 2024 [Page 23]
Internet-Draft Nfsv4 ACLs April 2024
[Consensus Needed, Including bulleted list (Item #110a)]: Clients
should not attempt to set an ACE unless the server claims support for
that ACE type. The server MUST reject requests with
NFS4ERR_ATTRNOTSUPP if any of the following apply:
* If the server receives a request to set an ACE type that is not
allowed as part of the acl attribute being set.
* If the server receives a request to set an ACE, it cannot store.
Support for any of the ACL attributes is OPTIONAL. However, certain
restrictions apply regarding the interaction of support for these
attributes, A server that supports either of the newer ACL attributes
(dacl or sacl) MUST support use of the new ACL attributes to access
all of the ACE types that it supports. In other words, if such a
server supports ALLOW or DENY ACEs and the sacl attribute, then it
MUST support the dacl attribute and any ALLOW or DENY ACE tyopes
supported by the tha acl attribute MUST be supported in the dacl
attribute as well. Similarly, if it supports AUDIT or ALARM ACEs and
the dacl attribute, then it MUST support the sacl attribute any AUDIT
or ALARM ACE types supported by the tha acl attribute MUST be
supported in the dacl attribute as well.
3.6. The Aclfeature Attribute (v4.2 extension)
[Consensus Needed (Item #105c), for entire section]
The contents of the Aclfeature attribute, which provides per-fs ACL
feature support information, are described in the XDR below.
typedef uint32_t af4miword;
struct af4minfo {
af4miword flagw;
acemask4 maskw;
};
typedef uint32_t af4typemask;
typedef uint32_t af4flags;
typedef uint32_t af4whoinf;
struct afeat4 {
af4typemask tmask;
af4flags flword;
af4whoinf whoword;
af4minfo maskinf<>;
}
Noveck Expires 28 October 2024 [Page 24]
Internet-Draft Nfsv4 ACLs April 2024
The field tmask provides information regarding the ACE types that are
supported (as does the Aclsupport attribute) and also those that can
be stored and retrieved while not being supported. See Section 5.1.2
for details
The field flword provides information regarding the ACE flags and
auto-inheritance flags that are supported. See Section 5.3.2 for
details
The af4minfo elements within the maskinf array provides information
to the existence of support for the individual ACE mask bits
appearing in ACEs. See Section 5.2.7 for details
[Consensus Needed (Item #4b)]: Previous specfications have given
server implementations wide latitude in terms of the ACL semantics
implemented. The prime motiation of the Aclfeature attribute is to
provide information about semantic choices validly made by the
server. However, there may also be implementations that made choices
now no longer valid that are allowed to retain the existing
implementation, its non-recommended character notwithstanding. In
such cases, the server MUST indicate such non-standard semantics
whenever Aclfeature is implemented and the definition of the
attribute provides means to do so. See Sections 5.1.2, 5.3.2, and
5.2.7.
Their are a number of situations in which responses that conform to
the XDR are considred invalid nonetheless. These situations are
similar to those in which NFS4ERR_INVAL would be returned on a
request. In the case of this attribute value there is no predefined
way to inform the server of perceived attribute invalidity. The
following rules apply:
* The server MUST NOT send an invalid value as the Aclfeature
attribute.
* When a client detects an invalid field that is not limited to a
single maskinf[] entry, the client MUST NOT not act on the invalid
Aclfeature attribute. This include cases in which multiple
maskinf[] entries, while each valid in itself, contradict one
another.
* When a client detects an invalid field that is limited to a single
maskinf[] entry, the client MAY ignore that entry instead of
considering the entire Aclfeature attribute to be invalid
In a case in which the attribute is invalid, the client has several
choices:
Noveck Expires 28 October 2024 [Page 25]
Internet-Draft Nfsv4 ACLs April 2024
* Ignoring the invalid AclFeature attribute, and proceding as if the
attribute were not implemented. In this case, support descisions
are limited to inferences that can be arrived at based on the set
of ACE type supported.
* Treating the Acl, Sacl, and Dacl attributes as unsupported. For
clients that require acl support, this can result in an inability
to use the file system.
In choosing between these, client implementations need to balance the
potential incovenience of refusing to use a feature whose semantics
is unclear against the likelyhood that ignoring the invalid attribute
might result in the problem never being fixed. Given this choice,
implemetations can often avoid the strictest treatment by reporting
such issues prominently, making it clear that the problems exist.
3.7. The Dacl Attribute (v4.1)
The dacl attribute was added in NFSv4.1 in order to divide ACLs so
that the authorization-related entries (i.e. ALLOW and DENY entries
were no longer combined in the same attribute as AUDIT and ALARM
entries.
{Consensus needed, Thru rest of Section (Item #65b)]: While the
original intention was to define a usable OPTIONAL attribute based on
the NFSv4 ACLs defined previous specifications, it is now more
appropriate to designate this under-specified attribute as
experimental although still formally OPTIONAL until the issues
discussed in Section 3.4 are addressed
Athough the issues applying to the acl attribute apply equally to the
dacl attribute, given the description in earlier specifications, it
might be easier to resolve them in the case of the dacl attribute for
the following reasons:
* Implementaions of POSIX ACLs might not have been updated to
support the sacl attriute, since doing so would add no value.
* Even if such POSIX-ACL-oriented implentations of the sacl
attribute did exist, it might be easier to get agreement on
regularizing the sacl attribute since, if acl were left as it is,
the POSIX ACL support would still be available.
3.8. The Sacl Attribute (v4.1)
The sacl attribute is like the acl attribute, but sacl allows only
AUDIT and ALARM ACEs. The sacl attribute supports automatic (see
Section 6).
Noveck Expires 28 October 2024 [Page 26]
Internet-Draft Nfsv4 ACLs April 2024
{Consensus needed, Thru rest of Section (Item #65c)]: While the
original intention was to define a usable OPTIONAL attribute based on
the NFSv4 ACLs definedin previous specifications, it is now more
appropriate to designate this under-specified attribute as
exprimental although still formally OPTIONAL until the issues
discussed in Section 3.4 are addressed
The Sacl attribute was added in NFSv4.1 in order to divide ACLs so
that the non-authorization-related entries (i.e. AUDIT and ALARM
entries) would no longer be combinded in the same attribute with the
ALLOW and DENY entries.
[Author Aside, Including List (Items #61c, #105d, #110b)]: Athough
the existing discussion of ACE structure results in the same sort of
lack of clarity affecting the Acl and Dacl attributes, it us more
likely that these will resolved in the case of the Sacl attribute as
compared to the Acl or Dacl attributes, even though the problems with
the existing text are essentially the same.
* There are no AUDIT or ALARM entries, in POSIX ACLs, so there would
be no need accommodate existing implementations of these that
embody a more POSIX-oriented semantic model.
As a result, it is likely to be easier to get WG approval for
changes that clearly state that the ACE mask bits are to followed
strictly for the these types of ACEs.
* Since such entries have no role in compute a corresponding mode
attribute, the effect of this issue for the sacl attribute is not
problematic.
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 5.1.
* 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 9. This involves use of Access Control
Entries of the AUDIT and ALARM types.
Noveck Expires 28 October 2024 [Page 27]
Internet-Draft Nfsv4 ACLs April 2024
[Consensus Needed (Items #61d, #105e, #110c)]: 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, up to the full set of extensions provided by
NFSv4 ACL semantics.
Matters that relate only to extensions provided to support NFSv4 ACLs
including the definition of the NFSv4.1-specific attribute Sacl, are
discussed in 9 and smmarized in Section 8.4 of
[I-D.dnoveck-nfsv4-security].
4.1. Need to More Clearly Address ACL Semantics Choices
Author Aside (Items #105f, #110d), Through end of section]: This
entire section is an explanation of the motivation for making the
extensive changes in the approach taken to the description of ACL
semantics in Sections 4.2 through 4.4 and in many subections of
Section 5. Although those sections, as now written, explain the
reasons for the approach adopted, the explanatory approach taken is
appropiate to a protocol choice already made, which will be
appropriate if the working group decides to adopt this new approach.
The explanation in this section is of a different nature, in that it
explains the fundamental design choice we now face, and why such
extensive changes to the approach taken in multiple previouly
publisjed Proposed Standards are now necessary, despite the
incongruity of adding an extension not previously discussed to the
extensible minor version NFSv4.2. This step is, in the author's
view, necessary to correct problems that having been part of the
NFSv4 protocols for over two decades.
It is anticipated that this section, like much other material in the
form of Author Asides, will not be published as part of the RFC
resulting from the progressive refinement of successive drafts of
this document.
In explaining the motivation this new approach, we will have to
understand the nature of the mistake that was made when ACL support
was incorporated, as part of NFsv4.0, in [RFC3010]. Although, in
explaining the choices actually made, we will have some suggestions
as to why it was made and approved, that is not the focus of our
investigation. Instead, we need to understand the mistake that was
made before we can understand the problems that it gave rise to and
examine the choices now available, as we work to address the problem.
As we look at the problems we now have and possible solutions, it
will become clear why the author believes that The approach taken
here, of providing a new attribute to inform the client of server
implemenation choices is the least of available evils if the goal is
Noveck Expires 28 October 2024 [Page 28]
Internet-Draft Nfsv4 ACLs April 2024
still, as it always has been, to take advantage of the more easily
implementable UNIX ACL subset, while allowing development, over time,
of more flexible alternatives. In the process, we will look at
potential alternate approaches to deal with support for two ACL
models, including some that could have been implemented earlier to
prevet this situation, but have become unavailable as the NFSv4
protools have evolved.
The basic problem that the working group faced in defining an ACL
feature for NFSv4 arose from the lack of existing semantic
descriptions of how ACLs were to work together with a set of
assumptions, derived from previous NFS versions, that maade it hard
to appropriately plan for the necessary work. Given this background,
there were two semantic models available which might be co-opted to
provide an ACL semantic model.
* The ACLs defined by a POSIX draft, later withdrawn. Here, and
elsewhere in this document and related documents, we describe
these as "UNIX ACLs".
Factors arguing for this as an appropriate choice were its close
connection with POSIX semantics, the existence of UNIX-based APIs
to establish and modify such ACLs and its commmon implementation,
within many file systems runnin within UNIX server
implementations, despite its withdrawn status.
On the other hand, that close connection to POSIX could be
considred limiting, in that model the adherered quite closely to
the POSIX approach with its coarse-grained approach to the
specification of authorized operations.
* Windows ACLs or the subset of it that could be fit into the NFSv4
protocol.
This provided a more flexible semantic model capable of finer-
grained control of the actions to be authorized or blocked
together with a number of elements that had no correlates within
the POSIX framework and could only be accepted by NFSv4 together
with the understanding that enforcement would be provided by
mechanisms ouside NFSv4.
As a result, initial impplementation of this model were not common
and any that were developed would likely to avoid some the
Windows-only material incoporation in the NFSv4 ACL model.
Given this background, the working group faced a difficult choice in
that adopting either pf these approaches posed significant
difficulties:
Noveck Expires 28 October 2024 [Page 29]
Internet-Draft Nfsv4 ACLs April 2024
* Adoption of the UNIX ACL approach, while likely to proceed quickly
did not address the goal of moving decsively beyond NFSv4 in terms
of ACL functionality.
* Adopton of the NFSv4 ACL model as the sole approach to ACL
semantics, would, most likely, have sharply limited adoption of
the ACL features to a small set of servers, with the expected
result that client would not be motivated to provide support
either.
Given the need to, in some fashion, support both of these semantic
models, the following two approaches listed below suggest themselves
as ways to take advantage of the immediate limited improvements
provided by UNIX ACL model, while allowing development over time of
implementations of the more flexible model.
* Defining support for the two types of ACLs by means of two
separate attributes.
* Providing the client other means (e.g. a per-fs read-only OPTIONAL
attribute) by which the client can determine which semantic model
was implemented.
As things turned out, neither of these approaches were taken, for
reasons that will not be discussed here. Instead, the two models
were embadded in a common XDR based on the NFSv4 model. Since the
embedding was such that UNIX ACLs, once put in this common form,
could not be recognized as such, the need for the two co-existence
options discussed above remained as it was, although later
developments had important effects limiting how the problem needed to
be addressed.
The resulting specification text, based on the XDR adopted, treated
the NFSv4 ACL model as canonical. The support for the UNIX ACL model
is limited to allowing, by various means, its implementation on the
server without really addressing the need to inform the client of the
semantic differences between the two models.
In the following, we list those semantic differences, which are, not
conincidentally, the specific issues that we have chosen to address
in the Aclfeature attribute. Together with each item, we discuss
possible alternatives to providing the information as an element in
an attribute like AclFeature.
* Existing specifications provide multiple ways of computing the
mode corresponding to an ACL, each described in its own section,
either Section 8.3 or 8.4.
Noveck Expires 28 October 2024 [Page 30]
Internet-Draft Nfsv4 ACLs April 2024
Although the existing specs do cite reasons why the first of is to
be preferred, it clearly allows server to choose either and
provides no way for the client to find out which aproach is
implemented, which makes interoperability testing hard to
accomplish.
While it would higly desirable to eliminate this variation, by
mandating one of these variations as REQUIRED, that has to be
considred quite unlikely at this point given the use, in the
existing specfications, of term SHOULD identified as an
"intentional use" with the clear implication that allowing this
behvior is necessary.
Given the likely existence of servers implementing the approach
described in Section 8.4, it appears that we would have difficulty
getting to a "SHOULD" that was valid according to [RFC2119].
Given that we are going to be faced with decidedly diffferent
approaches, it is essential that we provide a way to determine th
approach used. Without that, interoperbility testing cannot test
for the expected behavior since the expected behavior may differ
in unexpected ways, undercutting the entire effort.
* While UNIX ACLs use three permission bits, there are sixteen
distinct ACE mask bits, creating difficult issues in supporting
both models in the same protocol.
Part of this is due to the finer-grained nature of the ACE mask
bits, exacerbated by the mutiple use of each of the mask bits
defined in Section 5.2.3. For example, ACE4_WRITE_DATA can be
interpreted either as controlling all of the acions controlled by
the write privilege bit or the subset of such actions not
controlled by additional finer-grained mask bits.
The existing specfications are not very explicit about how to
address differences between the client and server as to diferent
approaches the mapping of authorization-requiring actions and the
corresponding mask bits. However, it is possible to infer an
expected approach which we can confirm (or not) once more
knowledge is made available regarding when client that support use
of ACLs actually do.
It seems that the expected approach to this problem was predicated
on the assumption that all of the ACE mask bits beyond those
described in Section 5.2.3 could be treated as finer-grained
versions of those three, as the ones described Section 5.2.4 are,
essentially ignoring the corresponding issue with regard to
Sections 5.2.5 and 5.2.6.
Noveck Expires 28 October 2024 [Page 31]
Internet-Draft Nfsv4 ACLs April 2024
With this limitation in mind, it seems that existing
specifications, essentialy require clients written to use the
three privilege bits of the UNIX ACL model, map the write bit to
the set of mask bits defined in Section 5.2.4 which all need to
authorized or not together. This makes the extensions to a finer-
grained authorization model essentially useless. For example, if
a client wants to specify an ACL for a directory which presvents
ubdirectories from being added (the reason for defining
ACE4_ADD_SUBDIRECTORY) it has a way to specify an ACL that would
do that if the server supports such a thing but that is all.
There is no way for the client to determine whether such an ACL
wold be accepted or whther it would do the desired thing if it
were accepted.
* There are special who values defined in Section 5.4 which are not
explicitly defined as OPTIONAL but which, by their nature appear
to be higly unlikely to be implemented by servers and for which,
so far, no implementations are known.
These special values need to be explcitly presented as OPTIONAL,
if they are retained in the protocol. Given the absence of known
implementations so far, their elimination should not be considered
impossible.
If these values are to be retained, there needs to be some eays
determine to determine if server support is provided. Without
that, client cannot use them, even on the the server subset
providing this support.
* There is support, via the acsupport attribute, for determining the
set of supported ACE types but the existing specifications do not
really address the issues of ACE types that can be stored without
being supported a it attempt to do with rspect to other similar
issues with potentially unsupported protcol elements.
To summarize, we have a situation in which some of the items
discussed above might be avoided without undoing the work done to
provide the extensions within the NFSv4 ACL model, but there are
others in which this work has to be considered essential. As a
result, there needs to be an Aclfeature attribute or somethings
similar. Given that fact, as the proposal now stands, all of the
above are dealt within that single framework.
As a result of the lack of attention to the task of providing the
client information regarding the specific ACL extensions supported,
we now have a situation inferior to that which would have arisen if
either of the original choices has ben pursued staightforwardly or if
both had been defned as separate OPTIONAL features.
Noveck Expires 28 October 2024 [Page 32]
Internet-Draft Nfsv4 ACLs April 2024
* There is no way clients can take advantage of the greater
flexibility provided by the NFSv4 ACL model because specifications
have been written to allow the greater flexibility not to be
implemented. As a result, only the UNIX ACL subset can be used
with some assurance that the necessary facilities are implemented.
* It is hard to provide support for and to use the UNIX ACL subset,
because of the degree to which implementors need to involve
themelves with details that they hane no chance of ever dealing
with.
* Given the existing sitution, server implementers have no
motivation to provide support for the extensions, since, even if
they did, there would be no ways that software could be written to
take advantage of that work.
* In addition, It is difficult for implementers to get resource to
invest in feature development, when it has been made so unclear
that there is a set of features to implement. As a result of the
lack of recognition of the NFSv4 ACL as OPTIONAL features, the
lack of tese features appear as a quality-of-implementtion issues
which it is hard to get allocate resource to address, since user
expectation in this area continue to be limited.
4.2. ACL Semantics Choices
[Consensus Needed, Including List (Items #61e, #105g, #110d)]: There
are a range of potential authorization models that can be supported
using the Acl and Dacl attributes:
* UNIX ACLs, based on the withdrawn POSIX ACL draft.
This approach retains the three bits typical of POSIX semantics
and maps them, with a number of implied restrictions, to a subset
of the more expansive set of ACE mask bits defined in Section 5.2.
* Full NFSv4 ACLs, with expanded semantics derived from Windows
ACLs.
This includes a finer-grained permissions model, the inclusion of
DENY ACEs, and the use of ACLs for non-authorization functions,
via the use of AUDIT and ALARM ACEs, and a number of features
related to ACL inheritance.
* Various hybrids of the two models, supporting some, but mot all of
the extensions to UNIX ACLs introduced in earlier minor version
specifications.
Noveck Expires 28 October 2024 [Page 33]
Internet-Draft Nfsv4 ACLs April 2024
The new Aclfeature attribute, available as an extension in
NFSv4.2, allows the client to determine which extensions are
implemented for a particular file system. See xref target="ACL-
sem-discovery"/> for further discussion.
Where this feature is not available, including NFSv4.0 and
NFSv4.1, information on the extensions supported can be inferred
based on the value of the Aclsupport attribute. See xref
target="ACL-sem-inference"/> for details.
In all of these cases the client can rely on the fact that the
core features derived from UNIX ACLs are always available when the
Acl or Dacl attributes are supported.
[Author Aside, Including List (Items #30a, #61e, #105g, #110d)]:
Earlier specifications of the ACL feature allowed servers to provide
any of these semantic models. Unfortunately, the server was not
given an explicit choice and the client has no way of determing the
semantics associated with the ACL and adapting accordingly. Instead
the approach was to widen the range of permissible server behavior to
be implemented for ACLs, so it included both sorts of ACL semantics,
various hybrids unlikely to be implemented, as welll as a lot of
miscellaneous variants, many probably unintended, as well.
* The keyword SHOULD was used for just about every element of ACL
semantics, without proper attention to the meaning of that term as
defined in [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
consequences of doing so.
The result was to effectively replace a single MAY by a lare
number instances of SHOULD each treated essentially as MAY with an
exponential expansion of the number behaviors a client would have
to be prepared for.
* In many cases, the use of SHOULD with the implied meaning MAY,
leaves open more than two possiilities since it is not always
clear what restictions apply to the case in which the
recommendation is bypassed.
As a result, the number of notionally valid server behaviors can
expand even beyond the exponential increase discuused above.
Noveck Expires 28 October 2024 [Page 34]
Internet-Draft Nfsv4 ACLs April 2024
* 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.
In many cases, An alternate method is introduced by stating that
"Some server implementations" do a particular thing, without any
discussion of the effect on interoperability, although it does say
that "implementations are discouraged" from doing this. Although
Section 6.4 of [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.3. Discovery of ACL Semantics
[Consensus Needed (Items #105h, #110e)]: The OPTIONAL attribute
Aclfeature defined as an NFSv4.2 extension (see Section 3.6 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:
1. The support for ACE mask bits (see Section 5.2 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 5.2.3, there are flags withing the Aclfeature attribute
that indicates whether the additional mask bits defined in
Sections 5.2.4, 5.2.5, and 5.2.6 are supported as well.
Additional mask bits will be definable as later extensions as
described in Section 5.2.9 to support new features and improve
granulrity. To enable smoother transitions to use of newer bits
the set of supported mask bits and those that can be stored abd
retriedved but not supported are separately specifiable.
2. The inclusion of support for ACE types in addition to
ACE4_ACCESS_ALLOWED_ACE_TYPE is deteminabe using the Aclsupport
attribute. In addition, the AclFeature attribute allows the
client to determine the set of ACE types that, while not
supported, can be stored and retrieved.
Noveck Expires 28 October 2024 [Page 35]
Internet-Draft Nfsv4 ACLs April 2024
When the AclFeature attribute is available additional ACE may be
defined, as described in Section 5.1.3.
3. Although it is clear that the ACE flags are intended to be
OPTIONAL, that term is not used and there is not any way of
determining whethe support for each of these is present as there
should be for such features.
Instead the optionality is conveyed by simply saying server "need
not" support any of these flags. To further complicate the
feature discovery process, previous discussion of these flags
contain the following statement:
If the server supports flags that are similar to, but not
exactly the same as, these flags, the implementation may
define a mapping between the protocol-defined flags and the
implementation-defined flags.
There is no way for the client to be aware of such an
implementation-defined mapping, even if there were a reasonable
definition flag being "similar".
When the AclFeature attribute is available the client can
determine the set of supported flags from information provided by
the server including informing the client of case in which acl
inheritence for file and directorties is supported but the two
options are not separable.
4. Regarding the flags in the sacl and dacl attributes, the existing
v4.1 specification is not altogether clear about whether these
are OPTIONAL or not. However, one can conclude that the protocol
needs to allow non-support of these features if only to allow
their use, which is recommended for all, in the ccase of servers
supporting the UNIX ACL model, which has no inheritance
provisions at all.
When the AclFeature attribute is available the client can
determine whether support is present by checking the
AF4FLAG_INHAUTO flag within the flword field of the Aclfeature
atrribute.
5. Section 5.4 defines a number of specual who values, in addition
to OWNER@, GROUP@, and EVERYON@, that can reasonably be assumed
to be OPTIONAL.
So far, no server implementations of these have been found, and
one cannot be sure any exist. Additionally, it is likely that
cliets using these do not exist.
Noveck Expires 28 October 2024 [Page 36]
Internet-Draft Nfsv4 ACLs April 2024
When the Aclfeature attribute is available, the presence of
support for these "special" who values is indicated by flags bits
within whoword field of the attribute. Similarly, there are also
flags that indicate whether such special values, when not
supported, can be stored and then returned when interrogated.
The details of support discovery are defined in subsections of
Section 5. Items one and two are dealt with in Sections 5.2.7 5.1.2
respectively, three and four delt with inn 5.3.2 while items five and
six are dealt wiith in Section 5.4.1.
4.4. Inferring ACL Semantics
In cases in which the Aclfeature attribute is not supported,
including use of minor versions for which it is not defined (i.e.
minor versions below two), there are ways to determine the extensions
supported. It is important to note that these methods, while
sometime helpful, have important limitations that make imlementation
of Aclfeature desirable, where this option is available:
* Testing for support of mask bits by attempting to set vaious masks
bit is a lengthy process, which might not be reasonably done on
crossing fs booundaries.
* In many cases, testing for support of particular features has been
made unreliable because of a laxness of specification language,
most often by use of "SHOULD" in calling for an error return.
* Similarly, in many cases, an error return cannot be relied upon
becayse the server is allowed to accept ACEs that it cannot
suppport, simply because it can store them and return them.
In any case, each of the following areas of support discovery
provided has some correlate in which inferences can be drawn given
available information. In some cases, these infernce ar sufficient
to provide the needed information while in others they are limited in
various ways, so that they can only be used in limited cirsumsances
or supplemented by other sorts of knowledge about server
characteristics. The following list the area of support discovery,
most desirably provided by the Aclfeature attribute.
* There are only limited facilities to determine te set of mask bits
supported. However, given the REQUIRED character of the mask bits
defined in Section 5.2.3 and knowledge of the choice of ACL model
we have something that will probably support the needs of existing
clients.
Noveck Expires 28 October 2024 [Page 37]
Internet-Draft Nfsv4 ACLs April 2024
In the case in which it it can be inferred that support for the
UNIX ACL model is provided, it is reasonable to suppose that ACE
mask bits other than those defined in Section 5.2.3 are not
supported.
[Author Aside (Item #113a)]: We neeed to clarify what clients
neeed to do in this case. Intend to wait until we see results
from experiments.
For servers supporting the NFSv4 ACL model, and certain hybrids
support could only be determined by testing various ACE mask
combinations in ACLs to be set. As this is unlikely to be
ppractical, clients only needing facilities provided by the UNIX
ACL model could handle things as is done with servers supporting
the UNIX ACL model. Those needing could only operate as they do
today, by depending on externally obtained knowledge about the
server bein used, i.e., non-interoperably.
* Information about support for various ACE types is provided by the
aclsupport attribute.
Unfortunately, the aclsupport attribute is OPTIONAL and will
remain so at least until NFSv3. This is of particular concern
since all attempts to infer the ACL model supported depend on the
set of ACE types supported and asking client to try particular
ACLs containing particlar ACE types when entering a file system is
probably not viable.
* Support for flags within the ACE can only be determined by
attempting to use those flags and seeing if NFS4ERR_ATTRNOTSUP is
returned. The same applies to the flags for the automatic
inheritence features in the dacl andsacl attributes
As that is unlikely to be practical, clients are likely to use the
inferred ACl model to simplify the process, It can be asssumed
that a server supporting the UNIX ACL model does not support any
of the ACE flags or any of the automatic ACL inheritance flags,
Clients that do not need any of these featues including those that
only need UNIX ACL features do not need the information. For
those that do need that information, their only option is to
depend on externally derived information about server support of
flags to enble use, albeit non-onteroperably.
* There are no means by which the presene of support for various
special who values other than by attempting to set aACEs using
them and seeing if NFS4ERR_BADOWNER is returned.
Noveck Expires 28 October 2024 [Page 38]
Internet-Draft Nfsv4 ACLs April 2024
As this is likely to be impractical it is unlikely to be done. In
practical terms however, tis is unlikely to be importnt since
clients using these might not exist and any that did would be
relying on externally obtained knowledge about the server to
obtain the function in a non-onteroperale fashion.
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;
struct nfsace4 {
acetype4 type;
aceflag4 flag;
acemask4 access_mask;
utf8str_mixed who;
};
5.1. ACE Type
5.1.1. Existing ACE Types
The constants used for the type field (acetype4) and as shifts used
in determining ACE type support are as follows:
const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000;
const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001;
const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002;
const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003;
All four are permitted in the Acl attribute. For NFSv4.1 and beyond,
only the ALLOWED and DENIED types are used in the Dacl attribute, and
only the AUDIT and ALARM types are used in the Sacl attribute.
Noveck Expires 28 October 2024 [Page 39]
Internet-Draft Nfsv4 ACLs April 2024
+==============================+==============+=====================+
| Value | Abbreviation | Description |
+==============================+==============+=====================+
| ACE4_ACCESS_ALLOWED_ACE_TYPE | ALLOW | Explicitly grants |
| | | the ability to |
| | | perform the set of |
| | | actions specified |
| | | in acemask4 to the |
| | | file or directory. |
| | | |
| | | When all such |
| | | actions to be done |
| | | by a given |
| | | operation are |
| | | explicitly |
| | | allowed, the |
| | | operation is |
| | | authorized and |
| | | scanning of the |
| | | ACL to dtermine |
| | | authorization |
| | | stops. |
+------------------------------+--------------+---------------------+
| ACE4_ACCESS_DENIED_ACE_TYPE | DENY | Explicitly denies |
| | | the ability to |
| | | perform the set of |
| | | actions specified |
| | | in acemask4 to the |
| | | file or directory. |
| | | |
| | | When any of the |
| | | actions to be done |
| | | by a given |
| | | operation are |
| | | explcitly denied, |
| | | the operation is |
| | | unauthorized and |
| | | scanning ofthe ACL |
| | | to determine |
| | | authoriztion |
| | | stops. |
+------------------------------+--------------+---------------------+
| ACE4_SYSTEM_AUDIT_ACE_TYPE | AUDIT | Logs (in a system- |
| | | dependent way) any |
| | | attempt to |
| | | perform, for the |
| | | file or directory, |
| | | any of the actions |
Noveck Expires 28 October 2024 [Page 40]
Internet-Draft Nfsv4 ACLs April 2024
| | | specified in |
| | | acemask4. |
+------------------------------+--------------+---------------------+
| ACE4_SYSTEM_ALARM_ACE_TYPE | ALARM | Generates (in a |
| | | system-dependent |
| | | way) an alarm upon |
| | | any attempt to |
| | | perform, for the |
| | | file or directory, |
| | | any of the actions |
| | | specified in |
| | | acemask4. |
+------------------------------+--------------+---------------------+
Table 2
The "Abbreviation" column denotes how the types will be referred to
throughout the rest of this document.
5.1.2. ACE Type Support Discovery
[Consensus needed (Item #105i), through end of section]:
Discovery of the ACE types that it is appropriate to use can occur in
two ways:
* By use of the OPTIONAL attribute Aclsupport, the set of supported
ACE types can be determined.
This set is limited to ACE types defined in Section 5.1.1and
cannot be extended.
* By use of the OPTIONAL attribute Aclfeature, the set of supported
ACE types can be determined together with a potentially larger set
of ACE types that can be set and retriedved without necessarily
being supported.
These sets can include ACE types defined by protocol extensions as
described in Section 5.1.3 as well as those defined in
Section 5.1.1.
When neither of these attribute values are available, the client has
no way of determining the ACE types supported and when attempting the
use of ACE tpes other than ALLOW needs to be prepared for a failure
due to non-support. Similarly, when the Aclfeature attribute is not
supported, clients attempting to use ACE types other than those
defined in Section 5.1.1, need to be prepared for failure to be
returned due to non-support.
Noveck Expires 28 October 2024 [Page 41]
Internet-Draft Nfsv4 ACLs April 2024
Within the Aclfeature value, words of type af4typemask are analyzed
using the definitions below to determine the sets of types which are
supported or are storeable without necessarily being supported.
const AF4TYPE_GSUPPMASK = 0x000003ff;
const AF4TYPE_BSUPPMASK = 0x000ffc00;
const AF4TYPE_STOREMASK = 0x3ff00000;
const AF4TYPE_GSUPPSHIFT = 0;
const AF4TYPE_BSUPPSHIFT = 10;
const AF4TYPE_GSTORESHIFT = 20;
The bits within the AF4TYPE_GSUPPMASK and AF4TYPE_BSUPPMASK values
each represent support for a specfic ACE type using the value one
left-shifted by the numeric value of the ACE type plus the associated
shift for the field. Separate masks are used for types for which the
support is accord with the recommendations of this document
(AF4TYPE_GSUPPMASK, AF4TYPE_GSUPPSHIFT) and for those that do not so
conform, relying on the more relaxed treatment within previous
specfications (AF4TYPE_BSUPPMASK, AF4TYPE_BSUPPSHIFT). Similarly,
the bits within the AF4TYPE_STOREMASK value each reprsent the ability
to store and return a specfic ACE type using the value one left-
shifted by a number of bis equal to the numeric v value of the ACE
type plus twenty.
5.1.3. ACE Type Extensiion
[Consensus needed (Item #105j), through end of section]:
Standards-track docments which define NFSv4 protocol extensions, as
provided for in [RFC8178], can extend the set of ACE types. The
definition of a new extension type needs to provide the following
information:
* An ACE type name, genenerally of the form ACE4_???_????_ACE_TYPE
which is to be used to define ACEs of the specfifed type, when
appearing in the type fields of the ACE.
* A numeric value between four and nine that has not been previously
used as an ACE type value.
While it is theoretically possible to delete a previously defined
ACE type as part of a new minor version, the practical
difficulties that result from these being stored within existing
file systems require that such numeric values not be reused.
* An abbreviation to be used when referring to that ACE type.
Noveck Expires 28 October 2024 [Page 42]
Internet-Draft Nfsv4 ACLs April 2024
* A decription of the effect of the ACEs of the specified type
within ACL. This needs to inlude, for ACE types that can appear
within existing ACL-based attributes, how the presence of the ACE
affects existing scans of ACL-based attributes such as an
authorization scan or a notification scan in response to action
successfully or unsuccessfully attempted.
* Description of the set of attributes in which the ACE type can
appear which can include Acl, Dacl, Sacl, and new attributes added
in the same or previous extensions.
5.2. ACE Access Mask
The following bitmask constants can be used within the access mask
field of the ACE.
const ACE4_READ_DATA = 0x00000001;
const ACE4_LIST_DIRECTORY = 0x00000001;
const ACE4_WRITE_DATA = 0x00000002;
const ACE4_ADD_FILE = 0x00000002;
const ACE4_APPEND_DATA = 0x00000004;
const ACE4_ADD_SUBDIRECTORY = 0x00000004;
const ACE4_READ_NAMED_ATTRS = 0x00000008;
const ACE4_WRITE_NAMED_ATTRS = 0x00000010;
const ACE4_EXECUTE = 0x00000020;
const ACE4_DELETE_CHILD = 0x00000040;
const ACE4_READ_ATTRIBUTES = 0x00000080;
const ACE4_WRITE_ATTRIBUTES = 0x00000100;
const ACE4_WRITE_RETENTION = 0x00000200;
const ACE4_WRITE_RETENTION_HOLD = 0x00000400;
const ACE4_DELETE = 0x00010000;
const ACE4_READ_ACL = 0x00020000;
const ACE4_WRITE_ACL = 0x00040000;
const ACE4_WRITE_OWNER = 0x00080000;
const ACE4_SYNCHRONIZE = 0x00100000;
Note that some masks have coincident values, or are treated
differently when used with different types of objects. For example,
ACE4_READ_DATA and ACE4_LIST_DIRECTORY designate the same mask bit
which is treated differently depeding on whether the object is a
directory or other type of object. Note that,
* The mask value names ACE4_ADD_FILE, ACE4_ADD_SUBDIRECTORY, and
ACE4_DELETE_CHILD are intended to be used with directory objects
that are not named attribute directories and are not supported
when used with objects of other types.
Noveck Expires 28 October 2024 [Page 43]
Internet-Draft Nfsv4 ACLs April 2024
* The mask value came ACE4_APPEND_DATA is intended to be used with
non-directory objects.
* The mask values used for ACE4_READ_DATA and ACE4_LIST_DIRECTORY
designate the same mask bit is which treated differently depeding
on whether the object is a named attribute directory a sirectory
which is not a named attribute directory, or other type of object.
The mask values for ACE4_WRITE_DATA and ACE4_ADD_FILE behave
similarly as do the mask values for ACE4_APPEND_DATA and
ACE4_ADD_SUBDIRECTORY.
* The mask bit designated by ACE4_EXECUTE controls two different
sets of action depending on whether the underlying object is a
directory.
[Consensus Needed (Items #102a, #103a), through end of list]: These
mask bit are explained in more detail in the sections mentioned below
based on their relationshup to the three POSIX-derived permission
bits: Read, Write, and Execute. Changes include material in multiple
subsections of Section 5.2.
* Mask bits whose set of authorized actions corresponds to a single
POSIX-drived permission bit are explained in Section 5.2.3.
These mask bits are always to be supported although the set of
authorized actions is expected to be smaller when other mask bits
covering a smaller set of actions are supported.
* Mask bits whose set of authorized actions is a subset of those
normally controlled by a single POSIX-drived permission bit are
explained in Section 5.2.4.
These mask bits are not always supported, but depend on ACL
extensions supported by the server. For detailed guidance
regarding how the client can determine which mask bits are
supported, see Sections 4.3 and 4.4.
* 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 5.2.5.
This section includes mask bits for which we have found existing
implementations. These mask bits are not always supported, but
clients need to be prepared for support actually present depending
on the set of ACL extensions supported.
Noveck Expires 28 October 2024 [Page 44]
Internet-Draft Nfsv4 ACLs April 2024
[Author aside (Item #111a)]: The following parapgraph has to be
considered tentiative for now, at least until some implementation
of this bit isfound or it is determined that none exist.
In at least one case, that of ACE4_READ_NAMED_ATTRIBUTES, we
include a mask bit for which no implementation has yet been found.
Although, the specific details differ from those in existing
specifications, change has been necessary to appropriately co-
ordinate handling of actions controlled by this bit, with the
corresponding handling when POSIX authorization is in effect or
when UNIX ACLs are supported.
* Mask bits defined in existing specfication but for which no
corresponding imlementation has yet been found are explained in
Section 5.2.6.
[Consensus Needed (Item #5a) The descriptions in the section below
are relevant to both authoriztion and for recognizing operations
whose success or failure are to be recorded when ACL are used for the
non-authorization functions described in Section 9. With regard to
ACCESS whose returned bits are affected, it is not necessarily the
case that the occurrence of ACCESS in these lists implies that such
operations are recordable events.
[Consensus Needed (Item #4c)]: While it s recommended that The sets
of actions to be authorized or otherwise noted in connecton with
these mask bits be those cited in the sections below, it is possible
that existng implementations might behave differently, based on their
earlier reliance on earlier specfications and a common understanding
within the working group that it was the job of the specification to
conform to the implementation, rather than the other way around. See
Section 5.2.7 for information about how the client is to be made
aware of such discordant implementations.
5.2.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:
Noveck Expires 28 October 2024 [Page 45]
Internet-Draft Nfsv4 ACLs April 2024
* [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 #4d)]: In a large number of places, SHOULD is
used inappropriately, since there appear to be no valid reasons to
allow a server to ignore what might well be a requirement. Such
changes are not always noted individually below. However, they
will be considered, here and in 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.
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.
Noveck Expires 28 October 2024 [Page 46]
Internet-Draft Nfsv4 ACLs April 2024
* Revisions in handling of the masks WRITE_RETENTION and
WRITE_RETENTION_HOLD. These are parts of consensus items #10.
5.2.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 #62a)]: Despite the fact that NFSv4 ACLs and mode
bits are separate means of authorization, it has been necessary, even
if only for the purpose of providing compatibility with earlier
implementations, to introduce the issue here, since reference to this
mode bit are necessary to resolve issues regard directory entry
deletion, as is done in Section 5.2.10.
[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.
* 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 5.2.10 is more restrictive than the
previous one appearing in Section 5.2.11. 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.
Noveck Expires 28 October 2024 [Page 47]
Internet-Draft Nfsv4 ACLs April 2024
* The handling of this mode bit was not documented in previous
specifications. However, there is a preliminary attempt to do so
in Section 5.3.1 of [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.
5.2.3. Uses of Core Mask Bits
[Consensus Needed (Items #4e, #5a, #7b, #8b, #106a, #107a, #108a,
#109a), Throughout section]
ACE4_READ_DATA (for non-directory objects)
Operation(s) affected:
READ
[Consensus Needed (Item #101a)]: READLINK
OPEN (for read or read-write)
ACCESS (ACCESS4_READ)
Discussion:
The action of reading the data of the file, or, in some cases,
providing necessary preparation to do so.
[Previous Treatment (Items #4e, #7b)]: Servers SHOULD allow a
user the ability to read the data of the file when only the
ACE4_EXECUTE access mask bit is allowed.
[Author Aside (Item #7b)]: The treatment needs to be clarified
to make it appropriate to all ACE types.
Noveck Expires 28 October 2024 [Page 48]
Internet-Draft Nfsv4 ACLs April 2024
[Consensus Needed (Items #4e, #7b)]: When used to handle READ
or OPEN operations, the handling MUST be identical whether this
bit, ACE4_EXECUTE, or both are present, as the server has no
way of determining whether a file is being read for execution
are not. The only occasion for different handling is in
construction of a corresponding mode or in responding to the
ACCESS operation.
ACE4_LIST_DIRECTORY (for directories which are not named attribute
directories)
Operation(s) affected:
WRITE
OPEN (for write or read-write)
ACCESS (ACCESS_MODIFY)
ACCESS (ACCESS_EXTEND)
- Only when ACE4_EXTEND_DATA in not supported.
ACCESS (ACCESS_DELETE)
- Only when ACE4_DELETE in not supported.
SETATTR of size (extension)
- Only when ACE4_EXTEND_DATA in not supported.
SETATTR of size (truncation)
Discussion:
[Author Aside (Item #8b)]: Needs to be revised to deal with
issues related to the interaction of WRITE_DATA and
APPEND_DATA.
[Consensus Needed (Item #8b)]: The action of modifying existing
data bytes within a file's current data. When ACE4_APPEND_DATA
is not supported, the action of extending a file's, data (e.g.
by a WRITE which extends EOF, is included as well
Noveck Expires 28 October 2024 [Page 49]
Internet-Draft Nfsv4 ACLs April 2024
[Consensus Needed (Item #8b)]: As there is no way for the
server to decide, in processing an OPEN or ACCESS request,
whether subsequent WRITEs will extend the file or not, the
server will, in processing an OPEN treat masks containing only
WRITE_DATA, only APPEND_DATA, or both bits, in identical
fashion. The result of ACCESS will reflect the individal
authorizations to overwrite existing bytes and to extend the
file.
[Consensus Needed (Item #8b)]: In processing a WRITE request,
the server is presumed to have the ability to determine whether
the current request extends the file and whether it modifies
bytes already in the file.
[Consensus Needed (Item #8b)]: ACE4_WRITE_DATA is required to
process a WRITE which spans pre-existing bytes in the file,
whether the file is extended or not.
ACE4_LIST_DIRECTORY (for named attribute directories)
Operation(s) affected:
All operations normally controlled by
ACE4_READ_NAMED_ATTRIBUTES are contrlled by ACE4_LIST_DIRECTORY
when ACE4_READ_NAMED_ATTRIBUTES is not supported.
Discussion:
[Consensus Needed (Item #111b)]: Through rest of this entry
In order to adapt authorization of operations on named
attribute directories to POSIX permission concepts as refleted
in UNIX ACLs which have no support for name attributes, the
actual control of authorization for the covered actions depends
on this bit ored with ACE4_EXECUTE.
As a result these actions are allowed if either bit is specfied
as allowed while they can be disallowed only if neither bit is
specfoed as allowed or both bits are specified as denied.
ACE4_WRITE_DATA (for directories)
Operation(s) affected (only including named attribute
directories when ACE4_WRITE_BAMED_ATTRIBUTES is not supported)
CREATE
- Will require ACE4_ADD_FILE, ACE4_ADD_SUBDIRECTORY, when
these are supported.
LINK
Noveck Expires 28 October 2024 [Page 50]
Internet-Draft Nfsv4 ACLs April 2024
OPEN (which creates file in the directory)
ACCESS (ACCESS4_EXTEND)
REMOVE (may require ACE4_DELETE_CHIILD, when supported
RENAME (on the target drectory)
Discussion:
Operations which modify a directory
Many of these operations may controlled at a finer granularity,
when the appropriate mask bits are supported.
ACE4_WRITE_DATA (for all object types)
Operation(s) affected (only when ACE4_WRITE_NAMED-ATTRIBUTES is
ot supported):
OPENATTR (when createdir is true)
Discussion:
[Consensus Needed (Item #111b)]: Through rest of this entry
This acton is normally controlled by
ACE4_WRITE_NAMED_ATTRIBUTES, but need to be controlled by
ACE4_WRITE_DATA when the former is not supported (e.g. when
UNIC ACLs are provided by the server.
ACE4_EXECUTE (for non-diectory objects)
Operation(s) affected:
READ
OPEN (for read or read-write)
ACCESS (ACCESS4_EXECUTE)
REMOVE
RENAME
LINK
CREATE
Discussion:
The action of reading a file in order to execute it.
Noveck Expires 28 October 2024 [Page 51]
Internet-Draft Nfsv4 ACLs April 2024
Servers MUST allow a user the ability to read the data of the
file when only the ACE4_EXECUTE access mask bit is allowed.
This is because there is no way to execute a file without
reading the contents. Though a server may treat ACE4_EXECUTE
and ACE4_READ_DATA bits identically when deciding to permit a
READ or OPEN operation, it MUST still allow the two bits to be
set independently in NFSv4 ACLs, and distinguish between them
when replying to ACCESS operations. In particular, servers
MUST NOT silently turn on one of the two bits when the other is
set, as that would make it impossible for the client to
correctly enforce the distinction between read and execute
permissions.
As an example, following a SETATTR of the following NFSv4 ACL:
nfsuser:ACE4_EXECUTE:ALLOW
A subsequent GETATTR of acl attribute for that file will
return:
nfsuser:ACE4_EXECUTE:ALLOW
and MUST NOT return:
nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW
ACE4_EXECUTE (for directories which are not named attribute
directories)
Operation(s) affected:
LOOKUP
ACCESS(ACCESS4_LOOKUP)
Discussion:
The action of traversing directory by searching for a
particular named item.
ACE4_EXECUTE (for named attribute directories)
Operation(s) affected:
All operations normally controlled by
ACE4_READ_NAMED_ATTRIBUTES are contrlled by ACE4_EXECUTE when
ACE4_READ_NAMED_ATTRIBUTES is not supported.
Discussion:
[Consensus Needed (Item #111b)]: Through rest of this entry
Noveck Expires 28 October 2024 [Page 52]
Internet-Draft Nfsv4 ACLs April 2024
In order to adapt authorization of operations on named
attribute directories to POSIX permission concepts as refleted
in UNIX ACLs which have no support for name attributes, the
actual control of authorization for the covered actions depends
on this bit ored with ACE4_LIST_DIRECTORY.
As a result these actions are allowed if either bit is specfied
as allowed while they can be disallowed only if neither bit is
specified as allowed or both bits are specified as denied.
5.2.4. Uses of Finer-grained Mask Bits Derived from Write
[Consensus Needed (Item #103x), Through the end of the following
list]: The mask bits presented in this section all control some
subset of the actions controlled by the write permission bit when
POSIX auhorizattion is in effect. These mask bits, when fully
supported, provide for finer-grained control of authorization
decisions. The corresponding ACE mask bit, ACE4_WRITE_DATA, still
control actions for which no corresponding mask bit defined in this
section provides for finer-grained control.
Although obect deletion is controlled by ACE4_DELETE for all types of
objects, the situation is different for directories and for on-
directory objects:
* For non-directory objects, once file deletions are excluded, all
actions can be divided into those controlled by ACE4_WRITE_DATA
and those controlled by ACE4_APPEND_DATA.
While separate control of these two bits is not available on
severs implementing UNIX ACLs, it appears that there will also be
servers more oriented to the NFSv4 ACL model, that do not
distinguish these either. As a result, clients that need control
of these to be distinct need to use the facilities described in
Section 5.2.7 to ensure that such support is available before
relying on different treatment for these two action subsets.
* For directories, many actions are subject to finer-grained control
when the mask bit defined in this section are implemented. These
include ACE4_ADD_FILE, ACE4_ADD_SUBDIRECTORY, ACE4_DELETE_CHILD.
Noveck Expires 28 October 2024 [Page 53]
Internet-Draft Nfsv4 ACLs April 2024
[Author Aside (Item #9b)]: The handling of RENAME in disngushing
crosss-directory and within-diretory RENAME options has to be
considered tentative. However, even though this is ifferent from
previous treatments of the issue needs to be carefully considered
by the working group. This is primrily because there seems to be
no clear motivation for the previous treatment and because it
seems unlikely that restrictions on adding or deleting objects
would necessitate corresponding restrictions on renaming them, in
case in which the directory was not read-only.
[Consensus Needed (Item #9b)]: Even when all the above bits are
fully supported, the action of renaming a file or directory is
controlled by ACE4_WRITE_DATA for the enclosing directory.
[Consensus Needed (Items #4f, #5a, #7b, #8b, #101a, #106a, #107a,
#108a, #109a), Throughout rest of section]
ACE4_ADD_FILE (For directories)
Operation(s) affected:
CREATE
LINK
OPEN (when creating a new file)
RENAME (in the cross-directory case)
Discussion:
The action of adding a new file in a directory. The CREATE
operation is affected when nfs_ftype4 is NF4LNK, NF4BLK,
NF4CHR, NF4SOCK, or NF4FIFO. (NF4DIR is not included because
it is covered by ACE4_ADD_SUBDIRECTORY.) OPEN is affected when
used to create a regular file. LINK is always affected and
RENAME is affected when a file/directory is moved betweewn
directories, with ACE4_ADD_SUBDIRECTORY covering the case when
a directory is renmed betweeen directories.
ACE4_APPEND_DATA (For non-directory objects)
Operation(s) affected:
WRITE
ACCESS
OPEN
SETATTR of size
Noveck Expires 28 October 2024 [Page 54]
Internet-Draft Nfsv4 ACLs April 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 #8c)]: As there is no way for the
server to decide, in processing an OPEN or ACCESS request,
whether subsequent WRITEs will extend the file or not, the
server will treat masks containing only WRITE_DATA, only
APPEND_DATA or both, identically.
[Consensus Needed (Item #8c)]: If the server is processing a
WRITE request and the area to be written extends beyond the
existing EOF of the file then the state of APPEND_DATA mask bit
is consulted to determine whether the operation is permitted or
whether alarm or audit activities are to be performed. If a
file has an NFSv4 ACL allowing only APPEND_DATA (and not
WRITE_DATA) and a WRITE request is made at an offset below EOF,
the server MUST return NFS4ERR_ACCESS.
[Consensus Needed (Item #8c)]: If the server is processing a
WRITE request and the area to be written does not extend beyond
the existing EOF of the file then the state of APPEND_DATA mask
bit does not need to be consulted to determine whether the
operation is permitted or whether alarm or audit activities are
to be performed. In this case, only the WRITE_DATA mask bit
needs to be checked to determine whether the WRITE is
authorized.
ACE4_ADD_SUBDIRECTORY (For directories)
Operation(s) affected:
CREATE
RENAME (in the cross-directory case)
Discussion:
[Author Aside]: The RENAME cases need to be limited to the
renaming of directories, rather than saying, "The RENAME
operation is always affected."
Noveck Expires 28 October 2024 [Page 55]
Internet-Draft Nfsv4 ACLs April 2024
[Consensus Needed (Item #9b)]: The action of creating a
subdirectory in a directory. The CREATE operation is affected
when nfs_ftype4 is NF4DIR. The RENAME operation is always
affected when directories are renamed and the target directory
NFSv4 ACL contains the mask bit ACE4_ADD_SUBDIRECTORY.
ACE4_DELETE_CHILD (For Directories)
Operation(s) affected:
REMOVE
RENAME (in the cross-directory case)
Discussion:
The action of deleting a file or directory within a directory.
See Section 5.2.10 for information on now ACE4_DELETE and
ACE4_DELETE_CHILD are to interact.
ACE4_DELETE (For all types of objects)
Operation(s) affected:
REMOVE
Discussion:
The action of deleting the associated file or directory. See
Section 5.2.10 for information on how ACE4_DELETE and
ACE4_DELETE_CHILD are to interact.
ACE4_WRITE_NAMED_ATTRS
Operation(s) affected, for all object types:
OPENATTR (when createdir is true)
Operation(s) affected, for named attribute directories:
CREATE
LINK
OPEN (which creates file in the directory)
ACCESS (ACCESS4_EXTEND)
REMOVE
RENAME
Discussion:
Noveck Expires 28 October 2024 [Page 56]
Internet-Draft Nfsv4 ACLs April 2024
The action of writing the named attributes of a file or of
creating a named attribute directory. OPENATTR is affected
when it is used to create a named attribute directory. This is
when createdir is TRUE.
[Author Aside (Item #111c)]: Despite the orgiginal intention
for this bit, it appears that the original scheme incoreectly,
allowed all sorts of chnges to name attributes as long as the
named attribute directory already existed. For this reason,
the current version changes that scheme even though no
implementtion supporting this mask bit has yet been found. In
the event one is found that follows the original scheme, the
working group will need to decide how to respond. One
possibiliy is to continue to recommened the approach here while
allowing that recommendation to be bypassed. When Aclfeatue is
supported, the desription of th support would indicate the non-
recommended character of the existing support.
The ability to check whether or not a named attribute directory
exists depends on the ability to look it up; therefore, users
also need the ACE4_READ_NAMED_ATTRS permission in order to
create a named attribute directory.
[Author Aside (Item #111a)]: Actually, they need that
permission to create a named attribute.
5.2.5. Uses of Other Additional Mask Bits
The mask bits discussed in this section all authorize actions, that,
in the absence of support for that bit mask bit, are not resolved by
one of the three POSIX-derived permission bits.
It is important to note this fact because prvious treatments of the
bit mask have strongly suggested that each bit is either identical to
a POSIX permission bit or controls a subset of one, as prt of a
system of controlling actions at a finer level of granularity. This
seems to exclude cases like the mask bits defined in this section and
in Section 5.2.6.
Where these bits are not supported, the authorization decision will
be arrived at, in one of the ways listed below, with the specifics
presented below as part of the discussion of that particular bit.
* The authorization can be controlled by file ownershiip.
* The authorization can be controlled by some boolean combination of
multiple permission bits or the mask bits that correspond to those
permission bits.
Noveck Expires 28 October 2024 [Page 57]
Internet-Draft Nfsv4 ACLs April 2024
* The authorization can be controlled by some boolean combination
file ownership and permission bits
[Consensus Needed (Item #102b)]: The authorization information
presented here is based on the only known implementtion of each of
the specified bits. Facilties need to be provided to allow the
specifics to be derived as part of mask support discovery.
ACE4_WRITE_ATTRIBUTES (for all object types)
Operation(s) affected:
SETATTR of time_access_set, time_backup, time_create,
time_modify_set, mimetype, hidden, system.
Discussion:
The action of changing the tims associated with a file or
directory to an arbitrary value. Also controls changing the
mimetype, hidden, and system attributes.
Implementation Informtion:
Acts as a finer-grained correlate of file ownership.
A user having ACE4_WRITE_DATA or ACE4_WRITE_ATTRIBUTES will be
allowed to set the times associated with a file to the current
server time.
ACE4_WRITE_ACL (for all object types)
Operation(s) affected:
SETATTR of acl and mode
Discussion:
The action of modifying the acl or mode attributes.
Implementation Informtion:
Acts as a finer-grained correlate of file ownership.
ACE4_WRITE_OWNER (for all object types)
Operation(s) affected:
SETATTR of owner and owner_group
Discussion:
The action of modifying the owner or owner_group attributes.
On UNIX systems, this done by executing chown() and chgrp().
Implementation Informtion:
Acts as a finer-grained correlate og file ownership.
Noveck Expires 28 October 2024 [Page 58]
Internet-Draft Nfsv4 ACLs April 2024
ACE4_READ_NAMED_ATTRS (for all object types)
Operation(s) affected:
OPENATTR
OPEN when the current fh is a named attribute directory(for
read or read-write)
ACCESS when the current fh is a named attribute directory
(ACCESS4_READ, ACCESS4_LOOKUP)
READDIR when the current fh is a named attribute directory
LOOKUP when the current fh is a named attribute cirectory
Discussion:
The action of reading the named attribute directory of a file
or of looking up a named attribute directory.
[Author Aside (Item #111d)]: It appears that this bit is
identical to the or of the read and execute privilege bits for
the named attribute directory. Unfortunatelly there is no way
to set the Mode attribute (or any attribute) of the named
attribute directory.
[Consensus needed (Item #111d): When this mask bit is not
supported, the actions normally controlled by it are controlled
by the or of the two mask bits ACE4_EXECUTE and
ACE4_LIST_DIRECTORY.
[Previous treatment (Item 111d)}: OPENATTR is affected when it
is not used to create a named attribute directory. This is
when 1) createdir is TRUE, but a named attribute directory
already exists, or 2) createdir is FALSE.
[Author Aside (Item #111d)]: The implication in the above
paragraph, the OPENATTR is not affected when it is used to
create a named directory troublesome, since, regardless of the
clients intentions, lookup acces in the named directory in
probably neessary.
ACE4_SYNCHRONIZE
Operation(s) affected:
NONE
Discussion:
Noveck Expires 28 October 2024 [Page 59]
Internet-Draft Nfsv4 ACLs April 2024
Permission to use the file object as a synchronization
primitive for interprocess communication. This permission is
not enforced or interpreted by the NFSv4.1 server on behalf of
the client.
Typically, the ACE4_SYNCHRONIZE permission is only meaningful
on local file systems, i.e., file systems not accessed via
NFSv4.1. The reason that the permission bit exists is that
some operating environments, such as Windows, use
ACE4_SYNCHRONIZE.
For example, if a client copies a file that has
ACE4_SYNCHRONIZE set from a local file system to an NFSv4.1
server, and then later copies the file from the NFSv4.1 server
to a local file system, it is likely that if ACE4_SYNCHRONIZE
was set in the original file, the client will want it set in
the second copy. The first copy will not have the permission
set unless the NFSv4.1 server has the means to set the
ACE4_SYNCHRONIZE bit. The second copy will not have the
permission set unless the NFSv4.1 server has the means to
retrieve the ACE4_SYNCHRONIZE bit.
Implementation Informtion:
In the only known implementation of this mask bit, its
effective setting, for ACEs for OWNER@, GROUP@, and
EVERYONE@,is derived by oring the three POSIX-derived privilege
bits for that who value.
5.2.6. Possible Uses of Additional Mask Bits
The mask bits discusssed in this section all have definitions in
exising specifications, but, so far, no substantive support for them
has been found. As a result, any discussion of these is tentative
and the working group will need to adjust approproately when
implementations are found or it is concluded that no such
implementations exist.
Implemetation of these mask bits are not yet pesent for various
reasons:
* In the case of ACE4_READ_ATTRIBUTES, it is because the
implementation investigated, while it does accept this bit in ACLs
and returns it as set or not appropriately it never uses this bit
to control authorization decisions
Noveck Expires 28 October 2024 [Page 60]
Internet-Draft Nfsv4 ACLs April 2024
[Author Aside (Item #112a)]: It does not seem likely that client-
side software would be prepared to deal effectively with a file
which could be looked up but whose attributes cannot be obtained.
As a result, it appears unlikly that more substantive
implementations will exist.
* In the cases of ACE4_WRITE_RETENTION and ACE4_WRITE_RETENTION, it
is because the implementation investigated does not contain
support for the secific OPTIONAL attributes affected.
[Author Aside (Items #10a, #11a)]: It does not appear that the
descrptions of the mask bits appearing below were fully thought
out before being incorporated as part of Proposed Standards. For
specfics, asides below will provide more detail. In any case, the
working group will need to think about replacements while avoiding
compatbility for any existing implementztions. Any replacement
needs to:
1. If separate bits for these are to be maintained and the server
is allowed to refer to a coarser-grained bit when when the
finer-rained bit is supported, the client needs a way to
determine,in advance, whether this will happen.
2. There needs to be some recognition of the fact that a
retention hold, by its nature needs to be protected from
arbitrary disablement as is likely to happen if the privileges
to modify these or to change authorization for their change,
is identical to privleges to establish them.
ACE4_READ_ATTRIBUTES (for all object types)
Operation(s) affected:
GETATTR of file system object attributes
VERIFY
NVERIFY
READDIR
Discussion:
The action of reading basic attributes (non-ACLs) of a file.
On a UNIX system, such basic attributes can be thought of as
the stat-level attributes. Allowing this access mask bit would
mean that the entity can execute "ls -l" and stat.
Noveck Expires 28 October 2024 [Page 61]
Internet-Draft Nfsv4 ACLs April 2024
[Author Aside (Items #11a, #112a)]: It is not clear that
existing clients are prepared to deal with denial of
authorization for such operations. As a result, if this mask
bit is retained, there need to be a way for clients to know, in
advance that such behavior is possible before proceding to use
the file system.
If a READDIR operation requests attributes, this mask needs to
be be allowed for the READDIR to succeed.
[Author Aside (Items #11a, #112a)]: The suggestion above needs
to be looked at closely. Even if it is justifiable to prevent
access to attribute values, failing the entire READDIR seems
unduly harsh. Returning an empty attribute set would be
preferable as there seems no justification for making it
impossible to get attributes for other files in the directory
simply because a single one is so constrained.
ACE4_WRITE_RETENTION (for all object types)
Operation(s) affected:
SETATTR of retention_set, retentevt_set.
Discussion:
The action of modifying the durations for event and non-event-
based retention. Also includes enabling event and non-event-
based retention.
[Previous Treatment]: A server MAY behave such that setting
ACE4_WRITE_ATTRIBUTES allows ACE4_WRITE_RETENTION.
[Author Aside]: The use of "MAY" here ignores the potential for
harm which unexpected modification of the associated attributes
might cause for security/compliance.
[Consensus Needed (Items #10a, #11a)]: If this mask bit is not
supported, the specfied action would be controlled by
ACE4_WRITE_ATTRIBUTES .
ACE4_WRITE_RETENTION_HOLD (for all obhect types)
Operation(s) affected:
SETATTR of retention_hold.
Discussion:
The action of modifying the administration retention holds.
Noveck Expires 28 October 2024 [Page 62]
Internet-Draft Nfsv4 ACLs April 2024
[Author Aside]: It seems that if multiple bits are to be
defined for this and ACE4_WRITE_RETENTION, there would be a
need to further restrict authorization for the modification of
administrative retetion holds.
[Previous Treatment]: A server MAY map ACE4_WRITE_ATTRIBUTES to
ACE_WRITE_RETENTION_HOLD.
[Author Aside]: The use of "MAY" here ignores the potential for
harm which unexpected modification of the associated attributes
might cause for security/compliance.
[Consensus Needed (Items #10a, #11a)]: If this mask bit is not
supported, the specfied action would be controlled by
ACE4_WRITE_ATTRIBUTES .
5.2.7. ACE Mask Support Discovery
Of the ACE mask bits defined above and those added later by
extensions as described in Section 5.2.9, support for most is
OPTIONAL. The only exceptions are for those discussed in
Section 5.2.3, which need to be supported whenever ACL-related
authorization attributes are supported.
When the the Aclfeature attribute is present, information about the
support of individual ACE mask bits aare provided as described in the
rest of this section. This information includes deermining which
bits are supported together with information clients ight need about
the nature of the support provided. When the Aclfeature attribute is
not supported, the client can obtain information about the support
for various ACE mask bits as descrbed in Section 5.2.8.
Within the Aclfeature attribute, individual af4minfo elements within
maskinf array, each specify the support characteristics of a set of
mask bits identified my the maskw field. The support characteristics
of that set of bits is provided by the corresponding maskw value,
which is structured as follows:"
Noveck Expires 28 October 2024 [Page 63]
Internet-Draft Nfsv4 ACLs April 2024
const ACLF4_MIM_SUPP = 0x00000007;
const ACLF4_MISH_SUPP = 0;
const ACLF4_MIBC_SUPP = 3;
const ACLF4_MIM_OTYPE = 0x00000018;
const ACLF4_MISH_OTYPE = 3;
const ACLF4_MIBC_OTYPE = 2;
const ACLF4_MIM_USES = 0x00000060;
const ACLF4_MISH_USES = 5;
const ACLF4_MIBC_USES = 2;
const ACLF4_MIM_BASIS = 0x07ffff80;
const ACLF4_MISH_BASIS = 7;
const ACLF4_MIBC_BASIS = 20;
const ACLF4_MIM_CSUPP = 0X18000000;
const ACLF4_MISH_CSUPP = 27;
const ACLF4_MIBC_CSUPP = 2;
This word is divided into the following bit fields, each of which has
constnats above defining the bit field mask, the shift count of the
field and the bit count of the field.
* The support field within ACLF4_MI*_SUPP indicates the level of
support provided for the associated mask bits specified in the
maskw word.
* The object-type-related bits within the field ACLF4_MI*_OTYPE
serve to qualify the mask bits witin the maskw word as applying to
directories, to non-directory objects, or to all objects.
* The uses-related bits within the field ACLF4_MI*_USES serve to
qualify the information about the mask bits the maskw word as
applying to their use in authorization, the non-authorization
functions described in Section 9, or to both sets of uses.
objects, or to both.
* The basis-related sub-fields within the field ACLF4_MI*_BASIS
identify the higher-level entities from which the specfied mask
bits' actions are taken and which provide authorizattion and
related functions when those mask bits are not supported.
This field is divided into the sub-fields ACLF4_MI*_BTYPE,
ACLF4_MI*_NUMB, ACLF4_MI*_BVAL, and ACLF4_MI*_BMASK, all of which
are explained below.
* The support-compliance-related bits within the field
ACLF4_MI*_CSUPP serve to indicate wheher the handling of
associated mask bits conforms to the recommendations of this
document.
Noveck Expires 28 October 2024 [Page 64]
Internet-Draft Nfsv4 ACLs April 2024
The support field uses the values defined below to communicate
information about the support for a set of masks as defined by the
mask word and the object-type field.
const ACLF4_MIF_SLREJECT = 0;
const ACLF4_MIF_SLIGNORE = 1;
const ACLF4_MIF_SLSUPP = 2;
const ACLF4_MIF_SLDEFAULT = 3;
const ACLF4_MIF_SLJOINED = 4;
The values which can be specified in the support field are listed
below. Each indicae a particular level of suppor for the mask bits
in maskw when used with object of type specified by the obect-type
field when used in acccord with the uses field.
* The value ACLF4_MIF_SLREJECT indicates that the mask bit specified
are invalid when used in ACEs of the associated ACE type for
objects of the specified types.
* The value ACLF4_MIF_SLIGNORE indicates that the mask bits
specified are ignored rather than being supported for objects of
the specified types.
For authorization-related uses, the covered actions are always
considered authorized and their appearance in ALLOW and DENY has
no affect
For other uses, the actions covered by the mask bits cannot be
specified for the actions indicated by AUDIT and ALARM ACEs, even
when those bits are present.
* The value ACLF4_MIF_SLSUPP indicates that the mask bits specified
are supported for objects of the specified types.
For the authorization of actions covered by the specified mask
bits, the appearance of these mask bits in ALLOW and DENY ACEs
controls the authorization of the action, which is authorized if
it appear in an applicable ALLOW ACE and never in an applicable
DENY ACE.
For other uses, the actions covered by the mask bits are dealt
with when they appear in AUDIT and ALARM ACEs.
The actions covered by the specified bits as supported is expected
to remove those actions from covrage by coarser-grained entities
that covers those actions when those mask bits are not supported.
See the detailed description of the basis-related sub-fields
below.
Noveck Expires 28 October 2024 [Page 65]
Internet-Draft Nfsv4 ACLs April 2024
* The value ACLF4_MIF_SLDEFAULT indicates that the mask bits
specified are partially supported for objects of the specified
types.
This partial support allows the mask buts to be specified in
ALLOW, DENY, AUDIT, and ALARM ACEs, just as is the case with
ACLF4_MIF_SLSUPP. However, the special deaulting behavior
associted with these masks often make their appearance in ALLOW
ACEs unnecessary.
Depending on the details of the basis-related field, the actions
covered by the specified bits as supported is expected to remove
those actions from covrage by coarser-grained entities that covers
those actions when those mask bits are not supported. In
addition, the basis-related field can specify a set of condition
for the default authoization behavior to be used when the specfied
mask bits are neither allowed nor denied. See the detailed
description of the basis-related sub-fields below.
* The value ACLF4_MIF_SLJOINED indicates handling similar to that
signified by ACLF4_MIF_SUPP but with one additional constraint.
When the set of selected mask its contains more than a single bit,
those setting ACEs containing any of those bits need to be sure
that they all have the same value, i.e. that if one of them is
set, so are all te rest. If this is not the case, the ACE MUST be
rejected.
const ACLF4_MIF_DIR = 0x00000008;
const ACLF4_MIF_NDIR = 0x00000010;
const ACLF4_MIF_OALL = 0x00000018;
The individual flags within ACLF4_MIM_OTYPE qualify the mask bits as
to whether they apply to directories, to non-directory objects or to
all objects. It is often necessary to describe hese separately
because the actions covered are different in the case of directories.
This can occur whther the same name is used for the mask bit as
applied to different objects or not.
* When the flag ACLF4_MIF_DIR is set the designated actions are
those defined as applying to the mask bits when used with
directories.
* When the flag ACLF4_MIF_NDIR is set the designated actions are
those defined as applying to the mask bits when used with non-
directory objects.
Noveck Expires 28 October 2024 [Page 66]
Internet-Draft Nfsv4 ACLs April 2024
* When the value ACLF4_MIF_OALL is used, both bits are set and the
bits in the specfied mask apply to all type of objects. This is
irrespective of whether the birs have the same names when aplied
to different types of objects or cover dfferent sets of actions
when aplied to different types of objects.
const ACLF4_MIF_UAUTH = 0x00000020;
const ACLF4_MIF_UOTHR = 0x00000040;
const ACLF4_MIF_UALL = 0x00000060;
The individual flags within ACLF4_MIM_USES qualify the entries as
applying to uses of the specified mask bits as to whther they apply
to operation authorization, to the non-authorizatio function
described in Section 9, or to all uses.
* When the flag ACLF4_MIF_UAUTH is set, the entry applies to the
specified mask bits appearing in ALLOW and DENY ACEs.
* When the flag ACLF4_MIF_UOTHR is set, the entry applies to the
specified mask bits appearing in AUDIT and ALARM ACEs.
* When the value ACLF4_MIF_UALL is used, both bits are set and the
bits in the specfied mask apply to all type ACEa.
The basis field ACLF4_MIM_BASIS is defined into a number of sub-
fields as described below. Some things to note:
* The definition for ACLF4_MIM_* and ACLF4_MISH_ are relative to the
word as a whole, rather than the basis field.
* Usage of many of these subfields is controlled by the value within
the ACLF4_MI*_BTYPE subfield.
const ACLF4_MIM_BTYPE = 0x00000380;
const ACLF4_MISH_BTYPE = 7;
const ACLF4_MIBC_BTYPE = 3;
const ACLF4_MIM_BNUMB = 0x00007c00;
const ACLF4_MISH_BNUMB = 10;
const ACLF4_MIBC_BNUMB = 5;
const ACLF4_MIM_BVAL = 0x001F8000;
const ACLF4_MISH_BVAL = 15;
const ACLF4_MIBC_BVAL = 6;
const ACLF4_MIM_BMASK = 0x07e00000;
const ACLF4_MISH_MASK = 21;
const ACLF4_MIBC_BMASK = 6;
Noveck Expires 28 October 2024 [Page 67]
Internet-Draft Nfsv4 ACLs April 2024
The three POSIX-derived privilege bits together with indication of
whether the file is bing accessed by its owner or by a member of the
owning group for the set of privilege bits. Each such bits has a
numeric value of the form ACLF4_MINP_* and a mask of the form
ACLF4_MIFP_*, used when t is necessary to define subset of such
privilege bits.
const ACLF4_MIFP_READ = 0x00000001;
const ACLF4_MINP_READ = 0;
const ACLF4_MIFP_WRITE = 0x00000002;
const ACLF4_MINP_WRITE = 1;
const ACLF4_MIFP_EXEC = 0x00000004;
const ACLF4_MINP_EXEC = 2;
const ACLF4_MIFP_OWNER = 0x00000008;
const ACLF4_MINP_OWNER = 3;
const ACLF4_MIFP_GROUP = 0x00000010;
const ACLF4_MINP_GROUP = 4;
The following basis sub-fields are defined. Together they are use to
define the hierarchical structure of actions, their classification by
mask ACE mask bits, and their derivation from specific privilege
bits, included, but not limited to the three POSIX-derived permission
bits, i.e. R, W, and X.
* The basis-type sub-field within ACLF4_MI*_BTYPE indicates the type
of basis specfication applying to the mask bits specified wiithin
the current entry.
The value in this sub-field controls how and whether the other
sub-fields are used.
* The basis-number sub-field within ACLF4_MI*_BNUMB indicates the
specific higher-level (i.e coarser-grained) entity of which the
sets of actions specfied by the assoated mask bits are a subset,
not necessarily proper.
This field can contain a mask bit number (i.e. the shift code of
an CE mask bit) or a privilege bit number, in the form of one of
the ACLF4_MINP_* constants.
* The basis-value sub-field within ACLF4_MI*_BVAL indicates a set of
privilege bit values that control whether the action are to be
considered allowed by default.
The value is the or of a set of ACLF4_MINF_* constants which to be
compared to the corresponding mask for the current request.
Noveck Expires 28 October 2024 [Page 68]
Internet-Draft Nfsv4 ACLs April 2024
* The basis-mask sub-field within ACLF4_MI*_BMASK indicates a set of
privilege bit values that are to be matched for exquality with the
vlue in the basis-value sub-field in determining whether the
actions associated with the ACE mask bits are to be considered
allowed by default
The value is the or of a set of ACLF4_MINF_* constants which to
used as a mask to determine which bists of the basis-value sub-
field are to compared tot the corresponding bits for the current
request.
const ACLF4_MIBT_NONE = 0;
const ACLF4_MIBT_PBIT = 1;
const ACLF4_MIBT_AMBIT = 2;
const ACLF4_MIBT_MCONE = 3;
const ACLF4_MIBT_MCALL = 4;
The above values, when appropriately left-shifted, can be used as
value of the basis-type subfield:
* When the value ACLF4_MIBT_NONE is used, the actions covered by the
mask bits specfied are treated as having no ancestor the hierarchy
of action which can be authorized.
As a result, there is no coarser-grained entity to use to control
authorization if the specified bits are not supported
* When the value ACLF4_MIBT_PBIT is used, the specfied ACE mask bits
are treated as the direct descendent of one of the five permission
bits, either one of the three POSIX privilege bits of some
ownership-related condition.
In this case, the specific permission bit is identified by the
value in the basis-number sub-field and all the other subfields
fields may only have the value zero.
* When the value ACLF4_MIBT_AMBIT is used,the specfied ACE mask bits
are treated as the direct descendent of one of other ACE mask
bits.
In this case, the specific ancestor ACE mask bit is identified by
the value in the basis-number sub-field (in the form of a shift
count)mand all the other subfields fields may only have the value
zero.
It is invlid for the ancestor relation to result in a loop when
repeated.
Noveck Expires 28 October 2024 [Page 69]
Internet-Draft Nfsv4 ACLs April 2024
* When the value ACLF4_MIBT_MCONE is used, the default for
authorization of the associated actions is deermine by use of the
basis-value and basis-mask subfields, each of which is a mask with
one bit position for each of the possible priviliege bits derived
from the mode and file ownership. The privilege mask for the
current request and the basis-value subfield are compared
resulting in a mask of the bit positions for which the two are
equal. that mask is then anded with the bas-mask subfield and if
any bits are on, the default status for authorization of the
asssocited mask bits is allowded
* When the value ACLF4_MIBT_MCALL is used. , the default for
authorization of the associated actions is deermine by use of the
basis-value and basis-mask subfields, each of which is a mask with
one bit position for each of the possible priviliege bits derived
from the mode and file ownership. The privilege mask for the
current request and the basis-value subfield are compared
resulting in a mask of the bit positions for which the two are
equal. that mask is then anded with the bas-mask subfield and if
all the bits in the bsis-mask subfield are set bits are on, the
default status for authorization of the asssocited mask bits is
allowded.
5.2.8. ACE Mask Bit Support Inference
[Consensus Needed (Item #61X), through end of section}:
The inference that can be done to provide information about ACE mask
bit support, in the absence of the Aclfeature attribute, depends on
the ACL model determined on the basis of the set of supported ACE
types. Given the inability of this method to deal with hybrids of
the two models, the inferences that can be done, treat server that
support the UNIX ACL model in one class, and all other in another
class which includes servers that implement the NFSv4 ACL model as
well as most hybrids in another.
In all cases, it can be assumed that the ACE mask bits defined in
Section 5.2.3 are supported.
When it is determined that the UNIX ACL model is supported, the
follow can be assumed:
* [Author Aside]: I'm pretty sure this paragraph is close to correct
but we need information about clients to verify that, especially
with regard to the handling of non-authorization ACL functions.
Noveck Expires 28 October 2024 [Page 70]
Internet-Draft Nfsv4 ACLs April 2024
All ACE mask bits defined in Section 5.2.4, need to be specified
whenever ACE4_WRITE_DATA is specified. This applies to all ACE
types. Mask bits that are associaed with unsupported features can
be excluded. For example, ACE4_WRITE_NAMED_ATTRIBUTES does not
need to be set on file system whch have no support for named
attributes.
* [Author Aside]: It is hard to determine what to say about mask
bits defined in Sections 5.2.5 and 5.2.6. What I have below is
pretty much a guess and I expect it will have to be changed as
more implementation information becomes available.
For ACE mask bits defined in Sections 5.2.5, it is best to avoid
using them in ACEs at all.
When the UNIX ACL model is not the one supported, i.e. for
implementations of the NFSv4 ACL model or most hybrids, the following
guidelines apply:
* Clients that only need support for the feature set provided by
UNIX ACLs can behave just as they would for a server supporting
the UNIX ACL model.
* Clients that need access to features that requie use of the finer-
grained ACE mask bit structure are in an unfotunate position. Due
to an earlier lack of attention to interoperability issues, there
is no good way to obtain the necessary support information in
minor versions zero and one.
While it might make sense to test for support of individal ACE
mask bits by setting ACEs with those mask bits and seeing if
NFS4ERR_ATTRNOTSUPP is returned, this is not a viable approach
even apart from the general difficulty of making uch checks when
cossing into a file system. The normal problems with this sort of
approach are magnfied by the need to check bit cominations in
addition to single bits and the lack of clear direction in
existing secification to return errors in such cass.
As a reult, when the Aclfeature attribute is not present, clients
have to rely on their knowledge of the server they are connected
to, as they have been doing, with no prospect of interoperable
support for these extensions.
Noveck Expires 28 October 2024 [Page 71]
Internet-Draft Nfsv4 ACLs April 2024
5.2.9. ACE Mask Bit Extension
Standards-track docments which define NFSv4 protocol extensions, as
provided for in [RFC8178], can extend the set of ACE mask bits. The
definition of a new mask bit needs to provide the following
information:
* The set of actions affected by the new mask bit.
* The name of the new mask bit together with a previously unused
mask bit value.
* Information about the way that support (or not) for the new mask
bit is to be determined.
* Information about how the actions affected by this bit are dealt
with when this new bit is not fully supported.
This includes situations in which this mask bit has to have the
same state some other mask bit, i.e. it is a finer-grained variant
of that other bit.
In addition case in which the new bit is not a finer-grained
variant of an existing bit need to be addressed by specifying a
boolean combination of existing mask bits or of conditions such as
being the owner of the fle or withinthe owning group of the file.
5.2.10. 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 5.2.11
This section describes the handling requests of that involve deletion
of a directory entry. It needs to be noted that:
* Modification or transfer of a directory, as happens in RENAME is
not covered.
* The deletion of the file's data is dealt with separately sincee
this action, like a truncation to length zero, requires only
ACE4_WRITE_DATA.
Noveck Expires 28 October 2024 [Page 72]
Internet-Draft Nfsv4 ACLs April 2024
* The use of ACE4_ADD_FILE, as opposed to ACE4_DELETE_CHILD, while
suspicious is being retained at least until we have information
about existing implementations.
* It is not clear how this all applies to deletions of
subdirectories. This also need information about existing
implementations before we close on Consensus Item #12.
In general, the recognition of such an operation for
authorization/auditing/alarm depends on either of two bits mask bits
being set: ACE4_MASK_DELETE on the file being deleted and
ACE4_MASK_DELETE_CHILD on the directory from which the entry is being
deleted.
In the case of authorization, the above applies even when one of the
bits is allowed and the other is explicitly denied.
[Consensus Items, Including List (#6c, #12a): When neither of the
mask bits is set, the result is normally negative. That is,
permission is denied and no audit or alarm event is recognized.
However, in the case of authorization, the server MAY make permission
dependent on the setting of MODE4_SVTX, as follows:
* If that bit not set, allow the removal if and only if
ACE4_ADD_FILE is permitted.
* If that bit is set, allow the removal if and only if ACE4_ADD_FILE
is permitted and the requester is the owner of the target.
5.2.11. Handling of Deletion (Vestigial)
[Author Aside]: This section contains the former content of
Section 5.2.10. All unannotated paragraphs within it are to be
considered the Previous Treatment associated with consensus item
#12b.
[Author Aside, Including List]: Listed below are some of the reasons
that I have tried to replace the existing treatment rather than
address the specific issues mentioned here and in later asides.
* The fact that there is no clear message about what servers are to
do and about what behavior clients might rely rely on. This
derives in turn from the use of "SHOULD" in contexts in which it
is clearly not appropriate, combined with non-normative reports of
what some systems do, and the statement that the approach
suggested as a way of providing "something like traditional UNIX-
like semantics".
Noveck Expires 28 October 2024 [Page 73]
Internet-Draft Nfsv4 ACLs April 2024
* The complexity of the approach without any indication that there
is a need for such complexity makes me doubtful that anything was
actually implemented, especially since the text is so wishy-washy
about the need for server implementation. The probability that it
would be implemented so widely that clients might depend on it is
even more remote.
* The fact that how audit and alarm issues are to be dealt with is
not addressed at all.
* The fact that this treatment combines ACL data with mode bit
information in a confused way without any consideration of the
fact that the mode attribute had been OPTIONAL.
Two access mask bits govern the ability to delete a directory entry:
ACE4_DELETE on the object itself (the "target") and ACE4_DELETE_CHILD
on the containing directory (the "parent").
Many systems also take the "sticky bit" (MODE4_SVTX) on a directory
to allow unlink only to a user that owns either the target or the
parent; on some such systems the decision also depends on whether the
target is writable.
Servers SHOULD allow unlink if either ACE4_DELETE is permitted on the
target, or ACE4_DELETE_CHILD is permitted on the parent. (Note that
this is true even if the parent or target explicitly denies one of
these permissions.)
If the ACLs in question neither explicitly ALLOW nor DENY either of
the above, and if MODE4_SVTX is not set on the parent, then the
server SHOULD allow the removal if and only if ACE4_ADD_FILE is
permitted. In the case where MODE4_SVTX is set, the server may also
require the remover to own either the parent or the target, or may
require the target to be writable.
This allows servers to support something close to traditional UNIX-
like semantics, with ACE4_ADD_FILE taking the place of the write bit.
5.3. ACE flag bits
The bitmask constants used for the flag field are as follows:
Noveck Expires 28 October 2024 [Page 74]
Internet-Draft Nfsv4 ACLs April 2024
const ACE4_FILE_INHERIT_ACE = 0x00000001;
const ACE4_DIRECTORY_INHERIT_ACE = 0x00000002;
const ACE4_NO_PROPAGATE_INHERIT_ACE = 0x00000004;
const ACE4_INHERIT_ONLY_ACE = 0x00000008;
const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010;
const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020;
const ACE4_IDENTIFIER_GROUP = 0x00000040;
const ACE4_INHERITED_ACE = 0x00000080;
[Author Aside]: Although there are multiple distinct issues that
might need to be changed, in the interest of simplifying the review,
all such issues within this section will be considered part of
Consensus Item #13a with a single revised treatment addressing all
the issues noted.
[Previous Treatment]: A server need not support any of these flags.
[Author Aside]: It is hard to understand why such broad license is
granted to the server, leaving the client to deal, without an
explicit non-support indication, with 256 possible combinations of
supported and unsupported flags. If there were specific issues with
some flags that makes it reasonable for a server not to support them,
then these need to be specifically noted. Some additional problems
with the existing treatment are that many of the flags in this list
are not, by their nature, capable of support by the server (e.g.,
ACE4_INHERITED_ACE) and that some cannot reasonably be made OPTIONAL
in general (e.g. ACE4_IDENTIFIER_GROUP for all ACEs and both
ACE4_SUCCESSFUL_ACCESS_ACE_FLAG and ACE4_FAILED_ACCESS_ACE_FLAG for
AUDIT and ALARM ACES). Also troubling is the lack of any statement
regarding the use of unassigned bits and the consequent effect on
protocol extensibility.
[Previous Treatment]: If the server supports flags that are similar
to, but not exactly the same as, these flags, the implementation may
define a mapping between the protocol-defined flags and the
implementation-defined flags.
[Author Aside]: The above regarding, the possibility of defining a
mapping betweeen the protocol-defined flags and hypothetical
implementation-defined flags might store the bits it supports, while
valid, is out-of-scope and need to be deleted.
[Previous Treatment]: For example, suppose a client tries to set an
ACE with ACE4_FILE_INHERIT_ACE set but not
ACE4_DIRECTORY_INHERIT_ACE. If the server does not support any form
of ACL inheritance, the server should reject the request with
NFS4ERR_ATTRNOTSUPP. If the server supports a single "inherit ACE"
flag that applies to both files and directories, the server may
Noveck Expires 28 October 2024 [Page 75]
Internet-Draft Nfsv4 ACLs April 2024
reject the request (i.e., requiring the client to set both the file
and directory inheritance flags). The server may also accept the
request and silently turn on the ACE4_DIRECTORY_INHERIT_ACE flag.
[Author Aside]: What is the possible justification for accepting a
request asking you do something and then, without notice to the
client, do something else. I believe there is none.
Consensus Needed (Item #13a)]: Server support for many of the flags
defined above is OPTIONAL, although there are constraints in some
cases so that certiain combination of support and non-support are not
allowed, as described in Section 5.3.1
Consensus Needed (Item #13a)]: When a server which does not support
all the flags bits receives a request to set an NFSv4 ACL containing
an ACE with an unsupported flag bit set the server MUST reject the
request with NFS4ERR_ATTRNOTSUPP.
Consensus Needed (Item #13a)]: The case of servers which do not
provide support for particular flag combinations is to be treated
similarly. If a server supports a single "inherit ACE" flag that
applies to both files and directories, receives a request set an
NFSv4 ACL with ACE ACE4_FILE_INHERIT_ACE set but
ACE4_DIRECTORY_INHERIT_ACE not set, it MUST reject the request with
NFS4ERR_ATTRNOTSUPP.
5.3.1. Details Regarding ACE Flag Bits
ACE4_FILE_INHERIT_ACE
Any non-directory file in any sub-directory will get this ACE
inherited.
Support for this flag bit is OPTIONAL.
ACE4_DIRECTORY_INHERIT_ACE
Can be placed on a directory and indicates that this ACE is to be
added to each new sub-directory created.
Support for this flag bit is OPTIONAL.
If this flag is set in an ACE in an NFSv4 ACL attribute to be set
on a non-directory file system object, the operation attempting to
set the ACL SHOULD fail with NFS4ERR_ATTRNOTSUPP.
Noveck Expires 28 October 2024 [Page 76]
Internet-Draft Nfsv4 ACLs April 2024
[Author Aside (Items #13b, #4g)]: Since I am unable to guess what
might by "valid resaons" to bypass the recommendation in the
paragraph, keeping this as a residual "SHOULD" for now. This
could change if it is determined that the recommendation was never
bypassed in existing server implementations, or if a specfic valid
reason to bypass the reommendation is found.
ACE4_NO_PROPAGATE_INHERIT_ACE
Can be placed on a directory. This flag tells the server that
inheritance of this ACE is to stop at newly created child
directories.
While Support for this flag bit is formally OPTIONAL, it has no
use if ACE4_DIRECTORY_INHERIT_ACE is not supported and is REQUIRED
if it is.
ACE4_INHERIT_ONLY_ACE
Can be placed on a directory but does not apply to the directory;
ALLOW and DENY ACEs with this bit set do not affect access to the
directory, and AUDIT and ALARM ACEs with this bit set do not
trigger log or alarm events. Such ACEs only take effect once they
are applied (with this bit cleared) to newly created files and
directories as specified by the ACE4_FILE_INHERIT_ACE and
ACE4_DIRECTORY_INHERIT_ACE flags.
If this flag is present on an ACE, but neither
ACE4_DIRECTORY_INHERIT_ACE nor ACE4_FILE_INHERIT_ACE is present,
then an operation attempting to set such an attribute SHOULD fail
with NFS4ERR_ATTRNOTSUPP.
ACE4_SUCCESSFUL_ACCESS_ACE_FLAG and ACE4_FAILED_ACCESS_ACE_FLAG
The ACE4_SUCCESSFUL_ACCESS_ACE_FLAG (SUCCESS) and
ACE4_FAILED_ACCESS_ACE_FLAG (FAILED) flag bits may be set only on
ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and ACE4_SYSTEM_ALARM_ACE_TYPE
(ALARM) ACE types. If during the processing of the file's NFSv4
ACL, the server encounters an AUDIT or ALARM ACE that matches the
principal attempting the OPEN, the server notes that fact, and the
presence, if any, of the SUCCESS and FAILED flags encountered in
the AUDIT or ALARM ACE. Once the server completes the ACL
processing, it then notes if the operation succeeded or failed.
If the operation succeeded, and if the SUCCESS flag was set for a
matching AUDIT or ALARM ACE, then the appropriate AUDIT or ALARM
event occurs. If the operation failed, and if the FAILED flag was
set for the matching AUDIT or ALARM ACE, then the appropriate
AUDIT or ALARM event occurs. Either or both of the SUCCESS or
FAILED can be set, but if neither is set, the AUDIT or ALARM ACE
is not useful.
Noveck Expires 28 October 2024 [Page 77]
Internet-Draft Nfsv4 ACLs April 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 5.4.
Support for this flag bit is REQUIRED.
ACE4_INHERITED_ACE
Indicates that this ACE is inherited from a parent directory. A
server that supports automatic inheritance will place this flag on
any ACEs inherited from the parent directory when creating a new
object. Client applications will use this to perform automatic
inheritance. Clients and servers MUST clear this bit in the acl
attribute; it may only be used in the dacl and sacl attributes.
5.3.2. ACE Flag Support Discovery
[Consensus Needed (Items #13c, #105k), Entire Section]:
Within the Aclfeature value, words of type af4flags are analyzed
using the definitions below to determine the sets of flags which are
supported or are storeable without necessarily being supported. In
addition, information about the conformance of the flag support with
recommmendations made in the specification is provided.
Bit fields within an af4flags value are defined at two levels:
* Individual flag bits are defined in a ten-bit level-of-flag-
support field.
* The word is divided into multiple level-of-flag-support fields and
additional flags.
Following are indivdual flags defined within eacg level-of-flag-
support field.
const AF4FLAG_INHFILE = 0x00000001;
const AF4FLAG_INDIR = 0x00000002;
const AF4FLAG_INHCHOICE = 0x00000004;
const AF4FLAG_INHAUTO = 0x00000008;
Noveck Expires 28 October 2024 [Page 78]
Internet-Draft Nfsv4 ACLs April 2024
Within a level-of-flag-support field, the followig bits are set or
not as specified below. The values of any bits not specfically
defined are to be zero.
* The flag AF4FLAG_INHFILE is set iff the flag ACE4_FILE_INHERIT_ACE
is supported.
* The flag AF4FLAG_INDIR is set iff the flag
ACE4_DIRECTORY_INHERIT_ACE is supported.
* The flag AF4FLAG_INHCHOICE is set iff the two flags
ACE4_FILE_INHERIT_ACE and ACE4_DIRECTORY_INHERIT_ACE are supported
independently making it possible for the choice as to whether
inheitance applies to be made differently for differnt sorts of
objects.
* The flag AF4FLAG_INHAUTO is set iff the flags related to the
automatic inheritance inheritance. This applies to whichever of
the dacl and sacl attributes that are supported. If neither of
those attributes are supported the value of the flag is to be set
to zero.
Defined below are te ovrall contents of words of type 4flags, which
consists of one overall flag and three level-of-flag-support fields.
const AF4FLAG_UNDEF0 = 0x40000000;
const AF4FLAG_ASUPPMASK = 0x000003ff;
const AF4FLAG_RSUPPMASK = 0x000ffc00;
const AF4FLAG_STOREMASK = 0x3ff00000;
const AF4FLAG_ASUPPSHIFT = 0;
const AF4FLAG_RSUPPSHIFT = 10;
const AF4FLAG_STORESHIFT = 20;
The fields within an af4flags word consist of the four fields listed
below. The three level-of-flag-support fields are each defined by a
mask defining the portion of the word in which he field resides and a
shift that specfies the number of bits the flss within the field are
to left-shifted to be place within the af4flags word.
* The flag AF4FLAG_UNDEF0 is to be set if the server sets all bit
within ACE flag feld tht are not defined by the protocol to be
zero. The asssurance provided makes it possible to extend the
function of the flags word, as described in Section 5.3.3
* The level-of-flag-support field specfied by AF4FLAG_ASUPPMASK and
AF4FLAG_ASUPPSHIFT is used to determine which flag bits have any
support at all, including cases where the support differs from the
recommendations in Section 5.3.1
Noveck Expires 28 October 2024 [Page 79]
Internet-Draft Nfsv4 ACLs April 2024
* The level-of-flag-support field specfied by AF4FLAG_RSUPPMASK and
AF4FLAG_RSUPPSHIFT is used to determine which flag bits are
supported as described in Section 5.3.1
* The level-of-flag-support field specfied by AF4FLAG_STOREMASK and
AF4FLAG_STORESHIFT is used to determine which flag bits are
accepted and stored in ACLs without necessarily implying they are
actually supported by the server.
When the Aclfeature attribute is not suported, possibilities for
support discovery are more limited and would depend on the ACL model
inferred based on the set of ACE types supported.
* When use of the UNIX ACL model is inferred, the client can
reasonably assume that no support for the inheritence- related
flags exist and that modes are computed in the alternate fashion
intended to support UNIX ACLs.
* In the unlikely event that there exist clients that depend on the
UNIX ACL model in that they do not support ACEs of types other
than ALLOW, while still needing some level of inheritence support
or which depend on mode being computed by the server as desctibed
in Section 8.3, the client can test for support as in other cases
in which the server provides a hybrid of the two models, as
discussed below.
* When use of the NFSv4 ACL model is inferred, the client has no
information about potential support but it is very likely that
support for inheritance-related ACL flags will be provided and
that the mode will be computed by the server as desctibed in
Section 8.3. In cases in which different support is provided by
the server or in which the clients needs different support, client
can test for support as in other cases in which the server
provides a hybrid of the two models, as discussed below.
For clients whose needs are for features in which there is a
discordance between what can be inferred from the set of ACE types
supported and the actual support that the af4flags fields would
indicate if Aclfeature were supported, the methods described below
could be used to test for support of various feature. However,
because of the difficulty of doing such tests when a file sytem is
first referenced and the lack of clarity in existing specs as to
feture discovery, it is likely that these methods would not be used.
Instead, such clients, if they exist, would find out about support
levels as they do now, by knowledge about particular depending on
external knowledge about server choices, without support for
interoperability involving other servers.
Noveck Expires 28 October 2024 [Page 80]
Internet-Draft Nfsv4 ACLs April 2024
* Support for various flag could be determined by using those in
ACLs to be set and seeing if NFS4ERR_ATTRNOTSUPP was returned.
In addition to the complexity of this procefure, the existing
specifications are not very direct about how on-support is to be
commmunicated, even though that seems to be the intent.
* Determiining which of Sections 8.3 or 8.4 is to be used in
computing mode value corresponding ACLs can only be done by
setting ACLs and seeing which of the expected mode values is
present.
In addition to the inherent complexity of this proceure,
interpretation of the results might by complicated by difficulties
in handling reverse-slope modes derived from problems in the
original specfications of thse matters.
The testing difficulties cited above is likely to result in their not
being used for feature discovery, with real feature discovery work
being deferred until Aclfeature is available. Nevertheless these
tests are useful to provide information about specific server
implemntations that can be used in future drafts of this document
5.3.3. ACE Flag Extension
[Consensus Needed (Item #13d), Entire Section]:
Although, in general, peviously unused bits within flags words such
as the flag field within an ACE can easily be added in extensions,
the way that the flag field within is defined creates unusual
difficulties, since we cannot be sure that undefined bits in these
words are always zero. As a consequence, the definition of
additional flags must satisfy one the following constaints:
* Use of the extension needs to be conditioned on support for the
Aclfeature attribute and the server setting the flag
AF4FLAG_UNDEF0 in the af4flags word returned.
* Defninition of the extension has to occur in a future minor
version that requires that unused bits in an ACE flag word always
be sent not set.
Assuming the flag can be defined as discussed above are
satisfactorily dealt with, definitions of new flags needs the
following items to be specified:
* An XDR definition of the value of the flag assigning an used flag
value to a synbol typically beginning with "ACE4_".
Noveck Expires 28 October 2024 [Page 81]
Internet-Draft Nfsv4 ACLs April 2024
* A definition of what the flag indicates.
* Discussion of the pattern of use of the flag, including whether it
is set by the client and used by the server, the reverse, or both.
* For flags set by the client and interpreted by the server,
specification of a means by which the client can determine whether
the flag is supported.
This can take the form of a new bit with that purpose within the
af4flags word, the support for or value returned by an OPTIONAL
attribute, or other means that the client can easily determine
whether support is present.
5.4. ACE Who
The "who" field of an ACE is an identifier that specifies the
principal or principals to whom the ACE applies. It may refer to a
user or a group, with the flag bit ACE4_IDENTIFIER_GROUP specifying
which of the two is referred to.
There are several special identifiers that need to be understood
universally, rather than in the context of a particular DNS domain.
[Author Aside, including list]: The above paragrph is OK, but the
following issues regarding these special identifiers need to be
addressed:
* Lack of clarity about the question of which of these special
identifiers have to be supported and for which support is
OPTIONAL.
* Lack of clarity about which special identifiers can be understood
by NFSv4.
* Confusion of "authentication" and "identification".
[Previous treatment (Item #50a)]: Some of these identifiers cannot be
understood when an NFS client accesses the server, but have meaning
when a local process accesses the file. The ability to display and
modify these permissions is permitted over NFS, even if none of the
access methods on the server understands the identifiers.
[Consensus Needed (Item #50a)]: Server support for the special
identifiers "OWNER", "GROUP", and "EVERYONE" is REQUIRED. For others
support is OPTIONAL with information regarding support discovery
appearing in Section 5.4.1
Noveck Expires 28 October 2024 [Page 82]
Internet-Draft Nfsv4 ACLs April 2024
[Consensus Needed (Item #50a)]: Some of these identifiers, such as
"NETWORK", "DIALUP", "INTERACTIVE", "BATCH", and "SERVICE" cannot be
reliably understood when an NFS client accesses the server, but might
have meaning when a local process accesses the file or when protocols
other than NFSv4 are used As a result, when ACEs containing these who
values are encountered, a server that supports these values when
NFSv4 request are processed is free to make its own judgment as to
whether any particular request will be treated as matching.
[Consensus Needed (Item #50a)]: The ability to display and modify
these OPTIONAL permissions is provided for by NFSv4, even though they
are not, in most cases, useful when processing NFSv4 requests,
+===============+===================================================+
| Who | Description |
+===============+===================================================+
| OWNER | The owner of the file. |
+---------------+---------------------------------------------------+
| GROUP | The group associated with the file. |
| | |
| | Note that the mode bits for the group do not |
| | apply to the owner of the file while the ownerof |
| | the file is a member of GROOUP@ |
+---------------+---------------------------------------------------+
| EVERYONE | [Previous treatment (Item #50a)]: The world, |
| | including the owner and owning group. |
| | |
| | [Consensus Needed (Item #50a)]: All requesters, |
| | including the owner, members of the owning |
| | group, and requests for which no user |
| | information is available. |
+---------------+---------------------------------------------------+
| INTERACTIVE | Accessed from an interactive terminal. |
+---------------+---------------------------------------------------+
| NETWORK | Accessed via the network. |
+---------------+---------------------------------------------------+
| DIALUP | Accessed as a dialup user to the server. |
+---------------+---------------------------------------------------+
| BATCH | Accessed from a batch job. |
+---------------+---------------------------------------------------+
| ANONYMOUS | [Author Aside]: Although AUTH_NONE requests, are |
| | included here it is not clear whether AUTH_SYS |
| | requests, particularly those issued without |
| | client peer authentication should be included. |
| | Although I feel that they are not truly |
| | authenticated, it is hard to be sure of the |
| | intention given the way term "authenticated" has |
| | been used in earlier specifications. Also hard |
Noveck Expires 28 October 2024 [Page 83]
Internet-Draft Nfsv4 ACLs April 2024
| | to resolve is the status of "nobody@domain" |
| | which is inteneded to be anonymous but may well |
| | be authentcated, as some other user. |
| | |
| | [Author Aside]: For now, am doing the best I |
| | can, given that no implementations of these have |
| | been found. When they are, will need to |
| | consider revision. If none are found, could |
| | consider deleting these. In any case, think we |
| | will wind up treating thse as opposites, unless |
| | forced to do otherwise by existing |
| | mplementations. |
| | |
| | [Consensus Needed (Item #50a)]: Accessed without |
| | any authentication of the user principal (e.g |
| | via AUTH_NONE). Also can include user defined |
| | as anonybous such as those which result from |
| | root-squashing, regardless of the quality of |
| | authentication |
+---------------+---------------------------------------------------+
| AUTHENTICATED | [Author Aside]: As for the previous case, am |
| | doing the best I can given that no |
| | implementation of these have been found. |
| | |
| | [Consensus Needed (Item #50a)]: Any |
| | authenticated user except those to be treated as |
| | anonymous (opposite of ANONYMOUS). |
+---------------+---------------------------------------------------+
| SERVICE | Accessed from a system service. |
+---------------+---------------------------------------------------+
Table 3
To avoid conflict, these special identifiers are distinguished by an
appended "@" and will appear in the form "xxxx@" (with no domain name
after the "@"), for example, ANONYMOUS@.
{Previous treatment (Item #51a)]: The ACE4_IDENTIFIER_GROUP flag MUST
be ignored on entries with these special identifiers. When encoding
entries with these special identifiers, the ACE4_IDENTIFIER_GROUP
flag SHOULD be set to zero.
[Author Aside]: I don't understand what might be valid reasons to
ignore this or how a server would respond in the case the that it was
ignored.
Noveck Expires 28 October 2024 [Page 84]
Internet-Draft Nfsv4 ACLs April 2024
[Consensus Needed (Item #51a)]: The ACE4_IDENTIFIER_GROUP flag MUST
be ignored on entries with these special identifiers. When encoding
entries with these special identifiers, the ACE4_IDENTIFIER_GROUP
flag should be set to zero.
It is important to note that "EVERYONE@" is not equivalent to the
UNIX "other" entity. This is the case because, by definition, UNIX
"other" does not include the owner or owning group of a file.
"EVERYONE@" means literally everyone, including the owner or owning
group.
5.4.1. ACE Who Value Support Discovery
[Consensus Needed (Item #50b, #105l), for entire section]:
[Author Aside (Item #50b), to the end of the bulleted list]: Given
that we have not yet encountered any implementations of these special
values. When we complete our analysis of exising implementations, we
might update this in varous ways:
* If it is the case that one or more of these special who values is
never accepted, the group will need to consider whether it make
sense to delete it now.
While there is no time gap that, by itself, would justify
unimplemented feature, the working group could reasonably conclude
that the absence of implementation for multiple decades could
consider that there is no real need for he feature.
* If an entire class of special who values (e.g. auth-related or
miscellaneous) were never implementented, it would be possible
streamline this section to delete it together with the flag bits
in af4flags supporting its discovery
The special who values for which support discovery is needed are
divided into two classes:
* The special values "AUTHENTICATED" and "ANONYMOUS" are referred to
as "auth-related" special values.
* The special values NETWORK", "DIALUP", "INTERACTIVE", "BATCH", and
"SERVICE" are referred to as "miscellaneous" pecial values.
Flags that provide support information regarding the server's
handling of who values are defined within a word of type af4whoinf,
which is available as part of the Aclfeature attribute, when that
attribute is supported.
Noveck Expires 28 October 2024 [Page 85]
Internet-Draft Nfsv4 ACLs April 2024
const AF4WHOI_AUTHSUPP = 0x00000001;
const AF4WHOI_AUTHSUPPC = 0x00000002;
const AF4WHOI_AUTHSTORE = 0x00000004;
const AF4WHOI_MISCSUPPA = 0x00000008;
const AF4WHOI_MISCSTORE = 0x00000010;
const AF4WHOI_OTHMODE = 0x00000020;
The flags whose xdr definition is presented above provide the
necessary support information for the current filesystem. These
flags' meanings are follows:
* AF4WHOI_AUTHSUPP indicates that the server provides support for
the special who value "AUTHENTICATED" and "ANONYMOUS", although
not necessarily with the definitions provided in Section 5.4.
This bit is not to be set unless request issued using AUTH_NONE
are selected (in the case of "ANONYMOUS) and excluded (in the case
of "AUTHENTICATED") when these special values appear in the who
field of an ACE.
* AF4WHOI_AUTHSUPPC indicates that the server provides support for
the special who value "AUTHENTICATED" and "ANONYMOUS, using the
definitions provided in Section 5.4.
* AF4WHOI_AUTHSTORE indicates that the server accepts ACEs with the
two special who values "AUTHENTICATED" and "ANONYMOUS", without
necessarily taking any action based on such ACEs other than to
store them and return them as part of ACLs.
* AF4WHOI_MISCSUPPA indicates that the server accepts ACEs with the
special who values identified as misccellaneous and makes some
effort to classify requests on the basis of the request's
provenance depending on the who value.
There are no contraints regrding how the server makes these
decisions
* AF4WHOI_MISCSTORE indicates that the server accepts ACEs with the
special who values identified as misccellaneous while essentially
ignoring such ACEs and not considering any request to match these
who values.
Such ACEs are stored abd returned as part of ACLs even though they
are ever acted on as part of processing NFSv4 requests.
* AF4WHOI_OTHMODE indicates how the server computes the mode value
to be set when changing the acl or dacl attributes. When set, it
specifies that ALLOW ACEs using non-special who values denoting
Noveck Expires 28 October 2024 [Page 86]
Internet-Draft Nfsv4 ACLs April 2024
specific user or groups are to be included in the mode value
computed (as applying to the "group" permissions) as specified in
Section 8.4 rather than using the method specified in Section 8.3.
When the Aclfeature attribute is not suported, possibilities for
support discovery are more limited and would depend on the ACL model
inferred baesed on the set of ACE types supported.
* When use of the UNIX ACL model is inferred, the client can
reasonably assume that no support for these special who values
exists.
* In the unlikely event that there exist clients that depend on the
UNIX ACL model in that they do not support ACEs of types other
than ALLOW, while still needing support for special who values,
thenn the client can test for support as it would in the next
case.
Such clients, if they exist, would, until support for Aclfeature
is available get the needed support as they do now, by depending
on exernal knowledge about server choices, without support for
interoperability involving other servers.
* When use of the NFSv4 ACL model is inferred, the client has no
information about potential support but can, if necessary
determine whther ACEs with these special values are accepted by
using them in ACLs containg ACEs with these special who values and
seeing if NFS4ERR_BADOWNER results.
In the case of auth-related special who values, requests with
specfic security paramters could be tested to determine whether
the use of those special values meets the client's needs.
In the case of miscellaneous special who values, it would hard to
use these values in ACEs and depending on their would remain as it
has been, without support for interoperbility involving other
servers.
5.4.2. ACE Who Value Extensiion
[Consensus Needed (Item #50c), for entire section]:
Because use of unknown who values is defined as returning
NFS4ERR_BADOWNER, standard track documents defining extensions to
extensible minor versions can define new special who values.
Definitions of such new values need to include the following:
Noveck Expires 28 October 2024 [Page 87]
Internet-Draft Nfsv4 ACLs April 2024
* The string(s) to serve with each together with an appended "@" as
the new special who value. The specfication should be in term of
the Unicode characters. If it is desired that case-insensitive or
normalization-form-insensitive string matching is desired, then
multiple strings should be specified rather than specifying the
type of code- insensitivity desired.
* A description of how it is to be determined whether a given NFSv4
request matches the new special who value. In this context,
"never", indicating such ACEs are to be ignored, is acceptable.
How these affect handling of non-NFSv4 requests can be treated as
out of scope.
* A description of how support for this new value is to be
ascertained. This can take the form of the specification of the
new value as auth-related, miscellaneous, or the idenification of
a new bit within af4whoinf values that indicates whether support
is present.
6. Automatic Inheritance Features
The acl attribute consists only of an array of ACEs, but the sacl
(Section 3.8) and dacl (Section 3.7) 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.
Noveck Expires 28 October 2024 [Page 88]
Internet-Draft Nfsv4 ACLs April 2024
Inheritable ACEs are normally inherited by child objects only at the
time that the child objects are created; later modifications to
inheritable ACEs do not result in modifications to inherited ACEs on
descendants.
However, the dacl and sacl provide an OPTIONAL mechanism that allows
a client application to propagate changes to inheritable ACEs to an
entire directory hierarchy.
A server that supports this feature performs inheritance at object
creation time in the normal way, and SHOULD set the
ACE4_INHERITED_ACE flag on any inherited ACEs as they are added to
the new object.
A client application such as an ACL editor may then propagate changes
to inheritable ACEs on a directory by recursively traversing that
directory's descendants and modifying each NFSv4 ACL encountered to
remove any ACEs with the ACE4_INHERITED_ACE flag and to replace them
by the new inheritable ACEs (also with the ACE4_INHERITED_ACE flag
set). It uses the existing ACE inheritance flags in the obvious way
to decide which ACEs to propagate. (Note that it may encounter
further inheritable ACEs when descending the directory hierarchy and
that those will also need to be taken into account when propagating
inheritable ACEs to further descendants.)
The reach of this propagation may be limited in two ways: first,
automatic inheritance is not performed from any directory ACL that
has the ACL4_AUTO_INHERIT flag cleared; and second, automatic
inheritance stops wherever an ACL with the ACL4_PROTECTED flag is
set, preventing modification of that ACL and also (if the ACL is set
on a directory) of the ACL on any of the object's descendants.
This propagation is performed independently for the sacl and the dacl
attributes; thus, the ACL4_AUTO_INHERIT and ACL4_PROTECTED flags may
be independently set for the sacl and the dacl, and propagation of
one type of acl may continue down a hierarchy even where propagation
of the other acl has stopped.
New objects are to be created with a dacl and a sacl that both have
the ACL4_PROTECTED flag cleared and the ACL4_AUTO_INHERIT flag set to
the same value as that on, respectively, the sacl or dacl of the
parent object.
Both the dacl and sacl attributes are Recommended, and a server MAY
support one without supporting the other.
Noveck Expires 28 October 2024 [Page 89]
Internet-Draft Nfsv4 ACLs April 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.
7. 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 28 October 2024 [Page 90]
Internet-Draft Nfsv4 ACLs April 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 5.4
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 28 October 2024 [Page 91]
Internet-Draft Nfsv4 ACLs April 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 features that many might
not need or use, it is the one that the working group adopted by the
working group, and I have to assume that alternatives, such as the
withdrawn POSIX ACL proposal were considered but not adopted. The
phrase "unsupported permission bits" with no definition of the bit
whose support might be dispensed with, implies that the server is
free to support whatever subset of these bits it chooses. As a
result, clients would not be able to rely on a functioning server
implementation of this OPTIONAL attribute. If there are specific
compatibility issues that make it necessary to allow non-support of
specific mask bits, then these need to be limited and the client
needs guidance about determining the set of unsupported mask bits.
[Previous Treatment]: The situation is complicated by the fact that a
server may have multiple modules that enforce ACLs. For example, the
enforcement for NFSv4.1 access may be different from, but not weaker
than, the enforcement for local access, and both may be different
from the enforcement for access through other protocols such as SMB
(Server Message Block). So it may be useful for a server to accept
an ACL even if not all of its modules are able to support it.
[Author Aside]: The following paragraph does not provide helpful
guidance and takes no account of the need of the the client to be
able to rely on the server implementing protocol-specifying semantics
and giving notice in those cases in which it is unable to so
[Previous Treatment]: The guiding principle with regard to NFSv4
access is that the server must not accept ACLs that appear to make
access to the file more restrictive than it really is.
8. Combining Authorization Models
Noveck Expires 28 October 2024 [Page 92]
Internet-Draft Nfsv4 ACLs April 2024
8.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 8.2 through 8.11. In addition, an
NFSv4.2-based extension related to attribute co-ordination will be
described in Section 8.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 28 October 2024 [Page 93]
Internet-Draft Nfsv4 ACLs April 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 8.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 8.5.
[Author Aside]: Despite the statement, now cited in Section 8.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 8.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 28 October 2024 [Page 94]
Internet-Draft Nfsv4 ACLs April 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 8
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.
8.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
8.7 through 8.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 28 October 2024 [Page 95]
Internet-Draft Nfsv4 ACLs April 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 8.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 28 October 2024 [Page 96]
Internet-Draft Nfsv4 ACLs April 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 8.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 8.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 8.4.
{Consensus Needed (Item #26a)]: How other ACEs are dealt with when
setting mode is described in Section 8.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 8.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 8.4. This is intentional, to avoid invalidating existing
implementations that compute the mode according to the withdrawn
POSIX ACL draft (1003.1e draft 17), rather than by actual permissions
on owner, group, and other.
[Consensus (Item #27a)]: In performing the co-ordinarion discussed in
this section, the method used to compute the mode from the ACL has an
important role. While the approach specified in Section 8.3 is
RECOMMENDED, it needs to be noted that the alternate approaches
discussed in Section 8.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 8.5.
Noveck Expires 28 October 2024 [Page 97]
Internet-Draft Nfsv4 ACLs April 2024
[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.
8.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 8 essentially pointless. Would prefer
"is to be used" or "MUST", with "SHOULD" available if valid reasons
to do otherwise can be found.
[Consensus Needed (Items #27b, #28b, #61f, #105m, #110f)}: The
following method (or another one providing exactly the same results)
SHOULD be used to calculate the MODE4_R*, MODE4_W*, and MODE4_X* bits
of a mode attribute, when it can be dermined that the ACL in question
is where it can determined one providing NFSv4 semantics in are to be
provided in this respect. In this case, the only valid reason to
bypass the recommendation is implementor reliance on previous
specifications which left this to implementor or ignored the cases of
the owner having less access than the owning group or the owning
group having less access than others. Further, in implementing or
the maintaining an implementation previously believed to be valid,
the implementor needs to be aware that this will result in invalid
values in some uncommon cases. Other reasons to do other than
recommended are discussed in Section 8.4, along with the case of ACLs
providing UNIX ACL semantics in this respect.
Noveck Expires 28 October 2024 [Page 98]
Internet-Draft Nfsv4 ACLs April 2024
[Author Aside, Including List]: The algorithm specified below, now
considered the Previous Treatment associated with Item #24a, has an
important flaw in does not deal with the (admittedly uncommon) case
in which the owner_group has less access than the owner or others
have less access than the owner-group. In essence, this algorithm
ignores the following facts:
* That GROUP@ includes the owning user while group bits in the mode
do not affect the owning user.
* That EVERYONE includes the owning group while other bits in the
mode do not affect users within the owning group.
[Previous Treatment (Item #28b)]: First, for each of the special
identifiers OWNER@, GROUP@, and EVERYONE@, evaluate the ACL in order,
considering only ALLOW and DENY ACEs for the identifier EVERYONE@ and
for the identifier under consideration. The result of the evaluation
will be an NFSv4 ACL mask showing exactly which bits are permitted to
that identifier.
[Previous Treatment (Item #28b)]: Then translate the calculated mask
for OWNER@, GROUP@, and EVERYONE@ into mode bits for, respectively,
the user, group, and other, as follows:
[Consensus Needed, including List(Item #28b)]: First, for each of the
sets of mode bits (i.e., user, group other, evaluate the ACL in
order, with a specific evaluation procedure depending on the specific
set of mode bits being determined. For each set there will be one or
more special identifiers considered in a positive sense so that ALLOW
and DENY ACE's are considered in arriving at the mode bit. In
addition, for some sets of bits, there will be one or more special
identifiers to be considered only in a negative sense, so that only
DENY ACE's are considered in arriving at the mode it. The users to
be considered are as follows:
* For the owner bits, "OWNER@" and "EVERYONE@" are to be considered,
both in a positive sense.
* For the group bits, "GROUP@" and "EVERYONE@" are to be considered,
both in a positive sense, while "OWNER@" is to be considered in a
negative sense.
* For the other bit, "EVERYONE@" is to be considered in a positive
sense, while "OWNER@" and "GROUP@" are to be considered in a
negative sense.
Noveck Expires 28 October 2024 [Page 99]
Internet-Draft Nfsv4 ACLs April 2024
[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 8.2 above.
8.4. Alternatives in Computing Mode Bits
[Author Aside]: All unannotated paragraphs within this section are to
be considered the Previous Treatment corresponding to Consensus Item
#27c.
Some server implementations also add bits permitted to named users
and groups to the group bits (MODE4_RGRP, MODE4_WGRP, and
MODE4_XGRP).
Implementations are discouraged from doing this, because it has been
found to cause confusion for users who see members of a file's group
denied access that the mode bits appear to allow. (The presence of
DENY ACEs may also lead to such behavior, but DENY ACEs are expected
to be more rarely used.)
[Author Aside]: The text does not seem to really discourage this
practice and makes no reference to the need to standardize behavior
so the clients know what to expect or any other reason for providing
standardization of server behavior.
The same user confusion seen when fetching the mode also results if
setting the mode does not effectively control permissions for the
owner, group, and other users; this motivates some of the
requirements that follow.
[Author Aside]: The part before the semicolon appears to be relevant
to Consensus Item #23 but does not point us to a clear conclusion.
The statement certainly suggests that the 512-ACL approach is more
desirable but the absence of a more direct statement to that effect
suggest that this is a server implementer choice.
[Author Aside]: The part after the semicolon is hard to interpret in
that it is not clear what "this" refers to or which which
requirements are referred to by "some of the requirements that
follow". The author would appreciate hearing from anyone who has
insight about what might have been intended here.
[Consensus Needed, Including List (Items #27c, #61g, #105n, #110g)]:
In cases in which the mode is not computed as described in
Section 8.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 or explicitly noted as
using this alternate procedure.
Noveck Expires 28 October 2024 [Page 100]
Internet-Draft Nfsv4 ACLs April 2024
* 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 8.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 8.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 8.2 above.
[Consensus Needed, Including List (Item #27c)]: When the
recommendation to use Section 8.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.
8.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
Noveck Expires 28 October 2024 [Page 101]
Internet-Draft Nfsv4 ACLs April 2024
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.
8.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.
8.7. Setting Mode and not ACL (overall)
8.7.1. Setting Mode and not ACL (vestigial)
[Author Aside]: All unannotated paragraphs are to be considered the
Previous treatment of Consensus Item #30b.
When any of the nine low-order mode bits are subject to change,
either because the mode attribute was set or because the
mode_set_masked attribute was set and the mask included one or more
bits from the nine low-order mode bits, and no ACL attribute is
explicitly set, the acl and dacl attributes must be modified in
accordance with the updated value of those bits. This must happen
even if the value of the low-order bits is the same after the mode is
set as before.
Note that any AUDIT or ALARM ACEs (hence any ACEs in the sacl
attribute) are unaffected by changes to the mode.
In cases in which the permissions bits are subject to change, the acl
and dacl attributes MUST be modified such that the mode computed via
the method in Section 8.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:
Noveck Expires 28 October 2024 [Page 102]
Internet-Draft Nfsv4 ACLs April 2024
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 8.11).
8.7.2. Setting Mode and not ACL (Discussion)
[Author Aside]: All unannotated paragraphs are to be considered
Author Asides relating to Consensus Item #30c.
Existing documents are unclear about the changes to be made to an
existing ACL when the nine low-order bits of the mode attribute are
subject to modification using SETATTR.
A new treatment needs to apply to all minor versions. It will be
necessary to specify that, for all minor versions, setting of the
mode attribute, subjects the low-order nine bits to modification.
One important source of this lack of clarity is the following
paragraph from Section 8.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
Noveck Expires 28 October 2024 [Page 103]
Internet-Draft Nfsv4 ACLs April 2024
above requirements. Discarding the ACL makes it effectively
impossible for a file created with a mode attribute to inherit an
ACL (see Section 8.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 8.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 8.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.
Beyond the possible issues that arise from the trivial-
implementation-ok interpretation, the treatment in Section 8.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
The effect of ignoring this case is often so pervasive that the
algoritms offered cnnot be patched to avoid the issue but neeed to
be rethought.
* Named users and groups.
The particular handling of these in computing mode, could
conceivably affect other aspects of mode handling as well.
Noveck Expires 28 October 2024 [Page 104]
Internet-Draft Nfsv4 ACLs April 2024
We will need to consider the behavior of clients and servers to
get a better handle on thse issues.
* The exact bounds of what within the ACL is covered by the low-
order bits of the mode.
A particular concern is the handling of ACE mask bits that are
neither derived directly from a POSIX permission bit nor control a
subset of the actions controlled by a POSIX permission bit. It is
often assumed in previous specification that no such bits exist
but that is not the case.
We have wound up accomodting a large set of bits, but might need
to revisit this issue if and when we decide to standardize the
handling of mask bits that are not finer-grained version of one of
the three POSIX permission bits.
It appears that for many of the issues, there are many possible
readings of the existing specs, leading to the possibility of
multiple inconsistent server behaviors. Furthermore, there are cases
in which none of the possible behaviors described in existing
specifications meets the needs.
As a result of these issues, the existing specifications do not
provide a reliable basis for client-side implementations of the ACL
feature which a Proposed Standard is normally expected to provide.
8.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.
Noveck Expires 28 October 2024 [Page 105]
Internet-Draft Nfsv4 ACLs April 2024
[Author Aside, through end of bulleted list]: In this and subsequent
sections I have tried to come up with overall recommendations that
are as consistent with the previous treatment as I can come up with,
as I have done in other areas. In this particular case, I have had
more difficulty than in others since this is the existing text
treatment is so unclear, making it hard to determine what hard-to-
accomodate aspects are intentional. In particular, as the working
group discusses this area and accommodate actual implementation, the
following difficult issues will need to be focused on:
* The retention or not of ACEs using special who values. Some of
the previous text suggests these are to be retained but I have
specfied they are to be invalidated.
In part, I am motivated by the fact that retaining these would
force a wholesale rewriting of the ACL, even in those cases in
which it can normally be avoided by using DENY ACEs to prevent
file authorization scanning from proceding beyond the portion of
the new ACE that is derived from the from the mode.
Requiring that these be retained would partially erode the conrol
of file authorization unless the ACL were rewritten to put these
first, whic might have unforeseen effects.
* The statement in existing specfication about avoiding conflicts
with the mode derived from the acl is not all that clear about
which method is intended.
I have stuck with Section 8.3 because I find the complexity of
dealing with multiple methods of mode computation hard to deal
with. When we have more information about implementations that
use alternate methods of mode computation, we will have to look at
this again, although we ight find that the context in which this
is one (i.e. UNIX ACLs) simple enough that we could adapt while
stll retaining our sanity.
* The handling of many of the ACE mask bits is not addressed, or is
addressed in flawed way because of mistaken that new mask bits
only change the granlarity of the set of action controlled and
nothing else.
We have tried to accommodate mask bits derivable from sets of mask
bits or from file ownership. While the result seems to make
sense, it might not do so once we look at detailed implentatio
characeristics and try to standardize the mappings between mask
bits and permission bits.
Noveck Expires 28 October 2024 [Page 106]
Internet-Draft Nfsv4 ACLs April 2024
This section describes how ACLs are to be updated in response to
actual or potential changes in the mode attribute, when the
attributes needed by both of the file access authorization models are
supported. It supersedes the discussions of the subject in [RFC7530]
and [RFC8881], each of which appeared in Section 6.4.1.1 of the
corresponding document.
Despite this supersession, it needs to be understood that previous
implementations addressed the issues using relying often on now-
superseded statements about the requirements to be satified and how
these requrements might be met. In light of the existence of these
implementations, in defining what would normally be requirements, we
use the term "SHOULD" with the understanding that reliance on
material in these earlier specifications is a valid reason to bypass
the new recommendation.
It is necessary to approach the matter differently than in the past
because:
* Organizational changes are necessary to address all minor versions
together.
* Those previous discussions are often internally inconsistent
leaving it unclear what specification-mandated actions are to be
performed.
* In many cases, servers were granted an extraordinary degree of
freedom to choose the action to take, either explicitly or via an
apparently unmotivated use of "SHOULD", leaving it unclear what
might be considered "valid" reasons to ignore the recommendation.
* There appears to have been no concern for the problems that
clients and applications might encounter dealing ACLs in such an
uncertain environment.
* Cases involving reverse-slope modes were not adequately addressed.
* The security-related effects of SVTX were not addressed.
Noveck Expires 28 October 2024 [Page 107]
Internet-Draft Nfsv4 ACLs April 2024
While that earlier approach might have been consdered workable at the
time, it made it difficult to devise client-side ACL implementations
that incorporated the extensions within NFSv4 ACLs, even if there had
been any interest in doing so. In order to enable this situation to
eventually be rectified, we will define the preferred implementation
here, but in order to provide temporary compatibility with existing
implementations based on reasonable interpretations of [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 existing servers that based their implementations on various
pieces of the existing text, now superseded.
The fundamental requirement that needs to be addressed is that when
mode bits involved in determining file access authorization are
subject to modification, the server MUST, when ACL-related attributes
have been set, modify the associated ACEs so as not to conflict with
the new value of the mode attribute.
The occasions to which this requirement applies, vary with the
attribute being set and the type of object being dealt with:
* For all minor versions, any change to the mode attribute, triggers
this requirement
* When the set_mode_masked attribute is being set on an object which
is not a directory, whether this requirement is triggered depends
on whether any of the nine low-order bits of the mode is included
in the mask.
* When the set_mode_masked attribute is being set on a directory,
whether this requirement is triggered depends on whether any of
the nine low-order bits of the mode or the SVTX bit is included in
the mask of bit whose values are to be set.
When the requirement is triggered, ACLs need to be updated to be
consistent with the new mode attribute. The necessary action depends
on specific of the ACEs involved.
* In the case of AUDIT and ALARM ACEs, which are used outside of
file access authorization, no change needs to be made.
Noveck Expires 28 October 2024 [Page 108]
Internet-Draft Nfsv4 ACLs April 2024
* For ALLOW and DENY ACEs, which are marked as inherit-only, no
change needs to be made since such ACEs have no effect on file
accces authorization for the current file.
* For ALLOW and DENY ACEs, which are marked as providing ACE
inheritance without being marked as inherit-only, the effect of
these ACEs on inheritance needs to be retained while their direct
effect on file access authorization needs to be disabled.
This can be effected by modifying the ACE to be inherit-only or
ensuring that such ACEs are never reached when scanning an ACL for
file access authorization. For eaxample, a DENY ACE for EVERYONE@
early in the ACL would have this effect
* The handling of remaining ACEs with a who-value of OWNER@, GROUP@,
or EVERYONE@ needs to be adapted to the new mode.
This could take the form of rewriting them in place or or of
generating new ACEs at the start of the ACL.
* The effect on file authorizaion of remaining ACEs whose who-value
is a named user needs to be avoided.
This can be accmplished by rewriting the ACL, eliminating such
ACEs or by or ensuring that such ACEs are never reached when
scanning an ACL for file access authorization. For eaxample, a
DENY ACE for EVERYONE@ early in the ACL would have this effect.
* The effect on file authorization of ACEs whose who-value is one of
the other special values defined in Section 5.4 are to be left
unmodified.
This can be accmplished by rewriting the ACL, eliminating such
ACEs or by or ensuring that such ACEs are never reached when
scanning an ACL for file access authorization. For eaxample, a
DENY ACE for EVERYONE@ early in the ACL would have this effect.
How these needs are best effected depends on the ACL model
implemented. Of particular importance is the existence of DENY ACEs
which allow one to force scanning for file access to be stopped at
some point while retaining later ACEs to be retained without any
possibility that they will affect file access authorization. We
discuss three classes of ACl implementations as discussed below.
* For implementation of NFSv4 ACLs and hybrids thatcontain support
for DENY ACEs, implememtation suggestions appearing in
Section 8.7.5 are provided.
Noveck Expires 28 October 2024 [Page 109]
Internet-Draft Nfsv4 ACLs April 2024
* For implementation of UNIX ACL, implememtation c suggestions
appearing in Section 8.7.4 are provided.
* For implementation of various bybrid ACLs that do not provide
support for DENY ACEs, implememtation suggestions appearing in
Section 8.7.6 are provided.
All of the abovementioned suggestions share common logic regarding
the formation of ACE masks used and how the mode bits are mapped ACE
mask designating allowed actions:
The set of ACE mask bits to be dealt with includes all of the mask
bits defined in Section 5.2 that are supported by server ACL
implementations.
[Author Aside]: Although the definintion above include
ACE4_WRITE_RETENTION and ACE4_WRITE_RETENTION_HOLD, we have not yet
determined how to arrive these values. If we ever find an
implementation of these, we will base that determination on that
implemention. See below.
The subsets of those mask bit to be allowed to the owning user
(OWNER@), members of the owning group (GROUP@) and EVERYONE@ are
determined as follows:
* For GROUP@ and EVERONE@, the appropriate set of three permission
is mapped, as described below, to a corresponding set of allowed
mask bits.
* For OWNER@, that same mapping is applied using the owner
permission but the resulting mask supplemented by adding, as
allowed mask bits, mask bits defiing action normally allowed to
the owner of the file rather than depending on the setting of
particular permission bits.
These include the ACE mask bits ACE4_WRITE_ATTRIBUTES,
ACE4_WRITE_ACL, and ACE4_WRITE_OWNER,
For each set of three permission bits the corresponding set of
allowed ACE mask bits is defined as follows:
* For mask bits defined in Section 5.2.3, each of the three
permission bits is mapped to the coreesponding ACE mask bits.
Although the names of those bit might be different depending on
whether the object is a directory or not, the same mapping is used
for all object types.
Noveck Expires 28 October 2024 [Page 110]
Internet-Draft Nfsv4 ACLs April 2024
* For mask bits defined in Section 5.2.4, they are included or not
depending on setting of the write permission bit. Note that the
set of mask bits is different for directories and for non-
directory objects.
* [Author Aside]: The following is a resonable guess but we need
implementation information to be confident about it.
The mask bit ACE4_READ_ATTRIBUTES is to be set unconditionally.
* [Author Aside]: The following what should happen but we need
implementation information to be confident about it.
The mask bit ACE4_READ_NAMED_ATTRIBUTES is to be set iff the read
permission bit or the execute permission bit is set.
* [Author Aside]: The following is based on the only i mplementation
tht we have locked but we need more implementation information to
be confident about it.
The mask bit ACE4_SYNCHRONIZE is to be set iff any of the three
permission bits is set.
* [Author Aside]: The mask bits ACE4_WRITE_RETENTION and
ACE4_WRITE_REYENTION_HOLD do not have any treatment specified
above. In the event that these are retained, we will need to
address that most probablt based on what is done by existing
implementations which support these. That could be easily dealt
with if these are to be controlled, in the absence of ACL support
by ownership combined with some set of privilege bits. If, on the
other hand, allowing these actions depends on some privilge
outsode of the scope the, it might make sense to exclude them from
treatment when a mode is set.
8.7.4. Setting Mode and not ACL in the Unix ACL Case (Proposed)
[Author Aside]: This proposed section is part of Consensus Item #30e
and all unannotated paragraphs within it are to be considered part of
that Item. Since the proposed text includes support for reverse-
slope modes, treats all minor versions together and assumes decisions
about handling of ACEs for named users and groups, the relevance of
consensus items #26, #28, and #29 needs to be noted.
Noveck Expires 28 October 2024 [Page 111]
Internet-Draft Nfsv4 ACLs April 2024
[Author Aside]: The inability of ACLs without DENY ACEs to present
certain modes in a newly discovered issue and a troublesome one which
will need extensive working group discussion. This issue applies to
Section 8.7.6 as well. It appears that this issue is not fixable
before NFSv4.2 but that it could be addressed by defining OTHERS@ and
GROUPEXCEPTOWNER@ as NFSv4.2 extensioniions.
When UNIX ACLs are implemented, the absence of support for DENY ACEs
forces the ACL to be rewritten in its entirety, rather than have a
mode-related section prepended to a mostly unchanged ACL. In
addition, the absence of support for DENY ACEs requires special
attention to the possible presence of reverse slope mode becase
OWNER@ is a subset of GROUP@ and both OWNER@ and GROUP@ are subsets
of EVERYONE@.
It should be noted however, that the complexity of the rewriting
process is reduced because of features not part of the UNIX ACL
model:
* The absence of support for ACEs other than ALLOW means only a
single ACE type neeeds to be dealt with.
* The absence of ACE inheritance means that ACEs marked to be
inherited or inherit-oly, do not exist.
* The absence of support for ACEs with OPTIONAL secial who allow
thes to be ignoed as well.
The replacement ACL begins with three ALLOW ACEs for the who values
OWNER@, GROUP@, and EVERYONE@. The order in which these are placed
in te resultant ACL needs to be adjusted based on the mode value
avoid prolems with reverse-slope modes. Such problems can arise when
a who value processed later contains permission bits not present in
previous one so that the later who value, covering a superset of the
principals of the earlier one, receives permissions that should not,
for eaxmple, be granted to the owning user according to the POSIX
definition of privileges for the owning group
In order to address this issue the three entries need to be sorted in
order of descending privilege, using the incluson relationship for
the privilege bits of each one.
It is possible that twp entries will have privilege sets not
orderable by inclusion, i.e., neither is a subset of the other.
Given the absence of DENY ACEs, the resulting permissions cannot be
representing by an ACL, so that the ACL needs to be deleted in this
case.
Noveck Expires 28 October 2024 [Page 112]
Internet-Draft Nfsv4 ACLs April 2024
These preliminary ACEs are followed by a series of ACEs derived from
the existing ACL with entries copied over or not as described below:
* ACEs with who value of OWNER@, GROUP@, or EVERYONE@ are not copied
over.
* ACEs with other who values are copied to the ACL, unmodified.
8.7.5. Setting Mode and not ACL in the NFSv4 ACL Case (Proposed)
[Author Aside]: This proposed section is part of Consensus Item #30f
and all unannotated paragraphs within it are to be considered part of
that Item. Since the proposed text includes support for reverse-
slope modes, treats all minor versions together and assumes decisions
about handling of ACEs for named users and groups, the relevance of
consensus items #26, #28, and #29 needs to be noted.
This covers in addition to NFSv4 ACLs per se, all cases in which
support for DENY ACEs is present. The availability of support for
DENY ACEs affects the generation of a new ACL as follows:
* Reverse slope modes do not force a re-ordering of the initial
ACEs. To avoid this, each initial ALLOW ACE is paired with a
corresponding DENY ACE
* Detailed analysis of the existing ACEs is not necessary since the
new ACL will prevent those from ever being referenced in
connection with file access authorization. This allows the
existing ACL to be appended to the three initial ACE pairs.
The replacement ACL begins with three pairs oACEs for the who values
OWNER@, GROUP@, and EVERYONE@. Each pair consists of an ALLOW ACE
for that who value followed by a corresponding DENY ACE with the same
who value. The ACE mask for the ALLOW ACE is derived from the
corresonding permission bits as described above. The mask for the
DENY ACE is the set of mode-related mask bits with the allows mask
bits turned off.
These preliminary ACEs are followed by copies of the ACEs within the
existing ACL. It is possible, although not necessary, to eliminate,
as part of this copy, all ALLOW and DENY ACEs with who values of
OWNER@, GROUP@, and EVERYONE@.
Noveck Expires 28 October 2024 [Page 113]
Internet-Draft Nfsv4 ACLs April 2024
8.7.6. Setting Mode and not ACL in Certain Hybrid ACL Cases (Proposed)
[Author Aside]: This proposed section is part of Consensus Item #30g
and all unannotated paragraphs within it are to be considered part of
that Item. Since the proposed text includes support for reverse-
slope modes, treats all minor versions together and assumes decisions
about handling of ACEs for named users and groups, the relevance of
consensus items #26, #28, and #29 needs to be noted.
This section covers ACL implementations that do not have support for
DENY ACEs. In such cases, the absence of support for DENY ACEs
forces the ACL to be rewritten in its entirety, rather than have a
mode-related section prepended to a mostly unchanged ACL. In
addition, the absence of support for DENY ACEs requires special
attention to the possible presence of reverse slope modes becase
OWNER@ is a subset of GROUP@ and both OWNER@ and GROUP@ are subsets
of EVERYONE@.
The replacement ACL begins with three ALLOW ACEs for the who values
OWNER@, GROUP@, and EVERYONE@. The order in which these are placed
in te resultant ACL needs to be adjusted based on the mode value
avoid problems with reverse-slope modes. Such problems can arise
when a who value processed later contains permission bits not present
in previous one so that the later who value, covering a superset of
the principals of the earlier one, receives permissions that should
not, for eaxmple, be granted to the owning user according to the
POSIX definition of privileges for the owning group
In order to address this issue the three entries need to be sorted in
order of descending privilege, as described in Section 8.7.4. As in
that case the existence of sets of privilege bits not coprable
according to inclusions migh force the ACL to be deleted, rather than
being replaced by an ACl equivalent to the mode, which in this case
cannot exist.
These preliminary ACEs are followed by a series of ACEs derived from
the existing ACL with entries copied over or not as described below:
* AUDIT and ALARMS ACEs are copied over.
* ALLOW and DENY ACEs that are marked inherit-only are copied over.
* ALLOW and DENY ACEs that are marked as inheritable without being
inherit-only are copied over in a modified form. They need to be
marked as inherit only.
Noveck Expires 28 October 2024 [Page 114]
Internet-Draft Nfsv4 ACLs April 2024
* Other ALLOW and DENY ACEs are not copied ober. This applies
irrespective of the who value, although the reasons for doing this
are different for different sorts of who values.
ACEs with who values of OWNER@, GROUP@, and EVERYONE@ are to be
eliminated because they are dealt with in the prepended ACEs.
ACEs with a who value denoting a specfic user or group are to be
eliminated because their presence is incompatable with the POSIX
file access authorization model.
ACEs with a special who value (auth-related or miscellaneous) are
to be eliminated in order to assue that the file access
authorization after settig the mode reflects the mode alone.
8.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 8.3. The three high-order bits of the mode
(MODE4_SUID, MODE4_SGID, MODE4_SVTX) SHOULD remain unchanged.
8.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 8.8.
8.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 28 October 2024 [Page 115]
Internet-Draft Nfsv4 ACLs April 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 8.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 8.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 8.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 8.3, with the
Noveck Expires 28 October 2024 [Page 116]
Internet-Draft Nfsv4 ACLs April 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.
8.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.
8.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 28 October 2024 [Page 117]
Internet-Draft Nfsv4 ACLs April 2024
9. 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.
10. XDR to Support an NFSv4.2 Aclfeature Extension
10.1. Extraction of XDR
This document contains the external data representation (XDR)
[RFC4506] description of the new open flags for delegating the file
to the client. The XDR description is embedded in this document in a
way that makes it simple for the reader to extract into a ready-to-
compile form. The reader can feed this document into the following
shell script to produce the machine readable XDR description of the
new flags:
<CODE BEGINS>
#!/bin/sh
grep '^ *///' $* | sed 's?^ */// ??' | sed 's?^ *///$??'
<CODE ENDS>
That is, if the above script is stored in a file called "extract.sh",
and this document is in a file called "spec.txt", then the reader can
do:
<CODE BEGINS>
sh extract.sh < spec.txt > layout_wcc.x
<CODE ENDS>
The effect of the script is to remove leading white space from each
line, plus a sentinel sequence of "///". XDR descriptions with the
sentinel sequence are embedded throughout the document.
Note that the XDR code contained in this document depends on types
from the NFSv4.2 nfs4_prot.x file (generated from [RFC7863]). This
includes both nfs types that end with a 4, such as offset4, length4,
etc., as well as more generic types such as uint32_t and uint64_t.
While the XDR can be appended to that from [RFC7863], the various
code snippets belong in their respective areas of the that XDR.
Noveck Expires 28 October 2024 [Page 118]
Internet-Draft Nfsv4 ACLs April 2024
10.2. Code Components Licensing Notice
Both the XDR description and the scripts used for extracting the XDR
description are Code Components as described in Section 4 of "Legal
Provisions Relating to IETF Documents". These Code Components are
licensed according to the terms of that document.
Noveck Expires 28 October 2024 [Page 119]
Internet-Draft Nfsv4 ACLs April 2024
<CODE BEGINS>
/// /*
/// * Copyright (c) 2017 IETF Trust and the persons identified
/// * as authors of the code. All rights reserved.
/// *
/// * Redistribution and use in source and binary forms, with
/// * or without modification, are permitted provided that the
/// * following conditions are met:
/// *
/// * o Redistributions of source code must retain the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer.
/// *
/// * o Redistributions in binary form must reproduce the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer in the documentation and/or other
/// * materials provided with the distribution.
/// *
/// * o Neither the name of Internet Society, IETF or IETF
/// * Trust, nor the names of specific contributors, may be
/// * used to endorse or promote products derived from this
/// * software without specific prior written permission.
/// *
/// * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS
/// * AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
/// * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
/// * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
/// * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
/// * EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
/// * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
/// * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
/// * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
/// * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
/// * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
/// * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
/// * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
/// * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
/// * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
/// *
/// * This code was derived from RFC 8276.
/// * Please reproduce this note if possible.
/// */
<CODE ENDS>
10.3. XDR For Aclfeature Extesion
Noveck Expires 28 October 2024 [Page 120]
Internet-Draft Nfsv4 ACLs April 2024
<CODE BEGINS>
/// /*
/// * aclfeat_prot.x
/// */
/// /*
/// * The following includes statements that are for example only.
/// * The actual XDR definition files are generated separately
/// * and independently and are likely to have a different name.
/// * %#include <rpc_prot.x>
/// * %#include <nfsv42.x>
/// */
/// /*
/// * Core type definitions needed for new feature.
/// */
/// typedef uint32_t af4miword;
/// struct af4minfo {
/// af4miword flagw;
/// acemask4 maskw;
/// };
/// typedef uint32_t af4typemask;
/// typedef uint32_t af4flags;
/// typedef uint32_t af4whoinf;
/// /*
/// * Definition of the Aclfeature attribute.
/// */
/// struct afeat4 {
/// af4typemask tmask;
/// af4flags flword;
/// af4whoinf whoword;
/// af4minfo maskinf<>;
/// };
/// /*
/// * Definitions to be used in interpreting words of type
/// * af4typemask.
/// */
/// const AF4TYPE_GSUPPMASK = 0x000003ff;
/// const AF4TYPE_BSUPPMASK = 0x000ffc00;
/// const AF4TYPE_STOREMASK = 0x3ff00000;
Noveck Expires 28 October 2024 [Page 121]
Internet-Draft Nfsv4 ACLs April 2024
/// const AF4TYPE_GSUPPSHIFT = 0;
/// const AF4TYPE_BSUPPSHIFT = 10;
/// const AF4TYPE_GSTORESHIFT = 20;
/// /*
/// * Definitions used in interpreting the maskw value within
/// * each af4minfo element within the maskinf array.
/// */
/// const ACLF4_MIM_SUPP = 0x00000007;
/// const ACLF4_MISH_SUPP = 0;
/// const ACLF4_MIBC_SUPP = 3;
/// const ACLF4_MIM_OTYPE = 0x00000018;
/// const ACLF4_MISH_OTYPE = 3;
/// const ACLF4_MIBC_OTYPE = 2;
/// const ACLF4_MIM_USES = 0x00000060;
/// const ACLF4_MISH_USES = 5;
/// const ACLF4_MIBC_USES = 2;
/// const ACLF4_MIM_BASIS = 0x07ffff80;
/// const ACLF4_MISH_BASIS = 7;
/// const ACLF4_MIBC_BASIS = 20;
/// const ACLF4_MIM_CSUPP = 0X18000000;
/// const ACLF4_MISH_CSUPP = 27;
/// const ACLF4_MIBC_CSUPP = 2;
/// /*
/// * Definitions of the values used in the support field
/// * within the masksw value.
/// */
/// const ACLF4_MIF_SLREJECT = 0;
/// const ACLF4_MIF_SLIGNORE = 1;
/// const ACLF4_MIF_SLSUPP = 2;
/// const ACLF4_MIF_SLDEFAULT = 3;
/// const ACLF4_MIF_SLJOINED = 4;
/// /*
/// * Definitions of the values used in the object-type
/// * field within the masksw value.
/// */
/// const ACLF4_MIF_DIR = 0x00000008;
/// const ACLF4_MIF_NDIR = 0x00000010;
/// const ACLF4_MIF_OALL = 0x00000018;
/// /*
/// * Definitions of the values used in the uses field
/// * within the masksw value.
Noveck Expires 28 October 2024 [Page 122]
Internet-Draft Nfsv4 ACLs April 2024
/// */
/// const ACLF4_MIF_UAUTH = 0x00000020;
/// const ACLF4_MIF_UOTHR = 0x00000040;
/// const ACLF4_MIF_UALL = 0x00000060;
/// /*
/// * Definitions of the sub-fields placed within the basis field
/// * of the masksw value.
/// */
/// const ACLF4_MIM_BTYPE = 0x00000380;
/// const ACLF4_MISH_BTYPE = 7;
/// const ACLF4_MIBC_BTYPE = 3;
/// const ACLF4_MIM_BNUMB = 0x00007c00;
/// const ACLF4_MISH_BNUMB = 10;
/// const ACLF4_MIBC_BNUMB = 5;
/// const ACLF4_MIM_BVAL = 0x001F8000;
/// const ACLF4_MISH_BVAL = 15;
/// const ACLF4_MIBC_BVAL = 6;
/// const ACLF4_MIM_BMASK = 0x07e00000;
/// const ACLF4_MISH_MASK = 21;
/// const ACLF4_MIBC_BMASK = 6;
/// /*
/// * Values used withinn the basis number subfield of
/// * maskw value.
/// */
/// const ACLF4_MIFP_READ = 0x00000001;
/// const ACLF4_MINP_READ = 0;
/// const ACLF4_MIFP_WRITE = 0x00000002;
/// const ACLF4_MINP_WRITE = 1;
/// const ACLF4_MIFP_EXEC = 0x00000004;
/// const ACLF4_MINP_EXEC = 2;
/// const ACLF4_MIFP_OWNER = 0x00000008;
/// const ACLF4_MINP_OWNER = 3;
/// const ACLF4_MIFP_GROUP = 0x00000010;
/// const ACLF4_MINP_GROUP = 4;
/// /*
/// * Values used withinn the basis type subfield of
/// * maskw value.
/// */
/// const ACLF4_MIBT_NONE = 0;
/// const ACLF4_MIBT_PBIT = 1;
/// const ACLF4_MIBT_AMBIT = 2;
Noveck Expires 28 October 2024 [Page 123]
Internet-Draft Nfsv4 ACLs April 2024
/// const ACLF4_MIBT_MCONE = 3;
/// const ACLF4_MIBT_MCALL = 4;
/// /*
/// * Definitions of flags used in each of the fields within words
/// * of type af4flags.
/// */
/// const AF4FLAG_INHFILE = 0x00000001;
/// const AF4FLAG_INDIR = 0x00000002;
/// const AF4FLAG_INHCHOICE = 0x00000004;
/// const AF4FLAG_INHAUTO = 0x00000008;
/// /*
/// * Definitions of the fields within words of type
/// * af4flags.
/// */
/// const AF4FLAG_UNDEF0 = 0x40000000;
/// const AF4FLAG_ASUPPMASK = 0x000003ff;
/// const AF4FLAG_RSUPPMASK = 0x000ffc00;
/// const AF4FLAG_STOREMASK = 0x3ff00000;
/// const AF4FLAG_ASUPPSHIFT = 0;
/// const AF4FLAG_RSUPPSHIFT = 10;
/// const AF4FLAG_STORESHIFT = 20;
/// /*
/// * Definition of flags within words of type af4whoinf.
/// */
/// const AF4WHOI_AUTHSUPP = 0x00000001;
/// const AF4WHOI_AUTHSUPPC = 0x00000002;
/// const AF4WHOI_AUTHSTORE = 0x00000004;
/// const AF4WHOI_MISCSUPPA = 0x00000008;
/// const AF4WHOI_MISCSTORE = 0x00000010;
/// const AF4WHOI_OTHMODE = 0x00000020;
<CODE ENDS>
11. 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].
12. IANA Considerations
This document requires no actions from IANA>
Noveck Expires 28 October 2024 [Page 124]
Internet-Draft Nfsv4 ACLs April 2024
13. References
13.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>.
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation
Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May
2006, <https://www.rfc-editor.org/info/rfc4506>.
[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>.
[RFC8178] Noveck, D., "Rules for NFSv4 Extensions and Minor
Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017,
<https://www.rfc-editor.org/info/rfc8178>.
[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>.
[RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor
Version 2 External Data Representation Standard (XDR)
Description", RFC 7863, DOI 10.17487/RFC7863, November
2016, <https://www.rfc-editor.org/info/rfc7863>.
[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>.
[I-D.dnoveck-nfsv4-security]
Noveck, D., "Security for the NFSv4 Protocols", Work in
Progress, Internet-Draft, draft-dnoveck-nfsv4-security-09,
21 April 2024, <https://datatracker.ietf.org/doc/html/
draft-dnoveck-nfsv4-security-09>.
13.2. Informative References
[RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "NFS version 4
Protocol", RFC 3010, DOI 10.17487/RFC3010, December 2000,
<https://www.rfc-editor.org/info/rfc3010>.
Noveck Expires 28 October 2024 [Page 125]
Internet-Draft Nfsv4 ACLs April 2024
[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.
* "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.
Noveck Expires 28 October 2024 [Page 126]
Internet-Draft Nfsv4 ACLs April 2024
* "NE" denotes change based on an existing issue in the spec but for
which the replacement text is incomplete and needs further
elaboration.
* "WI" denotes a potential change based on an existing issue in the
spec but for which replacement text is not yet available because
further working group input is necessary before drafting. It is
expected that replacement text will be available in a later draft
once that discussion is done.
* "LD" denotes a potential change based on an existing issue in the
spec but for which replacement text is not yet available due to
the press of time. It is expected that replacement text will be
available in a later draft.
* "EV" denote a potential change which is tentative or incomplete
because further details need to be provide or because the author
is unsure that he has a correct explanation of the issue. It is
expected that replacement text will be available in a later draft.
The following codes are defined for consensus items which are no
longer pending.
* "RT" designates a former item which has been retired, because it
has been merged with another one or otherwise organized out of
existence.
Such items no longer are referred to the document source although
the item id is never reassigned. They are no longer counted among
the set of total items.
* "CA" designates a former item for which consensus has been
achieved in the judgment of the author, although not by any
official process.
Items reaching this state are effected in the document source
including the deletion of annotations and the elimination of
obsoleted previous treatments.
Items in this state are still counted among the total of item but
are no longer considered pending
* "CV" designates a former item for which consensus has been
achieved and officially verified.
Noveck Expires 28 October 2024 [Page 127]
Internet-Draft Nfsv4 ACLs April 2024
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
accept or reject it. This would enable, once all items are dealt
with, an eventual request for publication as an RFC, with this
appendix having been deleted.
The consensus item in the followig table can be divided into three
groups, based on the ssociated numeric id.
* Those with ids less than 62 were created as part of the security
and documeny and transferred to this one as part of the doument
split.
Noveck Expires 28 October 2024 [Page 128]
Internet-Draft Nfsv4 ACLs April 2024
* Those with ids between 62 and 65 are the result of splitting item
created as part of the security that now adress issues in bo both
documents
* Those with id 100 and above were created after the document split.
In most case, there is no connection to material within the
security document.
+===+====+==================+=======================================+
|# |Type| ...References... | Substance |
+===+====+==================+=======================================+
|3 |BE | #3a in S 5.2 | 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 2.3 | Elimination of uses of SHOULD |
| | | | believed inappropriate in the |
| | | #4b in S 3.6 | descriptions of ACEs and |
| | | | clarification of ongoing use of |
| | | #4c in S 5.2 | SHOULD. |
| | | | |
| | | #4d in S 5.2.1 | |
| | | | |
| | | #4e in S 5.2.3 | |
| | | | |
| | | #4f in S 5.2.4 | |
| | | | |
| | | #4g in S 5.3.1 | |
+---+----+------------------+---------------------------------------+
|5 |NE | #5a in S 5.2 | Changes needes in treatment of |
| | | | ACCESS, including the following: |
| | | #5b in S 5.2.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 |
Noveck Expires 28 October 2024 [Page 129]
Internet-Draft Nfsv4 ACLs April 2024
| | | | authorization. |
| | | | |
| | | | Given the inability of the server |
| | | | to determine which bits are being |
| | | | tested by the client, determiing |
| | | | when success or failure has |
| | | | occurred is impossible. As a |
| | | | result it appears best to given |
| | | | the server freedom, in any |
| | | | particular case, to decide |
| | | | whether an ACCESS has succeeed or |
| | | | failed in determining whether it |
| | | | constitutes a recordable event. |
| | | | |
+---+----+------------------+---------------------------------------+
|7 |BE | #7a in S 5.2.1 | Clarification of relationship |
| | | | between READ_DATA and EXECUTE. |
| | | #7b in S 5.2.3 | |
+---+----+------------------+---------------------------------------+
|8 |CI | #8a in S 5.2.1 | Revised discussion of relationship |
| | | | between WRITE_DATA and APPEND_DATA. |
| | | #8b in S 5.2.3 | |
| | | | |
| | | #8c in S 5.2.4 | |
+---+----+------------------+---------------------------------------+
|9 |CI | #9a in S 5.2.1 | Clarification of how ADD_DIRECTORY |
| | | | relates to RENAME. |
| | | #9b in S 5.2.4 | |
| | | | We are assuming that the cros- |
| | | | directory and within-directory cases |
| | | | need to be treated differently. |
+---+----+------------------+---------------------------------------+
|10 |WI | #10a in S 5.2.6 | Possible revisions in handling of |
| | | | the masks WRITE_RETENTION and |
| | | | WRITE_RETENTION_HOLD. |
+---+----+------------------+---------------------------------------+
|11 |CI | #11a in S 5.2.6 | Explicit recommendation and |
| | | | requirements for mask granularity, |
| | | | replacing the previous treatment |
| | | | which gave the server license to |
| | | | ignore most of the previous section, |
| | | | placing clients in an unfortunate |
| | | | situation. |
+---+----+------------------+---------------------------------------+
|12 |BC | #12a in S 5.2.10 | Revised treatment of directory entry |
| | | | deletion. |
| | | #12b in S 5.2.11 | |
+---+----+------------------+---------------------------------------+
Noveck Expires 28 October 2024 [Page 130]
Internet-Draft Nfsv4 ACLs April 2024
|13 |BC | #13a in 5.3 | Attempt to put some reasonable |
| | | | limits on possible non-support (or |
| | | #13b in 5.3.1 | variations in the support provided) |
| | | | for the ACE flags. This is to |
| | | #13c in 5.3.2 | replace a situation in which the |
| | | | client has no real way to deal with |
| | | #13d in 5.3.3 | the freedom granted to server |
| | | | implementations. |
+---+----+------------------+---------------------------------------+
|14 |BC | #14a in S 3 | Explicit discussion of the case in |
| | | | which aclsupport is not supported. |
| | | #14b in S 3.5 | |
+---+----+------------------+---------------------------------------+
|15 |BC | #15a in S 3.5 | Handling of the proper relationship |
| | | | between support for ALLOW and DENY |
| | | | ACEs. |
+---+----+------------------+---------------------------------------+
|16 |NM | #16a in S 3.4 | Discussion of coherence of acl, |
| | | | sacl, and dacl attributes. |
+---+----+------------------+---------------------------------------+
|26 |CI | #26a in S 8.2 | Decide how ACEs with who values |
| | | | other than OWNER@, Group, or |
| | | #26 in S 8.7.3 | EVERYONE@ are be dealt with when |
| | | | setting mode. |
+---+----+------------------+---------------------------------------+
|27 |CI | #27a in S 8.2 | Concerns the possible existence of |
| | | | multiple methods of computing a mode |
| | | #27b in S 8.3 | from an acl that clients can depend |
| | | | on, and the proper relationship |
| | | #27c in S 8.4 | among these methods. |
+---+----+------------------+---------------------------------------+
|28 |WI | #28a in S 8.2 | Decide how to address flags in |
| | | | mapping to/from reverse- slope |
| | | #28b in S 8.3 | modes. |
| | | | |
| | | #28 in S 8.7.3 | |
+---+----+------------------+---------------------------------------+
|29 |BC | #29 in S 8.7.3 | Address the coordination of mode and |
| | | | ACL-based attributes in a unified |
| | | | way for all minor versions. |
+---+----+------------------+---------------------------------------+
|30 |CI | #30a in S 4.2 | New proposed treatment of setting |
| | | | mode incorporating some consequences |
| | | #30b in S 8.7.1 | of anticipated decisions regarding |
| | | | other consensus items (#26, #28, |
| | | #30c in S 8.7.2 | #29) |
| | | | |
| | | #30d in S 8.7.3 | |
Noveck Expires 28 October 2024 [Page 131]
Internet-Draft Nfsv4 ACLs April 2024
| | | | |
| | | #30e in S 8.7.4 | |
| | | | |
| | | #30f in S 8.7.5 | |
| | | | |
| | | #30g in S 8.7.6 | |
+---+----+------------------+---------------------------------------+
|31 |WI | #31a in S 8.7.3 | Need to deal with mask bits |
| | | | ACE4_READ_ATTRIBUTES, |
| | | | ACE4_WRITE_RETENTION, |
| | | | ACE4_WRITE_RETENTION_HOLD, |
| | | | ACE4_READ_ACL to reflect the |
| | | | semantics of the mode attribute. |
+---+----+------------------+---------------------------------------+
|50 |BC | #50a in S 5.4 | Revise handling of "special" who |
| | | | values, making it clear for which |
| | | #50b in S 5.4.1 | ones "special" is a euphemism for |
| | | | "semantics-challenged". |
| | | #50c in S 5.4.2 | |
+---+----+------------------+---------------------------------------+
|51 |BC | #51a in S 5.4 | Clarify the handling of the group |
| | | | bit for the special who values. |
+---+----+------------------+---------------------------------------+
|61 |RT | #61a in S 3.3 | Proposal to distinguish support for |
| | | | UNIX and NFSv4 ACLS, depending on |
| | | #61b in S 3.5 | the results returned by the |
| | | | Aclsupport attribute. |
| | | #61c in S 3.8 | |
| | | | Modified to e conditional on the |
| | | #61d in S 4 | absence of Aclfeature attribute |
| | | | because of the need to effectively |
| | | #61e in S 4.2 | handle hybrids. |
| | | | |
| | | #61f in S 8.3 | Many previous instances of this item |
| | | | now include Item #105 as well, since |
| | | #61g in S 8.4 | Aclfeature, when supported, replaces |
| | | | the attempt to infer the semantic |
| | | | model more simply. |
+---+----+------------------+---------------------------------------+
|62 |NE | #62a in S 5.2.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 8.1 | Revised description of co-ordination |
Noveck Expires 28 October 2024 [Page 132]
Internet-Draft Nfsv4 ACLs April 2024
| | | | of acl and mode attributes to apply |
| | | #63b in S 8.2 | to NFSv4 as a whole. While this |
| | | | includes many aspects of the shift |
| | | #63c in S 8.5 | to be more specific about the co- |
| | | | ordination requirements including |
| | | #63d in S 8.8 | addressing apparently unmotivated |
| | | | uses of the terms "SHOULD" and |
| | | #63e in S 8.10 | "SHOULD NOT", it excludes some |
| | | | arguably related matters dealt with |
| | | #63f in S 8.11 | as Consensus Items #26 and #27. |
| | | | |
| | | | Needs to be considered together with |
| | | | Item #25 in the security document |
| | | | proper. |
+---+----+------------------+---------------------------------------+
|64 |WI | #64a in S 8.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.4 | Designation of the Acl, Dacl, and |
| | | | Sacl attributes as Experimental in |
| | | #65b 3.7 | previous specifications even though |
| | | | still formally OPTIONAL. |
| | | #65c 3.8 | |
| | | | Note that this is separate from the |
| | | | possibility of sufficiently |
| | | | clarifying the description of the |
| | | | acl, dacl, and sacl attributes to |
| | | | make the Experimental designation |
| | | | unnecessary, or providing other |
| | | | means of semantic model discovery, |
| | | | which will be covered as Item #110. |
| | | | |
| | | | Needs to be considered together with |
| | | | Item #58 in the security document |
| | | | proper. |
+---+----+------------------+---------------------------------------+
|100|NE | | Needs to be considered together with |
| | | | Item #66 in the security document |
| | | | wich deal with parallel issues |
| | | | regarding POSIX-based authorization. |
| | | | |
| | | | Address issues regarding |
Noveck Expires 28 October 2024 [Page 133]
Internet-Draft Nfsv4 ACLs April 2024
| | | | ACE4_{READ,WRITE}_NAMED_ATTRIBUTES. |
+---+----+------------------+---------------------------------------+
|101|NM | #101a in S 5.2.3 | Inclusion of the action of READLINK |
| | | | as authorized by ACE4_READ_DATA |
+---+----+------------------+---------------------------------------+
|102|NE | #102a in S 5.2 | Mask bits have to be dealt with that |
| | | | are not simply finer-grained |
| | | #102b in S 5.2.5 | correlates of the three POSIX |
| | | | privilege bits. |
+---+----+------------------+---------------------------------------+
|103|NM | #103a in S 5.2 | Classification of masks bits based |
| | | | on relationship to permission bits |
| | | | and existence of implementations. |
+---+----+------------------+---------------------------------------+
|104|NE | #104a in S 1.3 | Presentation of UNIX ACLs as the |
| | | | basis of the feature, rather than |
| | | | the possibly aspirational NFSv4 ACLs |
| | | | |
| | | | Includes work to mention of deletion |
| | | | of Extension features that were |
| | | | never implemented, where the WG |
| | | | agrees. |
+---+----+------------------+---------------------------------------+
|105|NE | #105a in S 1.3.1 | Support for discovery of ACL |
| | | | extensions using the Aclfeature |
| | | #105b in S 1.3.4 | attribute or by using inference |
| | | | rules, to help in those case in |
| | | #105c in S 3.6 | which it is not supported. |
| | | | |
| | | #105d in S 3.8 | Presumes Item #104 has been |
| | | | implemented as well. |
| | | #105e in S 4 | |
| | | | |
| | | #105f in S 4.1 | |
| | | | |
| | | #105g in S 4.2 | |
| | | | |
| | | #105h in S 4.3 | |
| | | | |
| | | #105i in S 5.1.2 | |
| | | | |
| | | #105j in S 5.1.3 | |
| | | | |
| | | #105k in S 5.3.2 | |
| | | | |
| | | #105l in S 5.4.1 | |
| | | | |
| | | #105m in S 8.3 | |
Noveck Expires 28 October 2024 [Page 134]
Internet-Draft Nfsv4 ACLs April 2024
| | | | |
| | | #105n in S 8.4 | |
+---+----+------------------+---------------------------------------+
|106|BC | #106a in S 5.2.3 | More detail about cases in which |
| | | | OPEN is affected by ACE mask bits, |
| | | #106b in S 5.2.4 | including the dependence on the type |
| | | | of OPEN. |
+---+----+------------------+---------------------------------------+
|107|BC | #107a in S 5.2.3 | More detail about use of |
| | | | ACE4_WRITE_DATA and the dependence |
| | | #107b in S 5.2.4 | on the support for finer-grained |
| | | | bits in descriptions of ACE mask |
| | | | bits. |
+---+----+------------------+---------------------------------------+
|108|BC | | Distinguish mask bit treatments |
| | | | depending on the type of the objects |
+---+----+------------------+---------------------------------------+
|109|BC | | More detail about cases in which |
| | | | RENAME is affected by ACE mask bits |
| | | | including the dependence on the |
| | | | directories for wich the mask bits, |
| | | | distinguising the within-directory |
| | | | and cross-directory cases, and |
| | | | dealing appropiately with the |
| | | | rename-over case. |
+---+----+------------------+---------------------------------------+
|110|NM | #110a in S 3.5 | Make explicit reference to the ACL |
| | | | semantics provided by the server, |
| | | #110b in S 3.8 | assuming this can be known somehow, |
| | | | rather than by hand-wavily assuming |
| | | #110c in S 4 | that clients will somehow get by. |
| | | | |
| | | #110d in S 4.2 | Assumes that Item #61 or #105 is |
| | | | present or some replacement. |
| | | #110e in S 4.3 | |
| | | | |
| | | #110f in S 8.3 | |
| | | | |
| | | #110g in S 8.3 | |
+---+----+------------------+---------------------------------------+
|111|WI | #111a in S 5.2 | Addresss more substantively the |
| | | | handling of the mask bits |
| | | #111b in S 5.2.3 | ACE4_{READ,WRITE}_NAMED_ATTRIBUTES. |
| | | | |
| | | #111c in S 5.2.4 | Part of the eventual necessary |
| | | | resolution, most likely best |
| | | #111d in S 5.2.5 | deferred until we learn about an |
| | | | actual implementation, will need to |
Noveck Expires 28 October 2024 [Page 135]
Internet-Draft Nfsv4 ACLs April 2024
| | | | tackle serously the question of |
| | | | whether ACE4_WRITE_NAMED_ATTRIBUTES |
| | | | is somehow a finer-grained variant |
| | | | of the write privilege bits. While |
| | | | this is arguanle despite it refers |
| | | | to a different object, the |
| | | | coresponding issue with regard to |
| | | | ACE4_READ_NAMED_ATTRIBUTES is more |
| | | | troublesome in that it is a finer- |
| | | | grained variant of the or of two |
| | | | privilege bits: R and X. |
+---+----+------------------+---------------------------------------+
|112|WI | #112a in S 5.2.6 | Address the validity/utility of |
| | | | ACE4_READ_ATTRIBUTES. This might be |
| | | | unnecessary, if Aclfearure were |
| | | | implemented, since non-support would |
| | | | be a available as an option likely |
| | | | to be commonly chosen. |
+---+----+------------------+---------------------------------------+
|113|NE | #113a in S 4.4 | Clarify how ACE mask bits defined in |
| | | | Section 5.2.4 are to be dealt with |
| | | | by clients when the server does nt |
| | | | spport those mask bits, as migh be |
| | | | the case when he server supports the |
| | | | UNIX ACL model. |
+---+----+------------------+---------------------------------------+
Table 4
The following table summarizes the issues in each particular state.
Noveck Expires 28 October 2024 [Page 136]
Internet-Draft Nfsv4 ACLs April 2024
+===============+=====+====================+
| Type | Cnt | Detail |
+===============+=====+====================+
| BC | 11 | 12, 13, 14, 15 |
| | | |
| | | 29, 50, 51 |
| | | |
| | | 106, 107, 108, 108 |
+---------------+-----+--------------------+
| BE | 2 | 3, 7 |
+---------------+-----+--------------------+
| CI | 8 | 4, 8, 9, 11 |
| | | |
| | | 26, 27, 30, 63 |
+---------------+-----+--------------------+
| EI | 7 | 5, 62, 100, 102 |
| | | |
| | | 104, 105, 113 |
+---------------+-----+--------------------+
| NM | 4 | 16, 101, 103, 110 |
+---------------+-----+--------------------+
| NS | 1 | 65 |
+---------------+-----+--------------------+
| WI | 6 | 10, 28, 31, 64 |
| | | |
| | | 111, 112 |
+---------------+-----+--------------------+
| Non-terminal) | 39 | BC, BE, CI, NE |
| | | |
| | | NM, NS, WS |
+---------------+-----+--------------------+
| RT | 1 | 61 |
+---------------+-----+--------------------+
| Terminal | 1 | RT |
+---------------+-----+--------------------+
| All | 40 | Grand total for |
| | | above table. |
+---------------+-----+--------------------+
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.
Noveck Expires 28 October 2024 [Page 137]
Internet-Draft Nfsv4 ACLs April 2024
The author wishes to draw people's attention to Nico Williams' remark
that NFSv4 security was not so bad, except that there was no
provision for authentication of the client peer. This perceptive
remark, which now seems like common sense, did not seem so when made,
but it has served as a beacon for those working on putting NFSv4
security on a firmer footing. We appreciate Nico's perceptive
guidance.
The author wishes to thank Bruce Fields for his helpful comments
regarding ACL support which had a major role in the evolution of this
document.
The author wishes to acknowledge the important role of the authors of
RPC-with-TLS, Chuck Lever and Trond Myklebust, in moving the NFS
security agenda forward and thank them for all their efforts to
improve NFS security.
The author wishes to thank Chuck Lever for his many helpful comments
about nfsv4 security issues, his explanation of many unclear points,
and much important guidance he provided that is reflected in this
document, including his work to streamline the security negotiation
process by the definition of new pseudo-flavors.
The author wishes to thank Rick Macklem for his help in resolving
NFSv4 security issues. These include clarifying possible server
policies regarding RPC-with-TLS, helping to clarify "owner-override
semantics" and bringing to the Working Group's attention the
possibility of deriving limited principal identification from client
peer authentication while still staying within the boundaries of RPC-
with-TLS.
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 28 October 2024 [Page 138]