Graduate research 025: the environment and the shell's contributions

ADR 0203: the account's environment is one module's (seat node-environment); every module contributes variables and PATH entries, rendered by the controller as a POSIX file and as environment.d. ADR 0204: shell code is contributed to the login shell in named slots, and login-shell becomes the mesh's node-login-shell. ADR 0205: software the distribution does not package ships as a pinned archive of the module. Issue 225: undeclaring a user stops a node applying; the shell is never given back or checked. To-be 41 carries the work packages; to-be 38 WP5 points to it.
2026-10-04 10:30:23 +02:00
parent 947b85af5e
commit 0bf70ee8b4
12 changed files with 650 additions and 10 deletions
@@ -0,0 +1,50 @@
+---
+status: located
+opened: 2026-10-04
+located-in:
+  - mesh-host
+fixed-by:
+amended-design:
+---
+
+# 225 — A login the mesh set is never given back, and undeclaring one stops the node applying
+
+## What was observed
+
+2026-10-04. Before the shell module of to-be 38 WP5 was assigned anywhere, a review traced what the
+host does with the `user` shape the module declares (the operator account, with the login shell zsh)
+on three events: first assign, a later push, and unassign.
+
+1. **Undeclaring a `user` stops the node applying anything, for good.**
+   - The host's removal has no case for a `user`, so the orphaned record fails with "no way to remove".
+   - Orphans are removed before the declaration's first resource, and that failure aborts the apply.
+   - The record stays in the host's store, so every later apply fails the same way.
+
+   This was reproduced in a throwaway test against the host's code: the apply produced no outcomes,
+   and an unrelated file in the same declaration was not written. Renaming the resource's id has the
+   same effect. A showcase module carries a `user` today and is exposed to it too.
+2. **The shell the account had is never recorded.** [ADR 0176](../../02-DECISIONS/0176-the-login-shell-is-a-node-seat-and-execute-is-its-contract.md)
+   §2 says the host "gives back [the login shell] when the holding moves". The host keeps nothing to
+   give back.
+3. **A login shell is set whether or not it exists.** A failed package install does not stop the
+   resources after it. `usermod --shell` on the distribution only warns about a missing or
+   non-executable shell, and succeeds. The host's read-back compares the user database's string,
+   which matches. So an account can be pointed at a shell that is not there, and console, ssh and
+   display-manager logins then fail. No machine hit this, because zsh was already installed on all
+   four.
+
+## Why it matters beyond this instance
+
+Unassigning any module with a login in it, the case the mesh promises is ordinary, wedges the
+machine's applies until a person edits the host's store. It is the same class of failure as an
+earlier archive that could not be removed: a shape the host can create and cannot take away.
+
+## Located
+
+mesh-host, `internal/apply`: `remove()` has no `user` case, and `applyUser` neither records the shell
+it replaced nor checks the shell it sets. The fix is set out in
+[to-be 41](../../03-DESIGN/01-to-be/41-the-shell-and-the-accounts-environment.md) WP1:
+
+- a removal that never deletes an account;
+- the login shell given back, if it is still the one the mesh set and the recorded one still exists;
+- a shell refused before it is set unless it is executable and listed among the machine's shells.