POSIX Draft ACL support for Network File System Version 4, Minor Version 2

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 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 and . 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.

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 when, and only when, they appear in all capitals, as shown here.

Protocol Extension Considerations This document presents an extension to minor version 2 of the NFSv4 protocol as described in . 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 does not define NFSv4.2 as non-extensible, so treats it as an extensible minor version. This Standards Track RFC extends NFSv4.2 but does not update or .

XDR definitions for new attributes This section defines the XDR structures needed for the new OPTIONAL 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; };

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

OPTIONAL New Attributes - List and Definition References The list of New OPTIONAL attributes appears in . 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.

Name	Id	Data Type	Acc
server_acl_model	NN	aclmodel4	R
posix_default_acl	NN	posixace4<>	RW
posix_access_acl	NN	posixace4<>	RW

Definitions of new recommended attributes

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.

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.

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

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.

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.

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.

Implementation Status 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.

FreeBSD NFS server and client

Organization:: FreeBSD Project
URL:
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.