[nfsv4] Review of draft-ietf-nfsv4-posix-acls-02

[Chuck Lever <[e-mail]>]

Rick, thanks for un-expiring the posix-acls draft!

This review is as an individual contributor, not a chair position. It was prepared with AI assistance against the -02 text and the list archive, and I have checked each point below against the draft myself.

The design of the proposed extension looks settled to me. The items below are what I think has to be resolved in the text before a WGLC can succeed. For brevity, I'm skipping editorial and nit-level comments in this pass.


Issues

1. Attribute numbers 89 and 90 collide with draft-haynes-nfsv4-flexfiles-v2-08. Section 10 of this draft declares FATTR4_ACL_TRUEFORM = 89 and FATTR4_ACL_TRUEFORM_SCOPE = 90; the flexfiles-v2 XDR declares FATTR4_CODING_BLOCK_SIZE = 89 and FATTR4_CHUNKED_DATA_FILE = 90. Neighbouring numbers are already taken (delstid 83-86, uncacheable-files 87, uncacheable-directories 88). Rick and Tom, please coordinate on which draft moves, and record the assignment in Section 8 the way uncacheable-directories does for 88. Since posix-acls is already a WG document, IMHO it has squatters rights to the values 89 and 90.

2. Section 11 does not meet BCP 72 Section 5. It says only that accurate ACLs "should improve file system security when ACLs are used". Three things the body already establishes need to be stated there. First, RFC 8881 Section 6.2.1.3.1 binds ACE4_READ_ACL to "GETATTR of acl, dacl, or sacl" and ACE4_WRITE_ACL to "SETATTR of acl and mode"; the draft never says whether posix_access_acl and posix_default_acl are governed by those bits, or what governs them on a POSIX-model server. Second, Section 6 says an extension-unaware client "may set the NFSv4 ACL (acl/dacl) attribute and switch a file object's acl_trueform to ACL_MODEL_NFS4", and the Section 6 bullets say the stored POSIX ACLs are then deleted; that is a residual risk and belongs in Section 11 with an applicability note. Third, mode synchronization (Section 6) and GETATTR atomicity (Section 7) are SHOULDs; Section 11 should say what a client that uses mode for local access decisions can be told by a server that does not honour them. RFC 8275 Section 6 is about the right size.

3. Section 5 leaves the create path undecided when a client sends mode. It requires that in a directory with a POSIX default ACL "the low-order nine bits of the mode MUST be specified by mode_umask", but Section 3 promises that extension-unaware clients continue to interoperate, and RFC 8275 Section 5 only says a client "should use mode_umask in place of mode". The draft does not say whether a server receiving mode intersects the default ACL with the already-umasked mode, rejects the operation, or ignores the default ACL. The server side is also unstated: RFC 8275 Section 5 says mu_umask is ignored when "an object inherits any ACEs from its parent directory", written for NFSv4 ACEs, and this draft never says a POSIX default ACL counts as inherited ACEs for that purpose. Please state both.

4. Section 4 misdescribes the mask. It says "the permission bit must be set in both the Group_obj or Group ACE as well as the Mask ACE for permission to be granted." In POSIX draft ACLs the mask also bounds named User entries (acl(5): "the maximum access rights that can be granted by entries of type ACL_USER, ACL_GROUP_OBJ, or ACL_GROUP"). A server built from Section 4 grants a named user their full ACE where every deployed implementation masks it. The later sentence about group mode bits "limiting the upper bound for the Group_obj and Group ACEs" has the same gap.

5. The relationship between mode and the POSIX access ACL is normative only through a SHOULD that points at descriptive text. Section 6 says mode "SHOULD be synchronized with the true form ACL ... synchronization is described in Section 4", and Section 4 introduces itself as "a brief description of POSIX ACLs as they are currently implemented by various vendors" with no requirements language. RFC 8881 Section 6.4.1 states the NFSv4 counterparts as server requirements. The draft needs to decide whether a server supporting posix_access_acl MUST keep mode and the access ACL consistent, and if so promote the Section 4 rules. Pali's 2024 point that group mode bits reflecting the mask conflicts with RFC 8881's definition of mode still has no answer on the list, and belongs in the same decision.

6. The thread on my review of draft-rmacklem-nfsv4-posix-acls-13 (https://mailarchive.ietf.org/arch/msg/nfsv4/kEHzr0uvQ0XakdV-I3jILV2QIPQ/) ended with several points still open: the behaviour of a server that supports both ACL models on one file system, what a client is expected to do with acl_trueform_scope, and how an extension-unaware client on an ACL_SCOPE_FILE_OBJECT server is protected from silently converting a POSIX ACL to an NFSv4 ACL. My last message in that thread asked why a client that can ignore acl_trueform_scope entirely needs it in the protocol. -00 through -02 do not address those points and there has been no follow-up on the list.


Other comments

Section 9.3 says deleting a default ACL "might set the file object's acl_trueform to ACL_MODEL_NONE". Under ACL_SCOPE_FILE_OBJECT a directory can be ACL_MODEL_POSIX_DRAFT with only a default ACL. What does GETATTR of posix_access_acl return in that state, and is "might" a server choice?

The typedefs binding the attribute numbers to their XDR types (typedef aclmodel4 fattr4_acl_trueform; and the other three) were added in -01 and removed in -02. Without them the XDR never ties attribute 89 to aclmodel4. Was the removal intended?

Section 13.1 says the FreeBSD implementation "does not explore the case of ACL_SCOPE_FILE_OBJECT", and the Linux patch is tested against that server. The Section 6 rules for that scope are the most intricate part of the document and nothing has exercised them. It would help a WGLC if something did, or if the draft said which implementation is expected to.

Both Section 14.2 references that define the ACL model are informative, and [IEEE] carries no locator for a withdrawn draft that cannot be found. Section 5 rests a MUST on it. Possibly add a sentence in Section 3 or 4 that this document is normative for posixace4 semantics, with [Gruenbacher] as the description of the model it follows.


--
Chuck Lever