macOS 14+: Safely supervising worker-created child processes.

App & System Services Processes & Concurrency
Pugun717 OP
Created
Replies 5
Boosts 0
Views 595
Participants 2

Hello Apple Developer Community,

We are developing a macOS application with a minimum deployment target of macOS 14.0.

We are investigating a process-supervision safety problem involving the following topology: Root → Worker → Child

The Worker creates the Child using native process APIs and is responsible for supervising its lifecycle. The critical failure scenario

  1. Worker successfully creates Child.
  2. Child exists, but its verified process identity has not yet been communicated to Root.
  3. Worker unexpectedly terminates before completing the identity handoff.
  4. Root must avoid signaling an unrelated process while ensuring that an untracked Child cannot continue executing without authorization.

Our safety requirements

  • Independently establish Child's exact process-lifetime identity.
  • Prevent unsafe process signaling caused by PID reuse.
  • Handle Worker failure before identity handoff.
  • Verify process termination and disposition.
  • Avoid relying on private APIs or restricted entitlements.
  • Maintain compatibility with macOS 14 and later.

What we have investigated We have reviewed posix_spawn, waitpid, process observation APIs, audit-token-based process identification and signaling, Endpoint Security, and launchd-based supervision. We understand that Endpoint Security FORK events are notifications rather than authorization events, and that dropped notifications may prevent complete birth tracking. We also found es_new_descendants_client in the macOS 27 SDK, but it requires an Endpoint Security entitlement and does not meet our current macOS 14 deployment requirements. We understand that a process cannot automatically use waitpid to reap a grandchild merely because the intermediate parent has terminated. Our questions

  1. Is there a publicly supported macOS 14+ API or process-supervision mechanism that can reliably establish the identity of a Worker-created Child even if Worker terminates before communicating that identity?
  2. Is there a supported approach for safely containing such a Child when its identity is not yet known to Root?
  3. Can audit-token-based signaling provide sufficient process-lifetime identity guarantees for this scenario, and what minimum macOS version supports the relevant APIs?
  4. Is there a supported mechanism for independently verifying Child termination when Root is not its direct parent?
  5. If this cannot be guaranteed using public APIs, would Apple recommend changing the architecture so that Root directly creates and supervises Child?

We are not requesting private API access or Endpoint Security entitlements. We would appreciate guidance on the supported macOS process-lifecycle contracts before proceeding with implementation. Thank you for your assistance.

Replies  5
Boosts 0
Views  595
Participants  2
DTS Engineer OP
Apple

We understand that Endpoint Security FORK events are notifications rather than authorization events, and that dropped notifications may prevent complete birth tracking.

Dropped notifications are a correctable client level failure, not normal behavior. The solution to these issue is to build your client such that it can process events faster than it's clients can generate them, preventing any issues.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
Pugun717 OP

Thank you for the clarification. We understand that dropped notifications should be addressed by keeping the Endpoint Security client fast enough to handle incoming events. Our remaining concern is the failure window in which a Worker successfully forks a Child but terminates before communicating the Child's identity to its supervising Root process. Even assuming no notifications are dropped: We want to distinguish reliable event processing from guaranteed process containment and ownership. Thank you.

DTS Engineer OP
Apple

Thank you for the clarification. We understand that dropped notifications should be addressed by keeping the Endpoint Security client fast enough to handle incoming events. Our remaining concern is the failure window in which a Worker successfully forks a Child but terminates before communicating the Child's identity to its supervising Root process.

This isn't how ES works. Indvidual processes aren't involved with communicating their actions with your client. Those notification are coming directly from the kernel and nothing the Worker does effects that channel. The assumption you're making here:

terminates before communicating the Child's identity to its supervising Root process

...is that the termination of the Worker has some impact on the handling of events that have already occurred. It doesn't. The events where queued when the syscall occurred and isn't really impacted by later activity. Putting that in more concrete terms, if a process is set up to fork/exec/exit as quickly as possible, what you'll receive is a fork notification corresponding to every fork call. If things move fast enough, it's entirely possible that fork notification will reference a parent process that no longer exists, but that won't change whether or not you get the notification.

Similarly, the fact that a worked managed to exit before a child generates any event activity has no effect on which events your ES client will receive from that child. The relationship between your ES client and the child process was established when the child was originally created (by fork in the kernel) and thats all that matters to the ES system.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
Pugun717 OP

Thank you for the clarification. We now understand that Endpoint Security events originate from the kernel and that Worker termination does not affect the delivery of events already generated.

However, our application targets macOS 14+ and cannot depend on the restricted Endpoint Security entitlement.

Our remaining requirement is to guarantee safe process identity and lifecycle supervision when a Worker creates a Child but terminates before handing its identity to Root, without risking PID reuse or leaving an unsupervised process.

For this requirement, is there a supported public macOS 14+ mechanism that provides these guarantees without Endpoint Security, or should we redesign the architecture so that Root directly creates and supervises Child?

If neither approach provides a complete guarantee, we would appreciate confirmation of that limitation so we can make the appropriate architectural decision.

Thank you for your guidance.

DTS Engineer OP
Apple

For this requirement, is there a supported public macOS 14+ mechanism that provides these guarantees without Endpoint Security, or should we redesign the architecture so that Root directly creates and supervises Child?

Without Endpoint Security, I think this becomes an issue of app architecture, not API design. From that perspective, I think that means either shifting process creation over to "Root" or changing the dynamics of this process:

when a Worker creates a Child but terminates before handing its identity to Root,

What exactly are these child processes? If the child processes are executing code you control, then the other option here is to have the child process "check in" with Root instead of (or as well as) the Worker that created it. Putting that in concrete terms, if every child process ALWAYS does the following when it starts executing:

  1. Connect back to the Root process and send its process info.

  2. Wait Xs for a reply from root.

  3. If it receives a reply, begin work.

  4. If it doesn't receive a reply after Xs, exit().

Your Root process is then responsible for monitoring/managing all its "known" processes. At the point it exits, any unknown process will automatically exit after Xs without ever having done any work.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware