Root-only-login assertion reads a locked password as a password, refusing any real service #139

New issue

Closed

opened 2026-10-07 18:40:35 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-10-07 18:40:35 +01:00

Primary goals:

A locked account is not a login — hashedPassword = "!", "!!" or "*" is the canonical way to say password login is disabled, so none of them counts as a credential.
The guarantee stays — an account with a real password hash, a password file, or an authorized key is still refused, and a sabotage fixture proves each.
The assertion claims only what it enforces — a profile's own ssh daemon can authorize its own users by its own means, which the archetype neither sees nor controls; the message and the README should say that rather than promising root is the only possible login.

Current state and specifics

nix/builders/service.nix's loginCapableUsers treats any non-null hashedPassword as a credential. modules/forgejo/default.nix gives its clone user hashedPassword = "!" with isSystemUser = true, no declared authorized keys — the clone daemon authorizes through AuthorizedKeysCommand with AuthorizedKeysFile none — and a shellPath whose script execs forgejo serv for a well-formed forced command and otherwise prints "git SSH login is forced-command only." and exits 1.

So the account cannot authenticate by password and cannot obtain a session, and the assertion counts it anyway. Measured by evaluating the forge machine with the three data inputs overridden at their current masters:

Failed assertions:
- the service archetype allows only root to log in; found login-capable account(s): ["git","root"]

The archetype's hard guarantee is services.openssh.settings.AllowUsers = [ "root" ] on the administrative daemon, which holds whatever exists in /etc/passwd. The assertion is the evaluation-time backstop against a profile declaring login credentials, and that is the claim it should make.

The shell half of the predicate needs no change: it recognises a nologin shellPath and otherwise treats a shell as a login shell, which is the fail-closed direction.

Scope

In: the password predicate, the assertion's message, the matching check findings and sabotage fixtures in checks/service-archetype.nix, and the README's Builders paragraph. Out: the AllowUsers setting, which is correct; and the forge machine itself, which lives in the data repositories.

Part of allod/strategy#65

The service archetype refuses a service VM that runs an actual service: its root-only-login assertion reads a locked password as a password, so the first machine to compose a real service module fails to evaluate. Primary goals: - **A locked account is not a login** — `hashedPassword = "!"`, `"!!"` or `"*"` is the canonical way to say password login is disabled, so none of them counts as a credential. - **The guarantee stays** — an account with a real password hash, a password file, or an authorized key is still refused, and a sabotage fixture proves each. - **The assertion claims only what it enforces** — a profile's own ssh daemon can authorize its own users by its own means, which the archetype neither sees nor controls; the message and the README should say that rather than promising root is the only possible login. ### Current state and specifics `nix/builders/service.nix`'s `loginCapableUsers` treats any non-null `hashedPassword` as a credential. `modules/forgejo/default.nix` gives its clone user `hashedPassword = "!"` with `isSystemUser = true`, no declared authorized keys — the clone daemon authorizes through `AuthorizedKeysCommand` with `AuthorizedKeysFile none` — and a `shellPath` whose script execs `forgejo serv` for a well-formed forced command and otherwise prints "git SSH login is forced-command only." and exits 1. So the account cannot authenticate by password and cannot obtain a session, and the assertion counts it anyway. Measured by evaluating the `forge` machine with the three data inputs overridden at their current masters: Failed assertions: - the service archetype allows only root to log in; found login-capable account(s): ["git","root"] The archetype's hard guarantee is `services.openssh.settings.AllowUsers = [ "root" ]` on the administrative daemon, which holds whatever exists in `/etc/passwd`. The assertion is the evaluation-time backstop against a profile *declaring* login credentials, and that is the claim it should make. The shell half of the predicate needs no change: it recognises a nologin `shellPath` and otherwise treats a shell as a login shell, which is the fail-closed direction. ### Scope In: the password predicate, the assertion's message, the matching check findings and sabotage fixtures in `checks/service-archetype.nix`, and the README's Builders paragraph. Out: the `AllowUsers` setting, which is correct; and the `forge` machine itself, which lives in the data repositories. Part of allod/strategy#65

vnprc-agent referenced this issue from a commit

2026-10-07 18:49:50 +01:00

forge VM: the forge machine evaluates; two commits left to relay

vnprc referenced this issue from a commit

2026-10-07 19:01:53 +01:00

Stop reading a locked password as a login credential

vnprc-agent commented

2026-10-09 05:14:08 +01:00

Author

Landed on master in 87b0eae (Stop reading a locked password as a login credential); the forge machine evaluates with its locked git account. Closing as part of allod/strategy#65 housekeeping.

Landed on master in 87b0eae (Stop reading a locked password as a login credential); the forge machine evaluates with its locked git account. Closing as part of allod/strategy#65 housekeeping.

vnprc-agent closed this issue

2026-10-09 05:14:09 +01:00