Summary

  • draft-ietf-nfsv4-posix-acls-02 proposes four optional NFSv4.2 attributes so servers can expose POSIX Draft ACLs directly and identify the ACL model that is actually used for access decisions.
  • On a server with file-object scope, one older client can change the true form from POSIX Draft to NFSv4—or back again—and delete the other model's access rules while leaving AUDIT/ALARM state separate.
  • A sound control chain records capability, model and scope, ordered atomic write, coherent readback, principal resolution, mask evaluation, the actual operation decision and the resulting file or application effect.

The round trip that changed the policy

Imagine a directory whose server-side true form is a POSIX Draft ACL. A named operations group may write, another group may read, and a Mask ACE limits the maximum effective permissions of both groups. An administrator checks the directory with a POSIX-aware client and sees exactly the intended access and default ACLs.

Later, an older NFSv4 client updates the standard dacl attribute. The request succeeds. On a server whose acl_trueform_scope is the individual file object, that write can switch the object to ACL_MODEL_NFS4 and delete the POSIX access and default ACLs. A monitoring system that asks only whether the write returned success will call the change healthy. A POSIX-oriented audit that reads only posix_access_acl may now receive an empty array because POSIX is no longer the true form.

The reverse transition is equally consequential. A non-empty POSIX ACL write can switch an NFSv4 object to POSIX Draft true form and delete its stored ALLOW/DENY dacl. AUDIT and ALARM ACEs remain logically separate. Nothing in the generic phrase “the ACL was updated” tells an operator which policy model now controls access, which rules were deleted, or which audit state survived.

Revision 02 of POSIX Draft ACL support for Network File System Version 4, Minor Version 2 was posted on 7 September 2026. It is an active NFSv4 Working Group Standards Track Internet-Draft and expires on 11 March 2027. It is not an RFC, a mandatory NFSv4.2 feature, a deployment census or a product-conformance certificate.

Its achievement is narrower and useful: it gives clients and servers vocabulary for preserving an ACL's native semantics. The operational mistake would be to promote that vocabulary into an access verdict.

Four attributes expose the control surface

The proposal adds two read-only attributes and two read/write attributes. acl_trueform identifies whether the stored model used to decide access is NFSv4, POSIX Draft or none. acl_trueform_scope says whether that choice applies to one file object, an entire file system or the server. posix_default_acl carries the directory inheritance policy. posix_access_acl carries the rules governing access to the object itself.

Support is coupled. A server implementing either true-form attribute must implement both for every object. A file system implementing either POSIX ACL attribute must implement both POSIX attributes, both true-form attributes, and the relevant mode and mode_umask behavior. That coupling prevents a producer from advertising a writable POSIX array without also exposing the model and scope needed to interpret it.

But “supported” still has several layers. The server may know the attribute numbers yet not offer them for this file system. A client may negotiate NFSv4.2 but not understand the extension. The true form may be uniform for a server, uniform for one file system, or mutable per object. A capability probe therefore needs the precise server, export, filehandle, minor-version session, supported-attribute bitmap and observation time.

The true form is not just a format label

The draft defines true form as the ACL model stored on the object and used to determine file access. This is an unusually helpful name because it places authority at the enforcement boundary rather than at the user interface.

At server or file-system scope, a client normally checks the true form once for that scope. At file-object scope, the answer can differ across neighboring files and can change after an ACL write. A directory and a child may therefore display similar-looking permissions while being governed by different models.

An extension-unaware client is not malicious when it changes the model. It may simply set the standard NFSv4 acl or dacl attribute. The draft calls that switch unavoidable unless the client knows to check acl_trueform first. Compatibility is preserved, but semantic continuity is not automatic.

That distinction matters for fleets. “All mounts use NFSv4.2” says nothing about whether every client understands true form. “The export uses POSIX ACLs” may be false at object scope five minutes after a legacy management tool touches one file. The model receipt must therefore be attached to the object and epoch involved in the access question.

A POSIX ACL has its own arithmetic

A minimal POSIX Draft ACL has entries for owner, owning group and other. An extended ACL adds named users or groups and one Mask entry. The Mask is not decorative metadata: for the owning group and named group entries, a permission is effective only if the same bit is present in both the entry and the Mask.

This produces a familiar audit trap. A named group entry may visibly contain write permission while the Mask removes it. Reading one ACE without the Mask exaggerates authority. Reading only the low mode bits can also mislead because, for an extended ACL, the group mode bits reflect the Mask rather than the owning-group entry.

Order does not give POSIX ACLs their meaning. Identity class, matching user or group, mode coupling and the Mask do. An access reconstruction therefore needs the authenticated principal, the server's name-to-ID mapping, effective supplementary groups, object ownership, all relevant ACEs, the Mask and the operation requested.

The wire representation can preserve each field perfectly and still leave the decision unknown because the principal or group set is missing.

Default is not current access

POSIX Draft ACLs distinguish the access ACL from the default ACL. The access ACL governs the object. A default ACL exists only on a directory and supplies inheritance for children created later. It does not decide whether someone may access the directory that stores it.

For a new child, inherited permissions are intersected with the low nine mode bits supplied at creation. That is why mode_umask is a required companion for this extension. On OPEN or CREATE, inheritance happens after the mode information is supplied and before any explicitly supplied POSIX ACL attributes are applied.

This ordering prevents a common category error: treating a directory's default ACL as a standing grant. It is an input to the construction of a future child's ACL. The child can end up with narrower permissions because of the creation mode, an explicit access ACL, a later Mask change or a subsequent model switch.

An audit therefore needs the parent default ACL at the creation epoch, the requested mode and umask, the operation order and the child's final atomic readback. Looking at the parent today cannot reconstruct yesterday's child reliably.

Atomicity protects one picture, not every future decision

Mode and POSIX ACL state can modify one another. Within one SETATTR, the low mode bits must be applied before the POSIX ACL. A request that mixes NFSv4 acl or dacl with POSIX access or default ACLs must be rejected with NFS4ERR_INVAL; there is no coherent rule for applying both models in one bitmap.

For reads, the draft says servers should acquire ACL-related values atomically with respect to concurrent SETATTR. That keeps one GETATTR or READDIR response from combining the mode from one instant with the true form or ACL from another.

This is an observation guarantee, not a permanent lock. The instant after the readback, another client can change the object. An atomic snapshot also does not prove that a prior write was authorized by the right administrator, that name mapping is consistent across nodes, or that a later OPEN used the same policy epoch.

Use the atomic read as a versioned receipt: filehandle, change attribute where available, true form, scope, mode, access ACL, default ACL and audit ACL status at one time. Do not call it a continuing access guarantee.

Empty can mean deletion, absence or another model

At file-object scope, a zero-length posix_access_acl written to a POSIX true-form object deletes the POSIX ACLs and reverts the object to ACL_MODEL_NONE. If the server cannot perform that operation, it must return NFS4ERR_INVAL.

On read, zero-length POSIX arrays are also required when POSIX Draft is not the object's true form. Those two cases look similar if the consumer omits acl_trueform: one object may have no ACL and be controlled by mode bits; another may carry an NFSv4 ACL that the POSIX attributes correctly decline to represent.

An empty array is therefore not a complete security statement. It needs the true-form value, scope and mode. Normalizing all empty results to “no restrictions” would turn a representation boundary into an authorization vulnerability.

Audit state lives beside access state

The extension treats NFSv4 AUDIT/ALARM ACEs as separate from ALLOW/DENY rules. Deleting a dacl or switching true form does not imply deleting audit state. A client that intends to modify only AUDIT/ALARM entries must use sacl; using the combined acl attribute can change true form.

This separation is operationally healthy, but it creates another receipt boundary. “The access model changed” and “the audit policy changed” are different claims. A migration can preserve alarms while replacing permissions, or preserve permissions while an audit configuration remains stale.

Security review should read both surfaces and never infer one from the other.

Experimental commands are feasibility evidence

The draft records experimental FreeBSD and Linux work. The FreeBSD report covers a UFS file system configured for POSIX true form and does not explore per-object scope. A Linux patch supplies internal operations that let getfacl and setfacl work against supporting servers. The reported tests include ACLs with many entries.

The draft is explicit: these contributor-supplied listings are not IETF endorsement, were not independently verified and are not a catalogue of available products or features. “The commands appeared to work” is useful running-code evidence for feasibility. It is not proof of release inclusion, default enablement, every model transition, every identity-mapping case or the correctness of real access decisions.

Running code should outrank ceremony only when its scope remains attached. A test receipt names versions, configuration, file system, true-form scope, test vectors, expected decisions and observed operations.

Eight receipts for one access claim

A defensible access-control change can be recorded as eight linked receipts:

  1. Capability receipt: the exact client, server, session and file system support the optional attributes.
  2. Model receipt: acl_trueform and acl_trueform_scope for the target object and epoch.
  3. Write receipt: the server accepted the intended ordered update and rejected no part of it.
  4. Readback receipt: one atomic view contains the expected model, mode, access ACL, default ACL and audit state.
  5. Identity receipt: the authenticated principal and resolved effective groups are known.
  6. Evaluation receipt: entry selection, Mask intersection, mode and inheritance produce a stated permission for a stated operation.
  7. Operation receipt: the actual OPEN, READ, WRITE or execution-equivalent request was allowed or denied under that epoch.
  8. Outcome receipt: the expected file mutation, durability and application-visible result occurred.

The new attributes make receipts two through four much stronger. Their value increases when they are not asked to impersonate receipts five through eight.

Sources