53 lines
2.8 KiB
Markdown
53 lines
2.8 KiB
Markdown
---
|
|
status: located
|
|
opened: 2026-10-04
|
|
located-in:
|
|
- mesh-host
|
|
fixed-by:
|
|
amended-design:
|
|
---
|
|
|
|
# 228 — 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
|
|
(a shell that refuses logins need only be executable, since the distribution does not list it and
|
|
the controller's own account uses one).
|