docs: move privsep socket-activation + child-state rw rationale out of code comments
This commit is contained in:
parent
58b5434466
commit
fb1f7efbe4
4 changed files with 40 additions and 23 deletions
|
|
@ -59,3 +59,19 @@ The `area:ops` issues followed this sequencing:
|
|||
runs as the unprivileged `hive-core` user and delegates root
|
||||
operations to `hive-priv`, a narrow socket-activated helper. See
|
||||
[`docs/security.md`](security.md) for the privilege boundary table.
|
||||
|
||||
### hive-priv socket activation
|
||||
|
||||
`hive-priv` is **always** socket-activated by the `hive-priv.socket`
|
||||
systemd unit. The unit binds `/run/hive/priv.sock` with
|
||||
`SocketGroup=hive-core` and mode `0660` and passes the ready listener
|
||||
to the helper as fd 3 (`LISTEN_FDS`). The helper requires this and
|
||||
bails if it isn't socket-activated — there is intentionally no
|
||||
self-bind fallback.
|
||||
|
||||
Dropping the old fallback removed a dev/prod divergence: when
|
||||
`hive-priv` bound the socket itself it created the file owned by
|
||||
root's primary group rather than `hive-core`, so a `hive-core` client
|
||||
couldn't connect the way the socket unit's `SocketGroup` grant
|
||||
intends. Requiring socket activation everywhere means dev and prod
|
||||
take the exact same path and the group grant always holds.
|
||||
|
|
|
|||
Loading…
Reference in a new issue