Research 039: the login shell's execute is the first case, and narrow read tools must come first or approvals become noise
This commit is contained in:
@@ -44,10 +44,26 @@ agent on any node could run a command there as an account that can (ADR 0259 §8
|
||||
ADR 0266, hq pull request 225, not yet merged). Once agents run without root, **the tools are the
|
||||
boundary**, and a tool that can do lasting harm needs a person behind each call.
|
||||
|
||||
## The first case: the login shell's `execute`
|
||||
|
||||
The operator decided on 2026-10-08 that the login shell seat's verb `execute` is the first tool to
|
||||
need approval, on every node, once the mark exists. It runs any command it is given as the node's
|
||||
operator account, and that account has passwordless sudo, so one call is root on that node. Until the
|
||||
mark exists, the verb is removed on the control-node.
|
||||
|
||||
The calls it carried (about 300 across the four nodes, counted on 2026-10-08): about a third ran
|
||||
something with sudo; most of the rest were reads, such as reading or searching a file, listing
|
||||
containers, asking a unit's state, listing sockets, or looking up a user or a name.
|
||||
|
||||
So **narrow read tools must replace the common reads first**, each a tool of the module that owns the
|
||||
area. Otherwise nearly every approval asked is for a read, and the operator learns to approve without
|
||||
reading, which makes the approval worth nothing.
|
||||
|
||||
## Candidates seen on 2026-10-08
|
||||
|
||||
| Tool or verb | Why a person |
|
||||
|---|---|
|
||||
| the login shell's `execute` | decided: see above |
|
||||
| the new zfs module's `zfs_snapshot` | a snapshot of the media library holds its space; on a scratch dataset it does not matter |
|
||||
| `mesh-controller.push` | sends builds to nodes outside a walk |
|
||||
| the bus's upgrade, `mesh-controller.bus upgrade` | already a step a person starts ([ADR 0236](../../02-DECISIONS/0236-a-build-is-judged-on-its-first-machine-and-put-back-by-something-other-than-itself-and-so-it-rolls-out-unattended.md) rule 6); today "a person" is whoever calls it |
|
||||
@@ -82,9 +98,12 @@ boundary**, and a tool that can do lasting harm needs a person behind each call.
|
||||
with a handle the agent calls again?
|
||||
6. **The answer before a verified channel exists.** The desk is `acknowledge` only; is the controller's
|
||||
terminal the place, and how does it prove a person there?
|
||||
7. **Audit.** Is a warranted call a hand-act, and where is a declined or expired one recorded?
|
||||
7. **Per call, or per session or time window.** For a tool called as often as `execute`, does each
|
||||
call need its own approval, or may one approval cover one agent session, or a stated span of time?
|
||||
A wider approval is less noise and more reach for whoever holds it.
|
||||
8. **Audit.** Is a warranted call a hand-act, and where is a declined or expired one recorded?
|
||||
|
||||
## How it will be checked
|
||||
|
||||
Nothing measured yet. The first evidence to gather: how many tools and verbs in the catalogue act on
|
||||
Measured so far: only the login shell's calls, above. The next evidence to gather: how many tools and verbs in the catalogue act on
|
||||
data or on other nodes, and of those, how many are guarded by anything but the caller's restraint.
|
||||
|
||||
Reference in New Issue
Block a user