Function scheduler_owns_guest_pid_namespace 

pub fn scheduler_owns_guest_pid_namespace() -> bool

Whether this process, which runs the scheduler of the in-guest run it launches, owns the guests’ PID namespace (A5 step 3c.1, D51 and D52): it is PID 1 of its PID namespace, and every guest it launches descends from it, so is a member of that namespace. When a PID namespace’s init exits, the kernel sends SIGKILL to every task with a PID in the namespace and waits for them (zap_pid_ns_processes, kernel/pid_namespace.c v6.12 lines 170-222). That covers a guest in a nested PID namespace too: a task has a PID in its own namespace and in every ancestor (alloc_pid, kernel/pid.c v6.12 lines 194-253), and setns enters only the caller’s namespace or a descendant of it (pidns_install, kernel/pid_namespace.c lines 390-397), so no guest leaves the namespace. So a refusal that exits the scheduler (GlobalRequest::StoppingRefusal) then leaves no guest process running; the in-guest delivery gate requires that (in_guest_signal_delivery_gate).

A fact read from the process, never a setting a caller supplies, so the run-wide-exit claim cannot be forged: hermit run’s container launch, which runs the scheduler as the init of the namespace it creates, owns it, and hermit run --no-namespace does not (its scheduler is a plain child). A library caller owns it exactly when it really is that init.