A grant secret belongs to whoever provisions (hq 225); the sweep skips what it will not address (hq 226); a container publishes only what it declares (hq 227) #263

2026-10-04T10:25:47Z

mesh-admin commented

2026-10-04 10:25:47 +00:00

Three fixes, one build.

225 — a provisioner cannot read its grant secrets. The mesh seals one credential per consumer beside the provider's contributions file and wrote it root-owned. Right while a module's own code ran in a container as root; ADR 0198 moved that code under the node's runtime, as the node's account, and the secret stayed root's. On the control machine two consumers went unprovisioned for three hours.

The same sentence is already in this file a few hundred lines up, for a module's own secrets: "a root-owned 0600 file is one that process cannot read." This is that rule reaching the other kind of secret the mesh writes for a module. givenTo could not reach it — it claims the files a bundle's words name, and the harness composes a grant secret's path from the contributions file, which no word names.

226 — the sweep collected none of the 1681 it found. It met a reference recorded with the store's old address, read "I will not address this" as "the store refuses everything", and stopped. Two changes, deliberately separated:

references from build records are read through Recorded in the records, where the provenance is known. Not in LetGo — it cannot tell docker.io from the mesh's own store, so the guard there stays strict. (An earlier attempt put it in LetGo and the existing "a foreign reference is never asked about" test caught it immediately, which is the test doing its job.)
a reference the sweep will not address is ErrNotOurs: skipped, not marked collected, never a reason to stop. Only the store refusing ends a sweep.

227 — a container publishes only a port its module declares. "80" means publish what the software calls 80, and the mesh fills in the machine's half from the port it assigned — which it can only do for a port the module declared. The photo module declared its web endpoint at 4001, published a bare 80, got no assignment, and asked the machine for the port the reverse proxy holds. Four modules publish 80 quite safely because they declare 80: the difference is the declaration, not the number. A catalogue-wide test now says so, and names all three offenders against the catalogue as it was.

Every test here was run against the unfixed code first and fails there.

make check: two failures, both of which fail on main as well — TestTheResolverIsToldEveryMachineOnTheNetworkAndToldAgainWhenOneLeaves (hq 202 behind hq 203's guard) and TestTheServiceManagerReadsTheSystemdRenderingAsMeant, which reads the host's own shell environment and so depends on whose machine runs it. Neither is from here; the second is worth its own issue.

Goes with mesh-catalog #256 (the three photo modules) and mesh-sdk #22 (the message that called a permanent refusal a race).

Three fixes, one build. **225 — a provisioner cannot read its grant secrets.** The mesh seals one credential per consumer beside the provider's contributions file and wrote it root-owned. Right while a module's own code ran in a container as root; ADR 0198 moved that code under the node's runtime, as the node's account, and the secret stayed root's. On the control machine two consumers went unprovisioned for three hours. The same sentence is already in this file a few hundred lines up, for a module's *own* secrets: *"a root-owned 0600 file is one that process cannot read."* This is that rule reaching the other kind of secret the mesh writes for a module. `givenTo` could not reach it — it claims the files a bundle's *words* name, and the harness composes a grant secret's path from the contributions file, which no word names. **226 — the sweep collected none of the 1681 it found.** It met a reference recorded with the store's old address, read *"I will not address this"* as *"the store refuses everything"*, and stopped. Two changes, deliberately separated: - references from build records are read through `Recorded` **in the records**, where the provenance is known. Not in `LetGo` — it cannot tell `docker.io` from the mesh's own store, so the guard there stays strict. (An earlier attempt put it in `LetGo` and the existing "a foreign reference is never asked about" test caught it immediately, which is the test doing its job.) - a reference the sweep will not address is `ErrNotOurs`: skipped, not marked collected, never a reason to stop. Only the **store** refusing ends a sweep. **227 — a container publishes only a port its module declares.** `"80"` means *publish what the software calls 80*, and the mesh fills in the machine's half from the port it assigned — which it can only do for a port the module declared. The photo module declared its web endpoint at 4001, published a bare 80, got no assignment, and asked the machine for the port the reverse proxy holds. Four modules publish 80 quite safely because they declare 80: the difference is the declaration, not the number. A catalogue-wide test now says so, and names all three offenders against the catalogue as it was. Every test here was run against the unfixed code first and fails there. `make check`: two failures, **both of which fail on main as well** — `TestTheResolverIsToldEveryMachineOnTheNetworkAndToldAgainWhenOneLeaves` (hq 202 behind hq 203's guard) and `TestTheServiceManagerReadsTheSystemdRenderingAsMeant`, which reads the host's own shell environment and so depends on whose machine runs it. Neither is from here; the second is worth its own issue. Goes with mesh-catalog #256 (the three photo modules) and mesh-sdk #22 (the message that called a permanent refusal a race).

mesh-admin added 2 commits 2026-10-04 10:25:47 +00:00

A grant secret belongs to whoever provisions, and the sweep skips what it will not address 41b20b2782

Issue 225. The mesh seals one credential per consumer beside the provider's
contributions file, and wrote it root-owned. That was right while a module's
own code ran in a container as root; ADR 0198 moved that code under the node's
runtime, as the node's account, and the secret stayed root's. On the control
machine two consumers went unprovisioned for three hours and the only sign
was a line reading 'secret not readable yet', 4330 times.

The same sentence is already written for a module's own secrets a few hundred
lines above — 'a root-owned 0600 file is one that process cannot read'. This
is that rule reaching the other kind of secret the mesh writes for a module.

Issue 226. The sweep met a reference recorded with the store's old address,
read 'I will not address this' as 'the store refuses everything', and
collected none of the 1681 it had found. Two changes: references from build
records are read through Recorded, where the provenance is known — not in
LetGo, which cannot tell one registry host from another and must stay strict
— and a reference the sweep will not address is now ErrNotOurs, skipped,
never a reason to stop. Only the store refusing ends a sweep.

make check: the two failures both fail on main as well — the resolver test
(hq 202/203) and the service-manager test, which reads this machine's own
shell environment.

A container publishes only a port its module declares (hq issue 227) 74b0dab34c

The short form is a question the mesh answers: "80" means publish what the
software calls 80, and the mesh fills in the machine's half from the port it
assigned. It can only assign one for a port the module declared, so a number
appearing nowhere in listens gets no assignment and reaches the machine as
written — which is how the photo module asked for port 80 on the node whose
reverse proxy holds it.

Four modules publish 80 quite safely, because they declare 80. The difference
is the declaration, not the number. A catalogue-wide test now says so; it
names all three offenders against the catalogue as it was.

mesh-admin merged commit f421d4588c into main

2026-10-04 10:27:30 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-controller#263