Merge pull request 'Issue 358: a mesh directory outside a home is changed by path, through any link; issue 356 points at it' (#258) from issues/358-a-mesh-directory-outside-a-home-is-changed-by-path into main

2026-10-09 18:08:04 +00:00
parent fbaa8e16e6 e68d0ffa1d
commit 32c0f6efb1
2 changed files with 55 additions and 0 deletions
@@ -77,6 +77,14 @@ refused and say so. Then the engine. The catalogue's check and this record in an

 ## What remains

+- **A handed-over directory goes through no link on every apply, not only the first** (the confirmation review
+  of 2026-10-09). After the first apply the record is no longer used as found, so the directory read as the
+  mesh's own and was given its mode and owner by path. The hand-over is now checked before that, and a test
+  swaps a parent after an apply already gave the directory its owner (`mesh-host` #74).
+- **The same by-path change for every other mesh directory outside a home is a gap older than this issue**, and
+  is left to [issue 358](../358-a-mesh-directory-outside-a-home-is-changed-by-path-through-any-link/00-report.md):
+  closing it here would change every placement on every node.
+
 - A mesh-lab replay of the stale command (an engine delivered twice, the fallback compared) and of the hand-over
  (asked, refused through a verb, recorded through the terminal) is owed before this issue resolves: a core
  issue resolves with `replay:` ([ADR 0237](../../02-DECISIONS/0237-a-change-is-judged-against-the-mesh-that-runs-before-it-merges-on-the-build-seat.md)).
@@ -0,0 +1,47 @@
+---
+status: open
+opened: 2026-10-09
+located-in: [mesh-host (internal/apply/apply.go applyDirectory, internal/apply/home_links.go chmodDirPath, chownPath)]
+fixed-by:
+amended-design:
+---
+
+# 358. A mesh directory outside a home is given its mode and owner by path, through any link in its path
+
+## Symptom
+
+Found by the review of [issue 356](../356-the-operators-command-ran-a-stale-engine-and-a-hand-over-had-no-channel/00-report.md)
+on 2026-10-09, by reading the code; nothing was run against a node.
+
+The node-engine sets a directory's mode and owner by path when the directory is the mesh's own and lies outside
+an account's home: `applyDirectory` calls `chmodDirPath` and `own`, which call `os.Chmod` and `os.Chown` on the
+path. Both follow a link anywhere in the path. The directory applier refuses a link at the directory's own name,
+and issue 339's placement guard refuses the machine's own trees, but nothing refuses a link in a parent at the
+moment of use. Below a home the engine already walks every component without following a link (ADR 0266).
+
+Issue 356 closed this for a directory handed to the mesh by the operator: it is changed only through one
+descriptor opened from `/` with no link followed, on every apply. The same treatment for every other mesh
+directory was left out of that fix on purpose: it touches every placement on every node, and a machine whose
+data lives behind a parent that is a link (a mount point reached through one, say) would be refused where it
+is applied today.
+
+## Why it is an issue
+
+Root follows a path a parent of which another account may be able to replace. Whoever can turn a parent of a
+mesh directory into a link between two applies directs root's `chmod` and `chown` at the link's target.
+
+## Impact
+
+Not known whether any node has a mesh directory with a parent another account can write; finding that out is
+the first step of the diagnosis.
+
+## The acceptance test (the operator's view)
+
+No apply of any node changes the mode or owner of anything but the directory its declaration names, whatever
+link appears in that directory's path between applies; and every directory the mesh applies on the four nodes
+today still applies.
+
+## How it is checked
+
+To be written with the fix: a test that swaps a parent of an ordinary mesh directory for a link after an apply
+and finds the link's target untouched; and the guard run over the declarations every node would be sent today.