Confine package ownership changes to private mounts

This commit is contained in:
ms2k 2026-07-27 03:31:58 +09:00
commit 8334fd379f

View file

@ -832,6 +832,16 @@ The State Anchor preserves developer tooling and selected sandbox system paths f
one Domain. It combines a Lazaret-owned prepared lower from the selected base
image with a Domain-scoped writable upper directory.
The Agent Sandbox process receives `CAP_CHOWN`, `CAP_DAC_OVERRIDE`,
`CAP_FOWNER`, `CAP_SETGID`, and `CAP_SETUID` inside runsc while retaining
`noNewPrivileges`. Runsc permits ownership changes only on the root filesystem
and configured State Anchor persistent destinations. Every other bind mount,
including the Agent Workspace, control mounts, and developer-configured
volumes, uses LisaFS with directfs disabled and rejects UID or GID changes
before applying any requested attributes. State Anchor uses fuse-overlayfs
virtual ownership metadata so package-created identities persist without
changing the rootless host ownership of its backing files.
#### Prepared lower
Preparation resolves the selected base image, applies layers with a supported
@ -1140,6 +1150,7 @@ not duplicated here.
| **SR-13** | Git-ignored Agent Workspace paths shall use Ignored Workspace State by default, preventing the sandbox from reading or modifying corresponding host content; only trusted host configuration may disable this behavior. |
| **SR-14** | State Anchor maintenance shall remain confined to the resolved Domain Root. Destructive maintenance shall require exclusive lifecycle ownership and an inactive, unmounted target. |
| **SR-15** | Lazaret shall not use a live container-engine image mount as the State Anchor lower; the lower shall be a Lazaret-owned prepared lower. Archive export alone shall not be treated as a complete preparation boundary. |
| **SR-16** | Ownership-changing Agent Sandbox capabilities shall affect only the root filesystem and configured State Anchor persistent destinations. Host-backed bind mounts shall reject UID and GID changes before applying any requested attributes. |
### 4.2 Functional Requirements