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

Abstract

This document proposes four new optional file attributes for NFSv4.2 to support POSIX ACLs conforming to the withdrawn POSIX 1003.1e draft 17. Although never ratified, POSIX ACLs are implemented in widely deployed operating systems. Existing attempts to map between NFSv4 and POSIX ACL models have been unsuccessful due to semantic incompatibilities. These new attributes allow servers to expose POSIX ACLs directly, avoiding lossy mapping.¶

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

5. POSIX ACL Considerations

The who field is used to represent the Id field of a POSIX ACL.¶

In the who value within the posixace4 structure that appear in these new attributes, the field is interpreted as follows:¶

• For ACEs whose tag field is POSIXACE4_TAG_USER or POSIXACE4_TAG_GROUP the who value is a UTF8-encoded Unicode string, that has the same format as a user or group as represented within other NFSv4 operations and designates the same entity. In these cases, the distinction between users and groups derives from the tag rather than a flag bit, as is done in NFSv4 ACLs. This is in contrast to how the corresponding structures are described in [Gruenbacher], where numeric uids and gids are specified for the Id.¶
• For ACEs whose tag field has other values, the who field is ignored by the receiver and there is no reason for the sender to set it to any particular value. As such, a zero length who string is appropriate.¶

For POSIX ACLs, setting of the low-order nine bits of mode can change the ACL and setting of the POSIX access ACL can change the low-order nine bits of mode. As such, the ordering of setting the attributes related to mode and POSIX ACLs is important. Therefore, in a manner similar to [RFC8881] Section 6.4.1.3, if the low-order nine bits of mode is being set via the mode/mode_set_masked attributes in the same SETATTR as posix_access_acl and/or posix_default_acl attributes, the setting of mode/mode_set_masked MUST be done before setting the POSIX ACL.¶

For [IEEE], 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. Therefore, to maintain compatible semantics with the POSIX draft, for NFSv4 operations that create new file objects (OPEN/OPEN4_CREATE, CREATE) in a directory that has a POSIX default ACL, the low-order nine bits of the mode MUST be specified by mode_umask in the setable attributes for the operation. (See [RFC8275] for details on how mode_umask is used.) If the posix_access_acl and/or posix_default_acl are also specified in the setable attributes for the operation, the setting of these attributes MUST be done after setting mode_umask and performing any POSIX ACL inheritance.¶

6. POSIX ACL vs NFSv4 ACL Considerations

The model for the ACL(s) stored on a file object and used to determine file access is referred to as the true form.¶

For servers that support the posix_access_acl and posix_default_acl attributes for a file system, each file object will have ACL(s) of one true form at any given time. For servers that return a acl_trueform_scope attribute value other than ACL_SCOPE_FILE_OBJECT, the true form MUST remain uniform for all file objects in the file system (or file server for a scope of ACL_SCOPE_SERVER). However, for servers that return a acl_trueform_scope attribute value of ACL_SCOPE_FILE_OBJECT, the value of acl_trueform can change, due to a SETATTR operation that sets any of the acl/dacl/posix_access_acl/posix_default_acl attributes. For servers that return a acl_trueform_scope attribute value of ACL_SCOPE_FILE_OBJECT, there might be different acl_trueform values for different file objects in the file system.¶

For servers where the acl_trueform_scope is not ACL_SCOPE_FILE_OBJECT, the client SHOULD only use the attributes for the file system's acl_trueform, if the client supports these extensions. Normally a server where the acl_trueform_scope in not ACL_SCOPE_FILE_OBJECT will only support the attributes used to set the file system's acl_trueform. However, servers that support the NFSv4 ACL to POSIX ACL mapping algorithm, may choose to support the NFSv4 ACLs (acl/dacl) as well as the new attributes defined in this document. If a server implements both the lossy algorithm mapping from NFSv4 ACLs to POSIX ACLs and support for these new attributes, clients may see unusual POSIX ACLs, due to the lossy mapping algorithm. The expired IETF draft [Eriksen] explains the mapping algorithms.¶

For clients that do not support these extensions, if the server supports an acl_trueform_scope of ACL_SCOPE_FILE_OBJECT, the client may set the NFSv4 ACL (acl/dacl) attribute and switch a file object's acl_trueform to ACL_MODEL_NFS4. This is unfortunately unavoidable unless the client supports the acl_trueform attribute and checks this attribute's setting before setting the NFSv4 ACL (acl/dacl) attributes.¶

The low-order nine bits of mode SHOULD be synchronized with the true form ACL for the file object. If the true form is ACL_MODEL_NFS4, synchronization is described in [RFC8881]. If the true form is ACL_MODEL_POSIX_DRAFT, synchronization is described in Section 4. If the true form is ACL_MODEL_NONE, there is no ACL to synchronize with and the low-order nine bits of mode are used to control access to the file object.¶

For servers configured to return a acl_trueform_scope attribute value of ACL_SCOPE_FILE_OBJECT and not for any others, the following apply:¶

