Network File System Version 4 R. Macklem Internet-Draft FreeBSD Intended status: Standards Track 1 August 2024 Expires: 2 February 2025 POSIX Draft ACL support for Network File System Version 4, Minor Version 2 draft-rmacklem-nfsv4-posix-acls-01 Abstract 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 (NFSv4) 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 NFS Version 4, minor version 2 (NFSv4.2) server to support ACLs that conform the afor mentioned POSIX 1003.1e draft 17. Note This note is to be removed before publishing as an RFC. Discussion of this draft occurs on the NFSv4 working group mailing list (nfsv4@ietf.org), archived at https://mailarchive.ietf.org/arch/browse/nfsv4/. Working Group information is available at https://datatracker.ietf.org/wg/nfsv4/ about/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Macklem Expires 2 February 2025 [Page 1] Internet-Draft POSIX Draft ACL support for NFSv4.2 August 2024 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 2 February 2025. 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Extension Considerations . . . . . . . . . . . . . . 3 4. XDR definitions for new attributes . . . . . . . . . . . . . 3 5. POSIX ACL Considerations . . . . . . . . . . . . . . . . . . 4 6. OPTIONAL New Attributes - List and Definition References . . 5 7. Definitions of new recommended attributes . . . . . . . . . . 6 7.1. Attribute NN: server_acl_model . . . . . . . . . . . . . 6 7.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 6 7.2. Attribute NN: posix_default_acl . . . . . . . . . . . . . 6 7.2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 7 7.3. Attribute NN: posix_access_acl . . . . . . . . . . . . . 7 7.3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 7 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 8.1. FreeBSD NFS server and client . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informational References . . . . . . . . . . . . . . . . 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Macklem Expires 2 February 2025 [Page 2] Internet-Draft POSIX Draft ACL support for NFSv4.2 August 2024 1. Introduction 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 actually stores POSIX ACLs on file system objects and is set via SETATTR and then retrieved via GETATTR/ READDIR, 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/READDIR 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 [Grünbacher]. 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. 2. Requirements Language 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. 3. Protocol Extension Considerations 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]. 4. XDR definitions for new attributes This section defines the XDR structures needed for the new OPTIONAL ACL related attributes. Macklem Expires 2 February 2025 [Page 3] Internet-Draft POSIX Draft ACL support for NFSv4.2 August 2024 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; }; 5. POSIX ACL Considerations 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/or 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 as well. A POSIX access ACL defines permissions for a file object. A POSIX default 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 Macklem Expires 2 February 2025 [Page 4] Internet-Draft POSIX Draft ACL support for NFSv4.2 August 2024 related to mode and POSIX ACLs is important. Therefore, a client MUST not set the low order 9 bits of mode via the mode 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. 6. OPTIONAL New Attributes - List and Definition References The list of New OPTIONAL attributes appears in Table 1. The meaning of the columns of the table are: Name: The name of the attribute. Id: The number assigned to the attribute. Data Type: The XDR data type of the attribute. Acc: Access allowed to the attribute. R means read-only. RW means read/write. Defined in: The section of this specification that describes the attribute. Macklem Expires 2 February 2025 [Page 5] Internet-Draft POSIX Draft ACL support for NFSv4.2 August 2024 +===================+====+=============+=====+=============+ | 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 | +-------------------+----+-------------+-----+-------------+ Table 1 7. Definitions of new recommended attributes 7.1. Attribute NN: server_acl_model 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. 7.1.1. Rationale 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/READDIR. Doing so avoids any mapping between NFSv4 and POSIX ACLs being done by the server during GETATTR/SETATTR/READDIR operations. 7.2. Attribute NN: posix_default_acl 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, respectively. There MUST only be one POSIXACE4_TAG_USER ACE in the ACL for each user as represented by the who value. Similarily, there MUST be only one POSIXACE4_TAR_GROUP in the ACL for each group as represented by the who value. 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 Macklem Expires 2 February 2025 [Page 6] Internet-Draft POSIX Draft ACL support for NFSv4.2 August 2024 directory does not have a POSIX default ACL, a GETATTR/READDIR for the posix_default_acl attribute will reply with an ACL of zero length. This attribute is a per-file system object attribute. 7.2.1. Rationale 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. 7.3. Attribute NN: posix_access_acl This attribute specifies the POSIX access ACL for a file object. For a GETATTR/READDIR, 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. 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, respectively. There MUST only be one POSIXACE4_TAG_USER ACE in the ACL for each user as represented by the who value. Similarily, there MUST be only one POSIXACE4_TAR_GROUP in the ACL for each group as represented by the who value. 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. 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. 7.3.1. Rationale 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. 8. Implementation Status This section is to be removed before publishing as an RFC. Macklem Expires 2 February 2025 [Page 7] Internet-Draft POSIX Draft ACL support for NFSv4.2 August 2024 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. 8.1. FreeBSD NFS server and client Organization: FreeBSD Project URL: https://www.freebsd.org Maturity: Experimental software based on the current document. Coverage: The posix_default_acl and posix_access_acl attributes described in this document were implemented for the UFS file system configured to store POSIX ACLs. Licensing: BSD Implementation experience: The setfacl and getfacl commands appeared to function correctly. 9. References 9.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, . [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, November 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Macklem Expires 2 February 2025 [Page 8] Internet-Draft POSIX Draft ACL support for NFSv4.2 August 2024 [RFC8178] Noveck, D., "Rules for NFSv4 Extensions and Minor Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017, . [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, . 9.2. Informational References [Eriksen] Eriksen, M. and J. Fields, "Mapping Between NFSv4 and Posix Draft ACLs", August 2006. [Grünbacher] Grünbacher, A., "POSIX Access Control Lists on Linux", USENIX 2003 Annual Technical Conference Proceedings, June 2003. [IEEE] Institute of Electrical and Electronics Engineers, "IEEE 1003.1e and 1003.2c: Draft Standard for Information Technology--Portable Operating System Interface (POSIX)--Part 1: System Application Program Interface (API) and Part 2: Shell and Utilities, draft 17", October 1997. Acknowledgments XXX Author's Address Rick Macklem FreeBSD Project Canada Email: rmacklem@uoguelph.ca Macklem Expires 2 February 2025 [Page 9]