fix: compare getppid() against actual parent pid, not hardcoded 1

[mrsimpson]

Summary

Fixes Sandbox.run() failure in containerized server processes (e.g. uvicorn running as PID 1). The child's confine_child checked getppid() == 1 to detect parent death, but in containers the entrypoint process commonly runs as PID 1 itself — causing a false positive and silent child exit with read notif fd from child: pipe closed before 4 bytes read.

Root cause

context.rs line 788: if unsafe { libc::getppid() } == 1 { fail!("parent died before confinement"); }

When the server process is PID 1 (container entrypoint), any forked child legitimately has getppid() == 1. Sandlock interprets this as "parent was reparented to init" and aborts the child.

Fix

Capture the actual parent PID with getpid() before the fork and pass it through ChildSpawnArgs. The child compares against that value instead of hardcoded 1.

Testing

• Verified on k3s pod with Kubernetes RuntimeDefault seccomp, Landlock ABI v7, uvicorn running as PID 1
• Sandbox.run() now succeeds directly from the uvicorn process without any subprocess workaround
• Multiple consecutive tool calls confirmed working

Related

• Follow-up to sandlock_spawn fails with ENOSYS (clone3) when called from a multi-threaded Python process (uvicorn/asyncio + Kubernetes RuntimeDefault seccomp) #47 / PR ffi: fix sandlock_spawn failure under multi-threaded callers with restricted seccomp (#47) #49 (Tokio current_thread runtime fix)
• Both fixes are needed together in containerized environments

[congwang-mk]

Oops, thanks for catching it!