2026-09-26 15:11:33 +00:00
1 changed files with 11 additions and 2 deletions
@@ -38,11 +38,20 @@ definitions, for values that could only be true of one installation:
 | A public domain, or a name under one | 49 | 26 |
 | The node's own name | 58 | 19 |
 | A routable IP address | 12 | 1 |
-| An absolute path on the machine | 798 | 70 |
+| A **host** path — where a file sits on the machine | 698 | 70 |
 | An email address | 0 | 0 |
 The path row is [issue 119](../119-a-module-definition-decides-where-its-files-live/00-report.md),
-counted again and grown. The rest is this issue. **Thirty of the seventy-one definitions name this
+counted again — and counted differently, which is the correction worth keeping. **A path inside a
 container is not a fact about the machine.** `/run/secrets/…` and the directory a server keeps its
 data in are the software's own contract, true in any mesh that runs it; only the host side of a mount
 names where it landed. The first sweep matched path-shaped strings and so counted both halves of every
 mount and every in-container location a value mentioned. Counted by role instead — directory and file
 resources, the host side of mounts, accesses, and the targets of binds, grants, receives and secrets —
 it is 698 across 70 definitions. Issue 119's own figure is role-counted already and close to this; it
 additionally counts paths written into environment values, a few of which are container-side.
 The rest of the table is this issue. **Thirty of the seventy-one definitions name this
 installation** in one of the first three ways, and the worst single case is not a domain at all: a
 mail module states the node's own public IPv4 as the address it trusts a real-IP header from, so a
 node that moves, or gains a second address, silently stops attributing mail to the right sender. A