Research root-owned UDS bindspaces on Linux #494

Summary

PR #480 makes POSIX runtime directories UID-owned and mode 0o700, but POSIX filesystem metadata cannot distinguish the actor-tree root process from another process running under the same UID.

Research making the root actor the sole creator and lifecycle owner of a per-tree UDS bindspace. On Linux, evaluate a private mount namespace with a private tmpfs or bind mount so spawned subactors inherit the bindspace while same-UID processes outside the namespace cannot see it.

Questions

• Can the root actor create the mount namespace before any import-time UDS bindspace initialization?
• How should the selected bindspace and creator identity propagate through trio, multiprocessing, and forkserver spawn paths?
• Can independently launched discovery clients safely join the namespace, or do they require an explicit shared-bindspace or TCP fallback?
• Which Linux environments permit unprivileged user and mount namespaces, including CI, containers, and hardened distributions?
• How should shutdown, crash recovery, socket reaping, and stale namespace cleanup work?
• What remains protected only by UID ownership for same-namespace processes and non-Linux platforms?

Constraints

• Preserve multi-program registrar discovery instead of silently isolating clients that must communicate.
• Do not require elevated privileges for the default runtime path.
• Keep Darwin and other non-Linux transports functional without mount namespaces.
• Avoid making subactors independently create or replace the actor-tree bindspace.

Deliverable

Document the threat model and choose one of:

• a mount-namespace prototype with spawn, discovery, and teardown tests;
• a portable root-created bindspace protocol using explicit runtime metadata;
• UID ownership as the documented security boundary, with rationale for rejecting process-level isolation.

Related: #473, #480, and #480 (comment)

(this issue was generated in some part by opencode using
gpt-5.6-sol (openai))