I am evaluating a hypothetical file collector that uses fixed approved directory roots. Its requirement includes rename-after-open: if another process moves an opened file or an ancestor outside the approved namespace, the collector must not continue accessing it there. This concerns input reads, directory enumeration, preview reacquisition, and writes to exclusively created output files. Retaining a previously approved descriptor or detecting a move after access does not meet the requirement. I am considering whether Endpoint Security can prevent the relevant namespace mutations before they occur for the complete access interval. No Endpoint Security client has been created or exercised for this candidate. This is a request for a documented, versioned contract, not permission to deploy a client, obtain an entitlement, or change the system. The deadline-mode documentation describes the response to an unanswered authorization within its deadline. The mode values describe deny without killing the client, allow without killing the client, and killing the client as the default. The setter documentation also describes denial of a queue-full AUTH drop under FAIL_CLOSED. I have not found, in the specific pages listed below, an explicit contract for the separate case of client loss. I am not assuming that deadline policy covers disappearance of a client. Could you clarify the following? Pending authorization at client loss For a relevant authorization such as ES_EVENT_TYPE_AUTH_RENAME or ES_EVENT_TYPE_AUTH_UNLINK that is already pending, what exact verdict applies if the matching client crashes, disconnects, is deleted with es_delete_client, or unsubscribes before responding? Please distinguish each case, including when it was the last matching client and when other matching clients remain. Does a configured FAIL_CLOSED deadline policy remain attached to that pending request after client loss? Operations after the last matching client is gone What controls a later rename, reparenting, exchange, unlink, or other relevant namespace mutation after the last matching client has disappeared or unsubscribed? Is there a supported policy that remains effective independently of that client's lifetime? Please distinguish new operations from an authorization that was already pending, including cached decisions and any interval before a replacement client is ready. A supported complete protection interval Is there a supported way, through Endpoint Security or another supported kernel-enforced mechanism, to keep the necessary namespace mutations denied from before the collector's first access until its final read/write ends, despite authorization-client loss, partial setup, or owner death? The mutating actor may be outside the collector's process subtree. A later watchdog termination, restart, or notification of a completed operation would not establish denial during the intervening interval. If protection must end before that interval is complete, please identify the exact limitation. Client types and failure cases Which guarantees differ between es_new_client and es_new_descendants_client? Beyond the unanswered-deadline and full-queue cases, does any deadline mode affect the cases in questions 1 and 2? Please identify any self-process, muting, caching, scope, or actor limitations that prevent the proposed all-relevant-mutator coverage. I am not assuming a descendant-scoped client can authorize operations by unrelated processes. Versioned support and prerequisites For any supported contract, please cite the public documentation or other authoritative reference, applicable released macOS versions, exact API and deployment configuration, and required entitlements, privilege, consent, or system-extension conditions. API introduction metadata alone is not being treated as evidence about an installed target, and an upgrade or privilege change is not assumed. If no public supported mechanism provides the requested interval, an explicit statement of the missing guarantee or required independent enforcement boundary would be useful. Public references reviewed https://developer.apple.com/documentation/endpointsecurity/es_set_deadline_miss_mode(::) https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_t https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_fail_closed https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_fail_open https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_kill https://developer.apple.com/documentation/endpointsecurity/client https://developer.apple.com/documentation/endpointsecurity/es_client_t https://developer.apple.com/documentation/endpointsecurity/es_new_client(::) https://developer.apple.com/documentation/endpointsecurity/es_new_descendants_client(::) https://developer.apple.com/documentation/endpointsecurity/es_delete_client(:) https://developer.apple.com/documentation/endpointsecurity/es_unsubscribe_all(:) The scoped document reviews did not establish the two client-loss cases above; this is not a claim that every relevant Apple document or mechanism has been exhausted. No real data, credentials, private artifacts, logs, or host identifiers are needed for this clarification.

