Files
hq/04-ISSUES/035-reconciling-a-seed-file-wipes-what-grew-in-it/00-report.md
T
jschoubben 61f61b5d06 Reconcile the open issues against main
An audit of the six code repositories found eleven open issues fixed on main
with commits and beds to show (025, 027, 033, 036, 037, 040, 045, 047, 050,
052, 053), three partly (007, 026, 035), nine not (020, 031, 041, 046, 049,
054, 064, 065, 066) and one whose fix would live outside those repos (006).
Resolved ones name their evidence; partly ones say what remains; 041 records
that the exposure has widened since it was reported.
2026-09-21 01:52:53 +02:00

49 lines
2.6 KiB
Markdown

---
status: open
opened: 2026-09-02
located-in: []
fixed-by: partly — mesh-host 24e9ae4 (a run-once step writes a seed only if absent, ADR 0052); mesh-catalog ec1e718 (mosquitto). A file resource itself has no create-once semantic, and no bed asserts a seed's grown content survives a re-apply
amended-design:
---
# 035 — Reconciling a seed file wipes what grew in it
## The symptom, as observed
Found by review of the catalogue examples (2026-09-02), not by an outage — the outage is the
part the design permits to be silent.
The cache module declares its access-control file as an ordinary file resource with fixed,
empty content. The program that consumes the file requires it to exist at startup, which is
why the manifest declares it at all. But the same file is the one the provisioner writes
consumer users into, and the one the running program persists ACL changes back to.
A declaration is complete for what the host owns, and the host reconciles what is declared
([ADR 0010](../../02-DECISIONS/0010-delivery.md)).
So every apply that revisits this resource restores the declared content — empty — behind the
running program. Every consumer credential granted since the last apply is removed, the apply
reports success, and nothing anywhere says a grant vanished.
## Why it matters beyond the instance
The manifest needed *the file to exist before first start*, and the only vocabulary available
was *the file has this content, forever*. Those are different intentions, and the gap between
them is generic: any resource that a module seeds and something else then legitimately mutates
— an ACL file, a bootstrap configuration a program rewrites, an htpasswd a provisioner appends
to — has the same two owners and the same silent loss on reconcile.
It is also the mirror image of the boundary ADR 0010 draws so carefully on the *removal* side:
the host never removes what it did not create, but it happily overwrites what it *did* create,
even when what grew inside since is somebody else's work the mesh asked for.
## Open questions
- Is the missing thing a create-once file semantic ("present with this content if absent,
untouched otherwise"), or is the real fault that two owners share one file — and the
provisioner, not the declaration, should own it entirely, with first-start ordering solved
some other way?
- ADR 0010 treats every added resource type as a security artefact. Does a create-once
semantic widen what a compromised control plane can express, or narrow it?
- Are there other seeded-then-mutated files already in the catalogue that this failure is
waiting inside?