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.

Thank you for taking the time to review my questions and share your technical insights. I sincerely appreciate your detailed explanations and guidance. Your input has been very helpful in clarifying the technical considerations and identifying the appropriate direction for our implementation. Thank you again for your time, expertise, and support. It is greatly appreciated.

Hi Kevin, Thank you for the detailed response and the code example. This is very helpful. Your confirmation that macOS currently has no supported API for creating a hard link directly from an open file descriptor resolves our primary question. We also understand your suggested approach of using ATTR_CMN_FSID, ATTR_CMN_FILEID, and ATTR_FILE_LINKCOUNT to detect whether the resulting hard link references the intended object. However, our security requirement is specifically to prevent an unauthorized filesystem mutation, rather than detect one afterward. In our threat model, another process operating under the same user account may concurrently replace the source pathname. If linkat() creates a hard link to that substituted object, detecting the mismatch afterward would not satisfy our requirement because the unauthorized mutation has already occurred. I would appreciate clarification on two final points: Regarding your suggestion to validate a file privately and then publish it using renameat() with RENAME_EXCL or RENAME_SWAP: Is there a supported mechanism that guarantees the published object is the exact previously validated inode, even when another process under the same user account can concurrently modify the source directory? Our requirement also includes retaining the original directory entry, rather than moving or replacing it. If no such mechanism exists, would it be accurate to conclude that macOS currently provides no supported public API or filesystem mechanism that guarantees race-free, same-object hard-link publication under this specific same-user adversarial threat model? We want to ensure we are not overlooking a supported macOS capability before considering a different execution platform. Thank you again for your guidance.