Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mutableUsers = false; can lock you out of root #7308

Closed
domenkozar opened this issue Apr 10, 2015 · 10 comments
Closed

mutableUsers = false; can lock you out of root #7308

domenkozar opened this issue Apr 10, 2015 · 10 comments

Comments

@domenkozar
Copy link
Member

Discussion was at #5329

Fixing a simple brainfuck can be quite problematic, let's make sure our UX is better.

@domenkozar domenkozar added this to the 15.05 milestone Apr 10, 2015
@Ericson2314
Copy link
Member

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.

@fudanchii
Copy link

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?

@puffnfresh
Copy link
Contributor

@fudanchii I think nixos-install will just do a rebuild.

@domenkozar
Copy link
Member Author

Marking this as a blocker, I think locking out users by accident is not what we want.

@fudanchii
Copy link

@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.

@edolstra
Copy link
Member

@domenkozar Not sure if this should be a blocker given that 14.12 had the same behaviour (I think).

@domenkozar
Copy link
Member Author

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

@Ericson2314
Copy link
Member

Great!

edolstra added a commit that referenced this issue Sep 2, 2015
Fixes #7308

(cherry picked from commit 6e76765)
Signed-off-by: Domen Kožar <domen@dev.si>
@yorickvP
Copy link
Contributor

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?

@8573
Copy link
Contributor

8573 commented Aug 11, 2020

Cross-posting from #95130 now that I've noticed this ticket:

{ # If mutableUsers is false, to prevent users creating a
# configuration that locks them out of the system, ensure that
# there is at least one "privileged" account that has a
# password or an SSH authorized key. Privileged accounts are
# root and users in the wheel group.

Why are members of the wheel group 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 assuming security.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.)

adrianpk added a commit to adrianpk/nixpkgs that referenced this issue May 31, 2024
Fixes NixOS#7308

(cherry picked from commit 6e76765)
Signed-off-by: Domen Kožar <domen@dev.si>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants