jochen
0bf70ee8b4
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.
2.6 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | |
|---|---|---|---|---|---|
| located | 2026-10-04 |
|
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.
-
Undeclaring a
userstops 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
usertoday and is exposed to it too. - The host's removal has no case for a
-
The shell the account had is never recorded. ADR 0176 §2 says the host "gives back [the login shell] when the holding moves". The host keeps nothing to give back.
-
A login shell is set whether or not it exists. A failed package install does not stop the resources after it.
usermod --shellon 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 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.