We are evaluating a macOS design before implementation. This is a platform-support question, not a report of an observed runtime failure. No actual controller executable, helper executable or deployment configuration has been selected or qualified.
Our objective is to let a small, fixed-purpose helper examine an already-open object’s identity and access control list (ACL) metadata while preserving the original object reference and ownership.
Proposed configuration
- A trusted controller would launch one native C helper using an explicit executable target and
posix_spawn. - The controller would need to qualify for the documented nonsandboxed-parent case, without a conflicting inherited sandbox. We do not assume that an absent entitlement alone establishes this.
- The helper would be the main executable of its own signed application bundle, using its own ordinary App Sandbox rather than inheriting the controller’s sandbox.
- Its proposed additional filesystem permission would be
com.apple.security.temporary-exception.files.absolute-path.read-only, containing exactly two fixed directory entries beneath a user’s development workspace, outside the helper’s container. The literal private paths are omitted. - The controller would already own a read-only file descriptor for one regular file or directory within those trees. It would retain its original reference and pass a known duplicate referring to the same open object to the helper.
- The helper would perform one metadata observation. The proposed operations are
fstatfor object identity andfgetattrlistrequestingATTR_CMN_RETURNED_ATTRSandATTR_CMN_EXTENDED_SECURITY, withFSOPT_REPORT_FULLSIZEand withoutFSOPT_PACK_INVAL_ATTRS.
Required boundaries
The helper must use only the inherited descriptor for the subject observation. The design does not permit:
- Reopening or resolving the subject through a pathname, bookmark or URL.
- Substituting a copied file or another object reference.
- Reading file contents, enumerating directories, changing permissions, or modifying shared descriptor flags or file offsets.
- Expanding the exception to an ancestor, home directory or broader workspace.
- Disabling an existing sandbox or using private interfaces to bypass restrictions.
Parent-side traversal and identity checks remain separate responsibilities. Strict ancestor directories are not additional helper ACL subjects.
We understand that a read-only directory exception and ordinary sandbox/container capabilities may permit more than the helper’s intended metadata operations. Metadata-only behaviour would be a reviewed-code obligation; we are not asking App Sandbox to enforce an exact metadata-only operation filter.
Questions
-
Supported launch and activation: Under what documented parent-context, signing, bundle, container and launch conditions can this helper establish its own ordinary App Sandbox? What supported mechanism or guarantee establishes that the sandbox is effective before the subject metadata operation?
-
Required metadata permissions: Does the proposed read-only exception support
fstatand the specified extended-securityfgetattrlistrequest through an inherited read-only descriptor, for both regular files and directories? Please distinguish descriptor survival from permission to perform these operations, including any additional access-control conditions. -
Scope, identity and lifetime: What documented behaviour applies to descendant coverage, aliases, hard links, renames or namespace changes after the descriptor was opened? Please distinguish the lifetime of the inherited object reference from the lifetime of the static directory permission. Our design would refuse uncertainty rather than reopen, rebind or widen access.
-
Evidence and support boundary: Which public documentation, interfaces or authoritative guarantees support this exact composition, and which parts require separate empirical qualification? Please identify applicable macOS versions and restrictions. Distinguish platform support from any distribution or App Store review requirements.
If these requirements cannot be combined through supported interfaces, please identify the incompatible requirement. An approach requiring broader access, pathname reopening, a replacement object or a different handoff architecture would be a design change requiring separate review, not a solution within the stated constraints.
Permission failures, unsupported requests and incomplete metadata would remain unavailable results. They would not be interpreted as proof that an ACL is absent. Complete ACL-absence interpretation and native resource bounds remain separate qualification questions.
Apple material already reviewed