vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix(3044): a parent's mount of a child's config is read-only

Browse source 
The parent's copy is for reading a child's config; a change to it is a PR
on the child's repo, made from a clone and merged after review. A
writable mount is a second path to the same file that skips that review,
which makes the boundary a convention rather than a permission.

Confirmed with ruth before flipping: it clones from the forge and opens a
PR, including for a brand-new child's first config.

The prose was the larger half. docs/approvals.md did not merely describe
the old mount, it *instructed* agents to use it ("can therefore edit,
commit, and submit changes for any of its direct children directly inside
its container"), and the doc comment in host_config.rs asserted a
dependency that never existed: the InitConfig seed runs as hive-c0re
against the host path, and read_only on a bind constrains writers inside
the container only. That comment is what produced issue #3206, now closed
as invalid.
This commit is contained in:
atlas 2026-08-12 20:03:43 +02:00 • committed by mara
commit 0b6b3b755d
3 changed files with 59 additions and 39 deletions
Download patch file Download diff file Expand all files Collapse all files

19
docs/approvals.md
View file

@ -362,7 +362,7 @@ per container row.
## Two repos per agent
```
/var/lib/hyperhive/agents/<name>/config/ proposed — submitting agent RW
/var/lib/hyperhive/agents/<name>/config/ proposed — parent mount is RO
└── <anything> # any files the submitting
# agent wants in the commit.
# agent.nix is the
@ -490,12 +490,17 @@ approval card. See `docs/web-ui.md`.
### Submitting agent's view of config repos
Every parent agent's container has its **direct children's** proposed
config repos bind-mounted read-write (topology-driven: `lifecycle.rs`
calls `bind_child_agent_dirs` for each entry in
`topology::children_of(agent_name)`). An agent with the `approvals`
tool group can therefore edit, commit, and submit changes for any of
its direct children directly inside its container at `/agents/<child>/config/`.
Every parent agent's container has its **direct children's** config
repos bind-mounted **read-only** (topology-driven: `lifecycle.rs` calls
`bind_child_agent_dirs` for each entry in
`topology::children_of(agent_name)`). It is a copy to *read* a child's
current config — not an editing surface.
An agent with the `approvals` tool group submits a change the same way
any other change is made: **clone the child's config repo from the
forge into its own state dir, commit on a branch, open a PR**, and let
the operator review and approve it. There is deliberately no second,
mount-shaped path that reaches the same file without the review.
Agents holding the `can_manage_top_level_agents` topology role
(defined as `ROLE_CAN_MANAGE_TOP_LEVEL_AGENTS` in `hive-c0re/src/agent_config/topology.rs`)

29
docs/persistence.md
View file

@ -314,12 +314,12 @@ Under `/var/lib/hyperhive/agents/<name>/`:
### Parent access to child state
A parent agent gets each direct child's `state` and `config` dirs
bind-mounted **read-write** (`bind_child_agent_dirs` in
`lifecycle/host_config.rs`). The RW on `state` is deliberate, not an
oversight: a parent manages its children, which includes writing into a
child's state for recovery (e.g. seeding notes, clearing a stuck
sentinel) as well as reading it.
A parent agent gets each direct child's `state` dir bind-mounted
**read-write** and its `config` dir **read-only**
(`bind_child_agent_dirs` in `lifecycle/host_config.rs`). The RW on
`state` is deliberate, not an oversight: a parent manages its children,
which includes writing into a child's state for recovery (e.g. seeding
notes, clearing a stuck sentinel) as well as reading it.
**`harness` is not mounted at all.** It holds the child's own runtime
material — `bash-tasks/`, the turn-stats and event sqlite dbs — and
@ -329,11 +329,18 @@ never an argument so much as the side-effect of one loop treating all
three dirs alike. hive-c0re reads a child's harness dir **directly on the
host** when it wants those stats, which needs no mount into the parent.
`config` is still RW, and **nothing justifies that**: a config change is
a PR on the child's config repo, made from a clone, so the bind-mounted
`config` dir is a read-only *copy* for reading a child's config — not a
tree anyone edits in place. Narrowing it is tracked separately, and
depends on relocating where `InitConfig` seeds.
**`config` is read-only, including for the parent.** A config change is
a PR on the child's config repo, made from a clone and merged after
review — so the bind-mounted `config` dir is a *copy to read*, never a
tree anyone edits in place. Mounting it writable would leave a second
path to the same file that skips the review entirely, which makes the
boundary a convention rather than a permission.
⚠️ Not to be confused with the seeding done when an `InitConfig`
approval resolves: that writes the child's initial config repo as
**hive-c0re, against the host path**, and `read_only` on a bind
constrains writers *inside* a container only. The two are unrelated, and
reading them as the same thing is what kept this mount writable.
Per-child isolation still holds: a container only ever has its *own*
dirs plus its direct children's bind-mounted, never a sibling's.