Internet-Draft | POSIX Draft ACL support for NFSv4.2 | July 2024 |
Macklem | Expires 1 February 2025 | [Page] |
This document describes the addition of three new attributes that are used by servers to support POSIX ACLs. The term POSIX ACLs refers to the ACL component of the Portable Operating System Interface (POSIX) 1003.1e draft 17 [IEEE] document for which sponsorship was withdrawn in January 1998. Although the draft POSIX standard that describes these ACLs was never ratified, several POSIX based operating systems, such as Linux, Solaris and FreeBSD include support for them. The NFS Version 4 ACLs described in [RFC8881] henseforth referred to as NFSv4 ACLs, use a different model and attempts to map between the ACLs of these two models has not been completely successful. As such, this document proposes three new attributes that may optionally be used by an NFSv4.2 server to support ACLs that conform the afor mentioned POSIX 1003.1e draft 17.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this draft occurs on the NFSv4 working group mailing list, archived at https://mailarchive.ietf.org/arch/browse/nfsv4/. Working Group information is available at https://datatracker.ietf.org/wg/nfsv4/about/.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 1 February 2025.¶
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.¶
Implementation experience with mapping between NFSv4 and POSIX ACLs has not been completely successful. For example, if a NFSv4 ACL is applied to a server file that actaully stores POSIX ACLs on file system objects and is set via SETATTR and then retrieved via GETATTR, the ACL will often not be the same, since the mapping algorithm cannot do an exact mapping between them. The expired IETF draft [Eriksen] explains the mapping algorithms. A server may optionally choose to use these mapping algorithms and/or support the new attributes proposed by this document to set/get the POSIX ACLs.¶
As such, this document proposes three new attributes as an extension of NFSv4.2 which can be used by SETATTR and GETATTR to handle POSIX ACLs. If a server chooses to support these attributes, it MUST support all three of them.¶
For the semantics applied to POSIX ACLs by a server, please read the informational references [IEEE] and [Grunbacher]. However, there is a brief explanation of the aspects of POSIX ACLs that might affect the on-the-wire ACL or when the ACLs may be set.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document presents an extension to minor version 2 of the NFSv4 protocol as described in [RFC8178]. It describes new OPTIONAL features. NFSv4.2 servers and clients implemented without knowledge of this extension will continue to interoperate with clients and servers that are aware of the extension (whether or not they support it).¶
Note that [RFC7862] does not define NFSv4.2 as non-extensible, so [RFC8178] treats it as an extensible minor version. This Standards Track RFC extends NFSv4.2 but does not update [RFC7862] or [RFC8178].¶
This section defines the XDR structures needed for the new ACL related attributes.¶
enum aclmodel4 { ACL_MODEL_NFS4 = 1, ACL_MODEL_POSIX_DRAFT = 2 }; enum posixacetag4 { POSIXACE4_TAG_USER_OBJ = 1, POSIXACE4_TAG_USER = 2, POSIXACE4_TAG_GROUP_OBJ = 3, POSIXACE4_TAG_GROUP = 4, POSIXACE4_TAG_MASK = 5, POSIXACE4_TAG_OTHER = 6 }; typedef uint32_t posixaceperm4; /* Bit definitions for posixaceperm4. */ const POSIXACE4_PERM_EXECUTE = 0x00000001; const POSIXACE4_PERM_WRITE = 0x00000002; const POSIXACE4_PERM_READ = 0x00000004; struct posixace4 { posixacetag4 tag; posixaceperm4 perm; utf8str_mixed who; };¶
A POSIX ACL always has one ACE for each of POSIXACE4_TAG_USER_OBJ, POSIXACE4_TAG_GROUP_OBJ and POSIXACE4_TAG_OTHER. If the ACL consists only of these three ACEs, it is referred to as a minimal POSIX ACL. A POSIX ACL may also have one or more POSIXACE4_TAG_USER and POSIXACE4_TAG_GROUP ACE(s). Such a POSIX ACL is referred to as an extended POSIX ACL and must have one POSIXACE4_TAG_MASK ACE. A default POSIX ACL can only be associated with directory objects and is used for inheritance. The POSIX default ACL has no effect on access.¶
For POSIX ACLs, the POSIXACE4_TAG_USER and POSIXACE4_TAG_GROUP ACE(s) are described for uids and gids by the informational references. For these new attributes, the who value will be in the same format and have the same semantics as a owner (for uid) or owner_group (for gid) attribute.¶
For POSIX ACLs, setting of the low order 9 bits of mode can change the ACL and setting of the POSIX access ACL can change the low order 9 bits of mode. As such, the ordering of setting the attributes related to mode and POSIX ACLs is important. Therefore, a client MUST not set the low order 9 bits of mode via the mode and/or mode_set_masked attributes in the same SETATTR operation as one that sets the posix_access_acl and/or posix_default_acl proposed in this document. This is required because [RFC8881] does not specify an ordering for setting attributes in a SETATTR operation.¶
For POSIX, when a new object is created in a directory that has a POSIX default ACL on it, the inherited ACL includes the intersection between the mode specified by the POSIX system call and the posixaceperm4 fields of the POSIX default ACL.¶
For NFSv4 operations that create new file objects (OPEN/OPEN4_CREATE, CREATE) the low order 9 bits of the mode SHOULD be specified by either mode or mode_set_masked in the setable attributes for the operation. The attributes posix_access_acl and posix_default_acl MUST not be specified in the setable attributes for the operation, so that the server may use the low order 9 bits of the mode, along with the POSIX default ACL, to create the new inherited ACL(s). If the client needs to set the POSIX access ACL to something different than what will be generated via inheritance, setting the low order 9 bits of mode to zero during object creation will avoid any access vulnerability between the time of object creation and setting of the POSIX access ACL via a subsequent SETATTR operation.¶
The list of New OPTIONAL attributes appears in Table 1. The meaning of the columns of the table are:¶
Name | Id | Data Type | Acc | Defined in: |
---|---|---|---|---|
server_acl_model | NN | aclmodel4 | R | Section 7.1 |
posix_default_acl | NN | posixace4<> | RW | Section 7.2 |
posix_access_acl | NN | posixace4<> | RW | Section 7.3 |
This attribute is a read-only attribute that describes which ACL model (NFSv4 vs POSIX) is used for the ACL stored on the file object on the NFSv4.2 server.¶
It is a per-file system attribute.¶
This attribute allows the client to choose whether to use the acl attribute or the posix_access_acl and posix_default_acl attributes when doing GETATTR/SETATTR. Do so avoids any mapping between NFSv4 and POSIX ACLs being done by the server during GETATTR/SETATTR operations.¶
This attribute specifies the POSIX default ACL for a directory. For the posixacetag4 values of POSIXACE4_TAG_USER_OBJ, POSIXACE4_TAG_GROUP_OBJ, POSIXACE4_TAG_MASK and POSIXACE4_TAG_OTHER the who field MUST be of zero length. For the posxiacetag4 values of POSIXACE4_TAG_USER and POSIXACE4_TAG_GROUP, the who field must be in the same format as would be used for the owner or owner_group attribute. For all POSIXACE4_TAG_USER ACEs in the ACL, each who value must represent a different owner than the who value in other POSIXACE4_TAG_USER ACEs in the ACL. The same applies to the who values for all POSIXACE4_TAG_GROUP ACEs in the ACL, where the who values represent owner_groups. Since a POSIX default ACL only applies to directories, a SETATTR of the posix_default_acl for a non-directory object MUST reply NFS4ERR_INVAL. If SETATTR of a POSIX extended ACL does not have a POSIXACE4_TAG_MASK ACE, the SETATTR of the ACL MUST reply NFS4ERR_INVAL. Doing a SETATTR for a posix_default_acl of zero length deletes the POSIX default ACL, if one exists. If no POSIX default ACL exists, this is a no-op. If a directory does not have a POSIX default ACL, a GETATTR for the posix_default_acl attribute will reply with an ACL of zero length.¶
This attribute is a per-file system object attribute.¶
Without this option, a file server that natively stores POSIX default ACLs must map between the POSIX ACL and a NFSv4 ACL to support the acl attribute. It also must somehow combine the POSIX default ACL used for inheritance with the POSIX access ACL used for access control to the directory itself during the mapping, since a directory file object can only have, at most, one NFSv4 ACL.¶
This attribute specifies the POSIX access ACL for a file object. For a GETATTR, if a file object does not have a posix_access_acl stored for it, the server MUST generate a minimal one from the file's mode, owner and owner_group attributes. For the posixacetag4 values of POSIXACE4_TAG_USER_OBJ, POSIXACE4_TAG_GROUP_OBJ, POSIXACE4_TAG_MASK and POSIXACE4_TAG_OTHER the who field MUST be of zero length. For the posxiacetag4 values of POSIXACE4_TAG_USER and POSIXACE4_TAG_GROUP, the who field must be in the same format as would be used for the owner or owner_group attribute. For all POSIXACE4_TAG_USER ACEs in the ACL, each who value must represent a different owner than the who value in other POSIXACE4_TAG_USER ACEs in the ACL. The same applies to the who values for all POSIXACE4_TAG_GROUP ACEs in the ACL, where the who values represent owner_groups. For a SETATTR, a posix_access_acl of zero length deletes the POSIX access ACL, returning it to the minimal access ACL based on mode, owner and owner_group. If SETATTR of a POSIX extended ACL does not have a POSIXACE4_TAG_MASK ACE, the SETATTR of the ACL MUST reply NFS4ERR_INVAL.¶
This attribute is a per-file system object attribute.¶
Without this option, a file server that natively stores POSIX access ACLs must map between the POSIX ACL and a NFSv4 ACL to support the acl attribute.¶
This section is to be removed before publishing as an RFC.¶
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs.¶
Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶
XXX¶