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
@@ -167,3 +167,10 @@ service manager's tools do; a refusal by sudo is said as one.
| `node-mounts.mount` | a | mount one share or source now |
| `node-mounts.unmount` | a | release one now; its automount stays armed |
| `node-mounts.adopt` | a | take over one hand-written fstab line, as above |
## 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.