Which primary-source-supported OCI stack, runsc integration, privilege boundary, Unix-socket transport, path model, and installation shape can safely support both a host-installed Paseo daemon and the official Docker deployment without exposing a general container-runtime socket? Identify feasible alternatives, their prerequisites, and constraints that later supervisor and configuration decisions must honor.
Part of #1
## Question
Which primary-source-supported OCI stack, runsc integration, privilege boundary, Unix-socket transport, path model, and installation shape can safely support both a host-installed Paseo daemon and the official Docker deployment without exposing a general container-runtime socket? Identify feasible alternatives, their prerequisites, and constraints that later supervisor and configuration decisions must honor.
Use one root-owned host supervisor that invokes runsc directly against supervisor-generated, validated OCI bundles.
Host-installed Paseo connects through a narrow pathname Unix socket.
The official Docker deployment bind-mounts only that socket and identifies a root-owned deployment mapping; it never supplies raw host paths.
Paseo and agent sandboxes receive no Docker, containerd, supervisor, or runsc-state socket.
Reject rootless runsc for this POC because its documented lifecycle and networking limits do not satisfy the required create/start and isolated-network behavior.
The supervisor owns provider I/O and a bounded sequenced output buffer, allowing a restarted Paseo daemon to reconnect without losing the active process or stream. Supervisor-crash I/O recovery remains a separate unresolved boundary.
Start with direct runsc, default Gofer-backed filesystem access, a loopback-only network profile for lifecycle tests, and a sandbox-network profile for DNS/HTTPS tests.
This clears the topology prerequisite for the supervisor, execution, mount, network, configuration, and verification decisions.
## Resolution
Use one root-owned host supervisor that invokes `runsc` directly against supervisor-generated, validated OCI bundles.
- Host-installed Paseo connects through a narrow pathname Unix socket.
- The official Docker deployment bind-mounts only that socket and identifies a root-owned deployment mapping; it never supplies raw host paths.
- Paseo and agent sandboxes receive no Docker, containerd, supervisor, or runsc-state socket.
- Reject rootless `runsc` for this POC because its documented lifecycle and networking limits do not satisfy the required create/start and isolated-network behavior.
- The supervisor owns provider I/O and a bounded sequenced output buffer, allowing a restarted Paseo daemon to reconnect without losing the active process or stream. Supervisor-crash I/O recovery remains a separate unresolved boundary.
- Start with direct `runsc`, default Gofer-backed filesystem access, a loopback-only network profile for lifecycle tests, and a sandbox-network profile for DNS/HTTPS tests.
Research asset: [gVisor supervisor topology for Linux deployments](https://git.jb.codes/jb/paseo/src/branch/research/gvisor-supervisor-topology/goals/research/gvisor-supervisor-topology.md)
Branch: `research/gvisor-supervisor-topology`
Commit: `2c6089574f25c64c47992f1d37a7420a7aa2abd9`
This clears the topology prerequisite for the supervisor, execution, mount, network, configuration, and verification decisions.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Part of #1
Question
Which primary-source-supported OCI stack, runsc integration, privilege boundary, Unix-socket transport, path model, and installation shape can safely support both a host-installed Paseo daemon and the official Docker deployment without exposing a general container-runtime socket? Identify feasible alternatives, their prerequisites, and constraints that later supervisor and configuration decisions must honor.
Resolution
Use one root-owned host supervisor that invokes
runscdirectly against supervisor-generated, validated OCI bundles.runscfor this POC because its documented lifecycle and networking limits do not satisfy the required create/start and isolated-network behavior.runsc, default Gofer-backed filesystem access, a loopback-only network profile for lifecycle tests, and a sandbox-network profile for DNS/HTTPS tests.Research asset: gVisor supervisor topology for Linux deployments
Branch:
research/gvisor-supervisor-topologyCommit:
2c6089574f25c64c47992f1d37a7420a7aa2abd9This clears the topology prerequisite for the supervisor, execution, mount, network, configuration, and verification decisions.