Say that the modules' own checks are the only line before root, since sudo grants the account everything
mesh/delivery-group group feat/mounts-module delivering: 0 of 3 delivered
mesh/merge-gate pass: builds new: modules/mounts, modules/nfs-server, sent nowhere; no bus step; every machine composes with the change as it did without (…
mesh/repo-check fail: its merge-check.sh failed: --- FAIL: TestAnExportLineSquashesEveryClientToTheFoldersOwnerToTheMeshRangeOnly (0.00s)
mesh/delivery superseded: a newer head of the same pull request

This commit is contained in:
jochen
2026-10-08 20:21:28 +02:00
parent 53cc303440
commit 29ac6ee16a
2 changed files with 14 additions and 0 deletions
+7
View File
@@ -102,3 +102,10 @@ shares go. A plain restart, a push or a shutdown leaves the config file in place
own dataset.
- **Exports that are not the mesh's** (`/etc/exports`, a ZFS dataset's `sharenfs`) are left as found and
shown, until `adopt` takes one over on a person's word.
## Root acts and sudo
The tools run as the operator account and act as root through `sudo -n`. The `sudo` module grants that
account every command, so **this module's code is the only line** between a tool call and root: each act
checks again what it may touch before it runs a command, and a test holds each check. Narrowing what sudo
grants the account to the commands these modules need is a separate decision, not made here.