Post

Replies

Boosts

Views

Activity

macos: Supported API to establish filesystem ACL absence?
I'm implementing a security-sensitive filesystem metadata verifier on macOS 27.0.1 (Apple Silicon, MacOSX27.0.sdk). The verifier must distinguish three states: ACL absent: Supported evidence establishes that the file or directory has no filesystem ACL. ACL present: An ACL exists, including an empty ACL. Unknown: The observation is ambiguous, unavailable, unsupported, or incomplete. Only authoritative ACL absence is acceptable. All other states are rejected. I'm investigating fstatx_np() with a filesec_t object, followed by filesec_query_property(security, FILESEC_ACL, &present). My questions are: Does this combination provide a supported API guarantee that a file or directory has no ACL when present is reported as false? Can an unset FILESEC_ACL property be reliably distinguished from an omitted or unavailable ACL observation? If this mechanism cannot establish absence, is there another supported descriptor-based macOS API that can? Is there Apple documentation specifying these semantics, including relevant error and unsupported-operation behavior? I am not treating an empty ACL entry list, an unset property, or a command-line display without ACL entries as proof of absence. I'm seeking the native API contract so the verifier can fail closed whenever ACL absence is not authoritatively established.
0
0
24
4h
macos: Supported API to establish filesystem ACL absence?
I'm implementing a security-sensitive filesystem metadata verifier on macOS 27.0.1 (Apple Silicon, MacOSX27.0.sdk). The verifier must distinguish three states: ACL absent: Supported evidence establishes that the file or directory has no filesystem ACL. ACL present: An ACL exists, including an empty ACL. Unknown: The observation is ambiguous, unavailable, unsupported, or incomplete. Only authoritative ACL absence is acceptable. All other states are rejected. I'm investigating fstatx_np() with a filesec_t object, followed by filesec_query_property(security, FILESEC_ACL, &present). My questions are: Does this combination provide a supported API guarantee that a file or directory has no ACL when present is reported as false? Can an unset FILESEC_ACL property be reliably distinguished from an omitted or unavailable ACL observation? If this mechanism cannot establish absence, is there another supported descriptor-based macOS API that can? Is there Apple documentation specifying these semantics, including relevant error and unsupported-operation behavior? I am not treating an empty ACL entry list, an unset property, or a command-line display without ACL entries as proof of absence. I'm seeking the native API contract so the verifier can fail closed whenever ACL absence is not authoritatively established.
Replies
0
Boosts
0
Views
24
Activity
4h