diff --git a/04-ISSUES/149-an-adopted-machines-data-cannot-be-placed-where-it-is/00-report.md b/04-ISSUES/149-an-adopted-machines-data-cannot-be-placed-where-it-is/00-report.md index c13aa01..d5ed571 100644 --- a/04-ISSUES/149-an-adopted-machines-data-cannot-be-placed-where-it-is/00-report.md +++ b/04-ISSUES/149-an-adopted-machines-data-cannot-be-placed-where-it-is/00-report.md @@ -55,3 +55,17 @@ The two assignment halves 0112 decided: a setting that places a declared directo path on this node, and a setting that says where an access's data is — both validated like `endpoints` (unknown ids refused), and an access placed by the assignment still never created, chowned or removed. + +## Addendum 2026-09-30 — whose the data is, not only where + +The same modules need to run **as the owner of the data they access**: linuxserver images take +`PUID`/`PGID`, and ace's library is `media:media` (`1001:2000`, group members `ace`, `n8n`, `media`). +A manifest default is one value for every machine, and an assignment's settings do not reach a +container's environment. Adding user and group management to the mesh would contradict ADR 0051 — +the mesh owns nothing about the operator's data. + +The data already says whose it is, and the host already looks at it when it confirms an access exists. +Proposed: expose that as a fact the module can ask for, like `${port:…}` — e.g. `${access::uid}` +and `${access::gid}`, read from the accessed path on the machine — so a media module declares +`PUID=${access:media:uid}` and is right on every machine without the mesh creating, naming or +chowning anyone.