Discussion was at #5329
Fixing a simple brainfuck can be quite problematic, let's make sure our UX is better.
How come we can't check for "wheel accessibility" as @edolstra proposed in the previous thread on configuration build? This would seem to be the best check, and work for normal builds or initial installation alike.
I got bitten by this exact issue when I first installed NixOS, and was trying to set up wheel user with password plus password-less root. So had the current check existed then, I might have still screwed myself over as giving root a password was not my intent.
Just got an issue with this, Totally not expecting adding mutableUsers=false will actually _mutate_ shadow file and lock all the user out. Can't even login to single user mode since nixOS doesn't have sulogin. This rather ironic.
Any workaround for this? I tried to mount the disk from installer cd and unlock the user from /etc/shadow but it keeps reverting the file. Can I do nixos-rebuild from the installer environment? any chroot?
@fudanchii I think nixos-install will just do a rebuild.
Marking this as a blocker, I think locking out users by accident is not what we want.
@puffnfresh Awesome, that works thanks, just adding a note that it also reverting the system back to 4.12.868 though (obviously).
@domenkozar thanks, sorry for the noise before. Just to keep the ball rolling, this got me thinking, it would probably good for nixos-rebuild if it can detect locking for all users like this and just abort the build. For the very least this will make user aware about what mutableUsers really means.
Another alternative is probably to have some options to automatically convert /etc/shadow into passwordFile and let user supply them to configuration.nix.
anyway, thanks.
@domenkozar Not sure if this should be a blocker given that 14.12 had the same behaviour (I think).
we should find a solution for this release otherwise it will wait another 6 months and the current behaviour is unclear as I've seen many people being locked out
Great!
I had a SSH authorized key set, but disabled openssh and mutableUsers, so I still locked myself out. Maybe this can be re-opened to fix that particular loophole?
Cross-posting from #95130 now that I've noticed this ticket:
Why are members of the
wheelgroup necessarily considered privileged enough to change user account passwords (in this case, presumably by changing the NixOS configuration) or otherwise save users from being locked out of their accounts? Is this assumingsecurity.sudo.enable = true(which the code does not check), or am I just missing something?
(I wondered now whether maybe the security.sudo.enable option just didn't exist in the days when ticket numbers had only four digits, but that doesn't seem to have been the case.)
Most helpful comment
I had a SSH authorized key set, but disabled openssh and mutableUsers, so I still locked myself out. Maybe this can be re-opened to fix that particular loophole?