From e68d0ffa1d7cee4919dcaac366a12c1ac989db0d Mon Sep 17 00:00:00 2001 From: jochen Date: Fri, 9 Oct 2026 19:59:06 +0200 Subject: [PATCH] Issue 358: a mesh directory outside a home is changed by path, through any link; issue 356 points at it The confirmation review of issue 356 found that the by-path chmod and chown of an ordinary mesh directory outside a home follows any link in its path. Issue 356 closed it for a handed-over directory, on every apply; the general gap is older and wider, and is recorded here rather than fixed in passing. --- .../01-diagnosis.md | 8 ++++ .../00-report.md | 47 +++++++++++++++++++ 2 files changed, 55 insertions(+) create mode 100644 04-ISSUES/358-a-mesh-directory-outside-a-home-is-changed-by-path-through-any-link/00-report.md diff --git a/04-ISSUES/356-the-operators-command-ran-a-stale-engine-and-a-hand-over-had-no-channel/01-diagnosis.md b/04-ISSUES/356-the-operators-command-ran-a-stale-engine-and-a-hand-over-had-no-channel/01-diagnosis.md index e8c35452..6f3dc544 100644 --- a/04-ISSUES/356-the-operators-command-ran-a-stale-engine-and-a-hand-over-had-no-channel/01-diagnosis.md +++ b/04-ISSUES/356-the-operators-command-ran-a-stale-engine-and-a-hand-over-had-no-channel/01-diagnosis.md @@ -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)). diff --git a/04-ISSUES/358-a-mesh-directory-outside-a-home-is-changed-by-path-through-any-link/00-report.md b/04-ISSUES/358-a-mesh-directory-outside-a-home-is-changed-by-path-through-any-link/00-report.md new file mode 100644 index 00000000..4e7886b5 --- /dev/null +++ b/04-ISSUES/358-a-mesh-directory-outside-a-home-is-changed-by-path-through-any-link/00-report.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.