Reported environment: macOS Monterey 12.7.6 (build 21H1320), Intel, APFS. The filesystem type of the relevant volume and exact installed implementation have not been independently reverified. I need a supported, read-only way to distinguish an absent filesystem ACL, an explicit zero-entry ACL, and unavailable/unsupported/invalid/incomplete ACL evidence while retaining an open descriptor to the object. One retained observation: an existing empty regular file was opened read-only with O_NOFOLLOW and O_CLOEXEC. Path and descriptor metadata matched the expected identity, owner, mode and link count before and after the call. Exactly one acl_get_fd_np(fd, ACL_TYPE_EXTENDED) call returned NULL. Errno was cleared immediately before the call and immediately captured afterward as ENOENT. Descriptor closure succeeded. This observation does not establish ACL absence or identify the internal error path. File creation and private mode are not treated as proof of no ACL. I have not tested fgetattrlist on this host, created ACL fixtures for this inquiry, or established volume ACL capability results. Apple's published Libc-1507.100.9 source shows the fstatx_np/filesec property path, and xnu-8020.140.41 shows mode-dependent extended-security attribute packing. I am treating those as version-specific implementation evidence, not as confirmation of the installed implementation or a complete supported API contract. For this reported configuration: Which supported descriptor-bound API sequence and checked preconditions distinguish these three states? A contract applicable to Monterey and the relevant filesystem is sufficient; I am not asking for a guarantee across every macOS version or filesystem. Does NULL/ENOENT from acl_get_fd_np have a supported ACL-absence meaning under specified conditions? Can an explicit zero-entry ACL produce the same result, and how should it be distinguished? With fgetattrlist requesting ATTR_CMN_RETURNED_ATTRS and ATTR_CMN_EXTENDED_SECURITY, can an omitted security returned bit ever establish absence rather than unavailable evidence? Do legacy packing or a valid filesystem capability result supply a supported distinction? Please specify the applicable conditions. Does successful fstatx_np followed by filesec_query_property for FILESEC_ACL reporting an unset property distinguish absence from an unavailable observation? When a complete, valid security record is returned, what is the supported interpretation of KAUTH_FILESEC_NOACL versus an explicit entry count of zero? Is this representation intended for application-level absence verification? Please identify applicable documentation or supported technical guidance, including failure/unknown handling. Genuine retrieval errors must remain errors, and ambiguous or incomplete evidence must remain unknown. I do not want to infer success from an error, omitted attribute, invalid default or empty display, or modify an object's permissions/ACL to establish its prior state. References consulted: Apple's ACL getter manual Apple Libc-1507.100.9 ACL getter source Apple xnu-8020.140.41 attribute manual

