Persisting passwords (/etc/shadow)

[jordanisaacs]

I would like to persist shadow without persisting the entire /etc directory. Are there any solutions to this? Mounting fails due to the way passwd works with renaming. I tried playing around with symlinking (manually) and that also seems to not work.

[2xsaiko]

environment.etc = {
  "group".source = "/nix/persist/etc/group";
  "passwd".source = "/nix/persist/etc/passwd";
  "shadow".source = "/nix/persist/etc/shadow";
};

This works for me. (Not sure if the other two are necessary, I assume probably not?)

[talyz]

The preferred solution is to use declarative users (setting mutableUsers = false and declaring passwords in the configuration). Does that not work for you? What issues are you seeing when you try to persist /etc/shadow?

[jcszymansk]

@2xsaiko It doesn't work for me. Linking all the three files (as @2xsaiko suggested) broke things for me when I tried to enable nginx afterwards (files were linked after the user nginx was created, effectively deleting it); linking only /etc/shadow doesn't work either - as soon as the first user changes their password, the file is no longer a link, but a regular file, to be recreated on reboot. Am I doing something wrong?

@talyz Declarative users cannot change their passwords, this may be a requirement (it is here...).

[2xsaiko]

Ahh, yeah shadow does get unlinked when I change the password, and I assume I would have the same issue with the rest of the files. I just haven't done that yet after setting this up so I didn't notice.

[jcszymansk]

I tried to modify pam to follow symlink to /etc/shadow on update; the change itself is quite straightforward, but:

• replacing pam via overridePkgs forces the recompilation of the entire system, so I didn't even try this beyond dry-build...
• when I configure a modified pam_unix.so in pam.d/passwd everything seems to work except that when I change, as root, a user's password, the binary aborts for freeing an invalid pointer, but only after the password is changed, most likely somewhere in pam_end. The password is changed in the symlinked shadow, and the symlinks remain intact. If, however, a user changes their password, everything seems to work.

I have no idea how to debug this without having to recompile the entire system on every change to pam, if someone wanted to help it's there: https://github.com/jacekszymanski/nur-packages/tree/master/pkgs/pam-impermalite/ ; I think I'll try to reproduce this abort on a non-nixos linux and if successful, go from there.

[2xsaiko]

FWIW after hitting the same problem as you when having to add a new user, I'm now using mutableUsers=false together with the users.users.USER.passwordFile option, which keeps the password (hash) out of the configuration which is mostly what I wanted.

[jcszymansk]

I got it, it was a "classic" off-by-one malloc error 🤦‍♀️ Had it right before my eyes and didn't see it...

But now it seems it can change users' passwords on symlinked shadow without errors, so linking by environment.etc should work. Of course, use at your own risk etc.

[jacobranson]

@jacekszymanski Is there any chance you'd consider trying to upstream the change to Pam?

[jcszymansk]

@jacekszymanski Is there any chance you'd consider trying to upstream the change to Pam?

No.

I gave this some thought several months back, but as PAM is at the very heart of the OS security, such a change would require a very thorough testing and auditing in many (and I mean many) possible setups. Given that this is a hack designed for an unsupported configuration of an unofficial customization of a niche Linux distro, I don't really think it'd ever happen.