Skip to content
Oznog

6.5 · operations and agents · as-is

NixOS creates users alphabetically, and that is a security-relevant bug

date
20260904
what happened
The fleet standardised the human account at numeric id 1000 and the agent account at 1001. A survey of every host touching shared storage found 13 NixOS hosts, later 14 plus one straggler, with the two ids exactly swapped, because NixOS creates declared users in alphabetical order and the agent name sorts first. A Debian host with the same declared usernames did not have the problem.
what it cost
Nothing had crossed a filesystem boundary that carries numeric ids yet, so the exposure was latent. The moment one did, a file written by the human account on a NixOS host would have appeared owned by the agent account on the Debian host, and the reverse.
what changed
The ids are now declared explicitly in the fleet base module rather than left to creation order, and a phased, host-by-host procedure treats the id change and the file reownership as one atomic operation per host.
the check now
A check subcommand of the id tool runs on any new host before it joins an NFS or rsync flow. macOS, with its native 501 and 502, and the Unraid host are deliberately left alone by policy.

Any fleet mixing NixOS and another distribution, and sharing files by anything other than a name-based protocol, should read this closely. NixOS assigns numeric ids to declared users in alphabetical order unless you pin them. If your two administrative accounts happen to sort in the opposite order from how the other distribution created them, every host quietly disagrees about who owns what.

Nothing detects this when it happens. Names match everywhere you look, and name-based protocols such as SMB, or a metadata-preserving backup that records the name, keep working. It surfaces only when data crosses a boundary that trusts the number instead: NFS with system authentication, or a root-run rsync that preserves ownership. For Node0 the trigger that made the survey worth running at all was the storage cluster beginning to export NFS.

The fix is not subtle: pin the ids. The execution is the hard part. Changing the id in the passwd database without immediately reowning every file that account already owns leaves the host actively worse off than before the fix. Existing files now belong to the other account by number. So the two steps have to happen as one uninterruptible operation, run from outside the host being changed, and verified before the host is allowed back into anything that shares files.

Source: node0 lessons v0.1, lesson 6.5. Sanitized: checklist v0.1, 20260921; repository tool paths; voice pass 20260921. Part of oznog.com/node0.