Hi Quinn, Following your recommendation by email, I’m posting this as a new thread. Thank you again for your guidance on Virtualization.framework. This is a separate question about ordinary host-side subprocess ownership and timeout recovery, not VM cleanup. Target environment: Intel x86_64 macOS Monterey 12.7.6, build 21H1320 Python 3.13.15 Public, supported mechanisms; no root privileges, private APIs or kernel extensions We are verifying a subprocess supervision component with this process structure: Trusted caller process → runner → pytest → private helper → native subprocess Each parent normally owns the consuming wait for its direct child. The private helper exclusively manages signalling and reaping of its native child. Outer processes do not signal saved helper/native PIDs. Cancellation is cooperative, through channels and file/token delivery. The runner observes its fresh pytest child, drains stdout/stderr with bounded retention, and consumes its exact child’s status after exit is observed. The runner, pytest and helper are launched in separate sessions. Consequently, signalling pytest’s process group would not cover the separately sessioned helper and its native child. The unresolved failure case is: A fresh pytest invocation starts. Cancellation delivery fails, or delivery succeeds but the work does not finish. The runner continues observation and bounded output draining within the remaining deadline. The deadline expires while pytest or processes below it may still be alive. The runner reports an unresolved outcome and may exit. The caller also has a bounded deadline and may return without consuming its runner child. Closing capture pipes can cause EPIPE and disturb the child’s cleanup. Exiting a consuming parent also relinquishes its ability to collect that child’s eventual status. The outer caller does not automatically acquire wait rights over pytest or its descendants. Our current policy retains affected files, preserves the original failure, and prevents subsequent tests from starting. We do not treat cancellation delivery, pipe EOF, successful signal delivery, or direct-child reap as proof that every descendant has stopped. This prevents false success, but does not resolve responsibility for work that remains alive. We have considered separating the caller’s response lifetime from the consuming owners’ lifetimes: the caller could return an unresolved response while both existing parents remain alive, draining output and collecting their direct children later. However, keeping them alive adds no termination authority and does not address a crash of either owner. I am not asking for an absolute guarantee against arbitrary kernel failures, or a promise that SIGKILL always completes within a fixed time. I would like to understand the supported architectural approach on Monterey. My questions are: Is retaining the existing consuming parents beyond the response deadline the appropriate pattern, or is there a supported macOS facility that provides a better ownership and recovery boundary? What safe termination authority should those owners retain over their fresh direct children? If process groups are part of the solution, what lifecycle rules are needed to avoid acting on a reused identifier, particularly after leader exit or reaping? Is there a supported way to manage the separately sessioned helper/native work if an intermediate parent exits? Or must each level independently retain its own supervision and cleanup responsibility? If the consuming owner itself crashes, is there a supported recovery mechanism for ordinary subprocesses? Would launchd or XPC materially help, and what limitations would remain for descendants in separate sessions? Which design constraint would you recommend changing: cooperative-only cancellation, the fixed lifetime of the runner, or the process topology? These are our current choices, not restrictions we assume macOS imposes. Our practical goal is a bounded response while an identifiable owner remains responsible for unsettled work, with appropriate termination authority and an honest unresolved outcome when cleanup cannot be established. The immediate qualification scope is only three simple tests, using shell bodies such as exit, kill -9 $$, and echo with ordinary exit statuses. They contain no intentional background work, pipelines or command substitutions. We would prefer a proportionate supported pattern rather than a new general supervision framework. If a reduced example would help clarify the question, I can provide one. Thank you for your time and guidance.

Subject: Virtualization.framework VM execution ownership and crash reclamation on Intel macOS Monterey Hello, I’m investigating the lifecycle guarantees of Virtualization.framework on Intel macOS Monterey 12.7.x. The specific scenario is a VZVirtualMachine running a Linux guest. I need to understand the ownership and reclamation behavior when the process holding the VZVirtualMachine is abruptly terminated without calling stop() or performing normal cleanup. The key questions are: For a specific VZVirtualMachine on Intel macOS Monterey, which userspace task/process actually owns the Hypervisor VM and the vCPU threads backing guest execution? Is Hypervisor execution owned directly by the calling process, or by a separate process such as: com.apple.Virtualization.VirtualMachine or another Virtualization.framework backend? If the process holding the VZVirtualMachine is terminated with SIGKILL or crashes without executing cleanup code, is the underlying guest execution context necessarily destroyed? More specifically: Can guest vCPU execution continue after the client process has died? If a separate backend process owns the VM, is that backend guaranteed to terminate or destroy the VM when the client dies? Does this behavior apply to Intel macOS Monterey 12.7.x, or only to newer macOS releases? Is there a supported diagnostic on Monterey that can map one specific VZVirtualMachine instance to the task/process that actually owns its Hypervisor VM/vCPU execution? For example, would a diagnostic showing Hypervisor execution frames such as hv_vcpu_run in a process, combined with a reliable process-exit notification, be sufficient to establish that ownership relationship? If the Virtualization backend can survive the client process, what supported VM-specific recovery or termination mechanism is available to another process? The security property I need to establish is intentionally narrow: If the userspace owner of a VM is abruptly destroyed, guest computation must not be able to continue indefinitely as an independent execution domain. Persistent disk files or other inert VM artifacts are not the concern; the question is specifically about live guest/vCPU execution and its ownership lifecycle. I’m looking for the supported architectural contract or diagnostic approach, not undocumented implementation details. Target environment: macOS Monterey 12.7.x Intel x86_64 Virtualization.framework Hypervisor.framework Hardware virtualization available No private APIs or privileged/kernel extensions Thank you.