macOS 27/APFS: Supported ACL Absence Verification When acl_get_fd_np Returns ENOENT

App & System Services Core OS
HumaneezyDev OP
Created
Replies 2
Boosts 0
Views 167
Participants 2

Subject: Supported fail-closed ACL absence verification on macOS 27.0.1 / APFS

Environment: macOS 27.0.1, build 26A434; APFS; installed macOS 27.0 SDK.

We need a supported, documented way to determine whether an existing filesystem object has no effective ACL entries, while rejecting genuine retrieval failures and unsupported or unavailable ACL evidence. We are seeking clarification of the public interface contract, not alleging an Apple defect.

For existing directory and regular-file fixtures, pathname metadata and descriptor metadata identify the same object. Errno is cleared immediately before each native call and captured immediately afterward. ACL retrieval uses ACL_TYPE_EXTENDED:

  • acl_get_file(path, ACL_TYPE_EXTENDED)
  • acl_get_fd_np(fd, ACL_TYPE_EXTENDED)

On fresh objects, both return NULL with ENOENT. Explicit one-entry fixture ACLs are retrieved successfully. Explicit zero-entry fixture ACLs can also yield NULL/ENOENT, while attribute queries return a serialized zero-entry ACL.

The attribute queries use getattrlist() and descriptor-bound fgetattrlist(), requesting ATTR_CMN_RETURNED_ATTRS | ATTR_CMN_EXTENDED_SECURITY, with FSOPT_NOFOLLOW | FSOPT_REPORT_FULLSIZE and WITHOUT FSOPT_PACK_INVAL_ATTRS. Buffer lengths, variable-reference bounds and returned-attribute validity are checked. For the existing directories of interest, both calls succeed but omit the ATTR_CMN_EXTENDED_SECURITY returned bit. Explicit populated and zero-entry fixture records do set the bit. APFS reports valid VOL_CAP_INT_EXTENDED_SECURITY support; we do not assume that volume capability proves per-object ACL availability.

On macOS 27.0.1, build 26A434, using APFS, which supported interface and documented conditions allow software to distinguish an absent ACL from unavailable or unsupported ACL evidence when descriptor-bound attribute queries succeed but omit ATTR_CMN_EXTENDED_SECURITY and native ACL getters return ENOENT for an existing object?

Please clarify:

  1. Whether ENOENT has a supported ACL-absence interpretation, and under exactly which checked conditions.
  2. Whether an omitted extended-security attribute can establish ACL absence, rather than unavailable or unsupported evidence.
  3. How explicit zero-entry ACLs differ from absent ACL records through supported interfaces.
  4. How KAUTH_FILESEC_NOACL should be interpreted through supported APIs.
  5. How genuine retrieval failures, including permission, I/O, allocation and unsupported-operation errors, must remain distinguishable.
  6. Whether a supported descriptor-bound verification method exists that preserves fail-closed security checks and object identity binding; please identify its guarantees and limitations regarding pathname/ancestor changes and later operations.
  7. Whether relevant behavior is specific to this macOS/APFS version.

Please identify the applicable public documentation or supported verification sequence. We do not want to modify permissions, synthesize ACLs on target objects, treat invalid-attribute defaults as real evidence, or accept ambiguous omission/ENOENT as success. Existing ownership, mode and confinement checks must remain separate mandatory checks. If no public API can make this distinction reliably, please state that limitation.

Replies  2
Boosts 0
Views  167
Participants  2
Pokpong OP

I would treat NULL plus ENOENT as inconclusive for the security decision here. Apple’s acl_get_file man page documents ENOENT as the named object not existing (or an empty pathname); it does not document ENOENT as a portable signal that an existing object has no ACL: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/acl_get_file.3.html

Likewise, I would not promote an omitted ATTR_CMN_EXTENDED_SECURITY returned bit to proof of absence unless the getattrlist contract for this attribute explicitly guarantees that interpretation. Your descriptor-bound query and fixture results are good evidence to include in a Feedback Assistant report, but I can’t find a public contract that resolves the APFS/macOS 27 case you describe. For a fail-closed check, keep treating both outcomes as “ACL state not established” and avoid using them to authorize the operation until Apple confirms a supported distinction.
HumaneezyDev OP

Thank you, Pokpong, for the thoughtful response and for clarifying the limits of the documented API behavior.

Your interpretation aligns with the fail-closed approach we are taking. We will continue treating both NULL/ENOENT from the ACL getters and omission of ATTR_CMN_EXTENDED_SECURITY as inconclusive, rather than interpreting either as proof of ACL absence.

The key unresolved question is whether Apple provides a supported, descriptor-bound mechanism to distinguish an absent ACL from unavailable ACL evidence for an existing APFS object, particularly when explicit zero-entry ACLs can exhibit similar behavior.

We will preserve the fixture results and descriptor-bound observations for a potential Feedback Assistant submission and seek clarification of the supported API contract rather than relying on undocumented behavior.

For now, the affected security-sensitive operation will remain blocked wherever ACL absence cannot be established reliably.

Thank you again for the guidance and the documentation reference. It is helpful in confirming the appropriate security boundary while the underlying API semantics remain unresolved.