• The server MUST return a value of ACL_MODEL_NONE for acl_trueform if there is no true form ACL(s) associated with the file object.¶
• The server MUST return a zero length posixace4 array for posix_default_acl and posix_access_acl if the value of acl_trueform for the file object is not ACL_MODEL_POSIX_DRAFT.¶
• Using SETATTR to set a zero length posixace4 array for posix_access_acl (for a file object with a true form ACL of ACL_MODEL_POSIX_DRAFT) will delete the true form ACL(s) from the file object and revert it to ACL_MODEL_NONE. If a server cannot do this, it MUST reply NFS4ERR_INVAL for the SETATTR.¶
• Using SETATTR to set the dacl or acl attribute to any value will result in the object's true form being set to ACL_MODEL_NFS4. In addition, if the object's acl model had been ACL_MODEL_POSIX_DRAFT, any existing POSIX default and access true form ACL(s) are deleted. If a server cannot do this, it MUST reply NFS4ERR_INVAL for the SETATTR. For a client to set ALARM/AUDIT ACEs without causing any change in a file object's true form, it will need to perform a SETATTR of the sacl attribute and not the acl attribute.¶
• Using SETATTR to set a posix_default_acl or posix_access_acl of non-zero length posixace4 array (for a file object with a true form ACL not ACL_MODEL_POSIX_DRAFT) will result in the object's acl model being set to ACL_MODEL_POSIX_DRAFT. In addition, if the object's acl model had been ACL_MODEL_NFS4, any dacl (all ALLOW/DENY ACEs) will be deleted from the stored ACL. If a server cannot do this, it MUST reply NFS4ERR_INVAL for the SETATTR. As noted above, any AUDIT/ALARM ACEs stored for the file object are not affected.¶

For all other configurations of acl_trueform_scope and a acl_trueform of ACL_MODEL_POSIX_DRAFT, the server MUST always return at least a minimal POSIX ACL for posix_access_acl, if that attribute is supported for the file object's file system. A server that is configured for a acl_trueform_scope other than ACL_SCOPE_FILE_OBJECT MUST NOT support the posix_default_acl and posix_access_acl unless the true form for the file system is ACL_MODEL_POSIX_DRAFT. If a client does a SETATTR of a zero length posixace4 array for posix_access_acl and the acl_trueform_scope is anything other than ACL_SCOPE_FILE_OBJECT, the server MUST reply NFS4ERR_INVAL.¶

For all acl_trueform_scope configurations, if the acl/dacl attribute(s) are specified in the same setable attributes bitmap as the posix_default_acl/posix_access_acl attribute(s), the server MUST reply NFS4ERR_INVAL.¶

7. ACL Related Attribute Atomicity

For servers that choose to implement the extensions described in this document, the following semantics with respect to ACL related attributes SHOULD be implemented.¶

To ensure a reply to operations that return attributes (GETATTR/READDIR) provide consistent results when multiple ACL related attributes (acl/dacl/posix_access_acl/posix_default_acl/acl_trueform/mode/mode_set_masked) are acquired, the server SHOULD acquire the reply values for these attributes atomically with respect to any SETATTR of any of these attributes. For this purpose, atomically means that no SETATTR of any of the above ACL related attributes can be performed during acquisition of the attribute values for a given file object.¶

9. Definitions of new optional attributes

10. XDR definitions for new attributes

This document contains the External Data Representation (XDR) [RFC4506] description of the new OPTIONAL ACL related attributes. 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 flexible file layout type:¶

   <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:¶

   sh extract.sh < spec.txt > posix_acl_prot.x

The effect of the script is to remove leading white space from each line, plus a sentinel sequence of "///".¶

The embedded XDR file header follows.¶

Note that the XDR code contained in this document depends on types from the NFSv4.1 and the nfs4_prot.x file [RFC5662]. This includes both nfs type utf8str_mixed, as well as the more generic type uint32_t.¶

<CODE BEGINS>

  ///  enum aclmodel4 {
  ///          ACL_MODEL_NFS4          = 1,
  ///          ACL_MODEL_POSIX_DRAFT   = 2,
  ///          ACL_MODEL_NONE          = 3
  ///  };
  ///
  ///  enum aclscope4 {
  ///          ACL_SCOPE_FILE_OBJECT   = 1,
  ///          ACL_SCOPE_FILE_SYSTEM   = 2,
  ///          ACL_SCOPE_SERVER        = 3
  ///  };
  ///
  ///  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;
  ///  };
  ///
  ///  %/*
  ///  % * New for POSIX ACL extension
  ///  % */
  ///  const FATTR4_ACL_TRUEFORM         = 89;
  ///  const FATTR4_ACL_TRUEFORM_SCOPE   = 90;
  ///  const FATTR4_POSIX_DEFAULT_ACL    = 91;
  ///  const FATTR4_POSIX_ACCESS_ACL     = 92;

<CODE ENDS>

14. References