Issue 279: a folder cannot be owned by the account a module runs as

2026-10-06 20:57:38 +02:00
parent be0754ec7f
commit 5e2b520307
1 changed files with 63 additions and 0 deletions
@@ -0,0 +1,63 @@
 ---
 status: open
 opened: 2026-10-06
 located-in: []
 fixed-by:
 amended-design:
 ---
 # 279. A folder cannot be owned by the account a module runs as
 ## Symptom
 On 2026-10-06 a catalogue merge gave four media managers — the TV, film, music and book managers —
 a recycle-bin folder each: a declared directory, mounted into the app's container, where the app
 keeps a file it replaces with an upgrade. The directories were declared owned by the image's usual
 user and group, as the modules' configuration directories are.
 On the home server the TV and film managers refused the folder — their own words: *"Folder … is not
 writable by user 'abc'"* — and the run-once step that applies their settings exited non-zero. The
 book manager took it. The music manager, which applies the setting from its own code rather than the
 step, logged the same refusal and carried on.
 The difference is the account each app runs as. A media module runs as an identity its assignment
 sets per node (`puid` and `pgid`, written into an environment file the container reads, per
 [ADR 0112](../../02-DECISIONS/0112-a-module-definition-names-no-node-mesh-or-path.md) and
 [issue 153](../153-an-adopted-machines-data-cannot-be-placed-where-it-is/00-report.md)). On the home
 server three of them run as a second account the operator has long kept for media, and the book
 manager as the image's default. The configuration directory works anyway only because the images
 re-own it at start; a second directory gets no such help.
 The stopgap merged the same evening, by the operator's choice, makes the folder writable by every
 account.
 ## What it cost
 One step failing failed the node's whole report, so every module in the same rollout failed its gate
 on that node — the book manager's too, whose step had succeeded — and the controller raised that the
 book manager's build *"failed its gate … and was NOT put back"*, there being no earlier build of it
 kept to put back.
 ## Why it matters beyond this instance
 The mesh knows one account on a node: the operator's ([ADR 0181](../../02-DECISIONS/0181-the-operator-account-is-a-node-fact-and-a-home-is-a-placement-root.md)),
 which a resource may name as its owner. The account a containerised module *runs as* is a number its
 assignment carries and the mesh does not know: nothing ties it to an account on the machine, and a
 directory's owner cannot follow it — a manifest's owner is literal, and `${setting:…}` is filled in a
 file's content and a contribution, not in a resource's owner. [To-be 29](../../03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md)
 leaves *one account or several per node* open; this is a node that has several, in practice, for
 years.
 So every directory a module's app must write — beyond the one its image re-owns — can be right on one
 machine and refused on another, and the definition cannot say which. The definition was checked, the
 manifest passed, and the failure showed only once applied.
 ## Open questions
 - Is the account a module runs as a node fact the mesh holds (as the operator account is), a property
  of the assignment, or something a module declares and the node provides?
 - Should a directory's owner be able to name it — the way `${machine:account}` names the operator's?
 - What of the media library itself, which those apps write and which is owned by that same second
  account: is it a fact the mesh should know, or an access it only mounts?
 - Separately: should one module's failed step fail every gate in the rollout on that node, and should a
  build with nothing kept to put back be judged as a failed rollback?