I am evaluating a local macOS C XPC design. The target under consideration is macOS 27.0.1, build 26A434, on Apple silicon. This is a source-design question; I have not run a reproducer or established that the public source below matches that OS build. The public SecCode.h comment describes SecCodeCreateWithXPCMessage as obtaining a code reference for the sender of the supplied XPC message using associated audit identity. The implementation at Apple Security commit 97c3a4296c1ea06b0fe1877a7e616aa84450b5b2 obtains the dictionary's remote connection, takes that connection's audit token, and uses it for code lookup: https://github.com/apple-oss-distributions/Security/blob/97c3a4296c1ea06b0fe1877a7e616aa84450b5b2/OSX/libsecurity_codesigning/lib/SecCode.h https://github.com/apple-oss-distributions/Security/blob/97c3a4296c1ea06b0fe1877a7e616aa84450b5b2/OSX/libsecurity_codesigning/lib/SecCode.cpp Function anchor in both files: SecCodeCreateWithXPCMessage. I am treating this as a question about the supported API contract, not evidence of a vulnerability or proof of installed implementation. For an actual received C XPC dictionary M, retained for deferred processing, I need to understand the supported identity and reply guarantees: Does SecCodeCreateWithXPCMessage(M, ...) resolve audit identity fixed to M's original sender occurrence, or can the associated connection's identity at lookup time differ? In particular, what is guaranteed if another message arrives or processing occurs concurrently on another queue? If the sending process performs exec before the lookup, or after lookup but before a reply, what does the resulting SecCode reference identify? Is there a documented supported way to distinguish the original message-sending occurrence and executable from a later executable or replacement peer without using PID-based reconstruction or private XPC APIs? If I retain M and later use its supported C reply context, does the reply remain addressed to that same original sending occurrence? What are the documented effects of connection invalidation, exec, forwarding/delegation of relevant rights and outstanding aliases? I am not assuming that retaining M or the returned SecCode reference locks peer identity or revokes other holders. If these APIs do not jointly provide those guarantees, which public API and ownership pattern should a design use to validate the actual eventual reply recipient before sending sensitive data? A statement that a guarantee is unavailable or requires a different design would also help. Please distinguish C XPC behavior from Swift XPCReceivedMessage; I am not assuming an undocumented conversion between them. Could you point to the applicable documentation and supported macOS versions, and clarify whether the cited public source revision is representative of the target? If exact-build behavior cannot be established publicly, please identify that limitation. This question concerns transport identity and context lifetime only. A valid code identity would still need separate application authorization; I am not asking XPC to issue role, run or resource authority. I would prefer a documented contract over an inference from a successful test. I can prepare a separately scoped minimal example if one is necessary, but no executable example is included in this question.

I am designing a macOS Virtualization application using RAW disk images, an EFI variable store and host directory sharing. I need to distinguish stopping guest execution from releasing host backing-file access. I inspected the public declarations for VZDiskImageStorageDeviceAttachment, VZEFIVariableStore, VZSharedDirectory and VZVirtualMachine in the macOS27 SDK. The stop completion describes a stopped VM or an error; the backing types expose URL-based initialization. I could not identify a final backing-release event in those declarations. I would appreciate the supported contract, including any differences on macOS26 and macOS27. For each of the three URL-backed surfaces: When are paths resolved and backing references opened? Can the framework reopen a path or lazily access shared descendants later? Does successful stop completion guarantee backing references are released and required writes persisted, or only that guest execution stopped? What object-reference release and queue/callback ordering is required before the application may safely reuse, replace or remove the backing objects? Can Virtualization helper processes retain backing access after the application's worker process exits? Is there a supported observable event covering those references? If no such release event is documented, what supported architecture should retain or quarantine these resources until release can be established? I am not using physical block devices and am not generalizing their documented file-handle retention to URL-backed images, EFI stores or directory shares. Please link the public contract or clarify which behaviors are unspecified.