nixos/nsswitch cleanup nss modules

[flokli]

This moves the remaining NSS modules to their corresponding modules, and contains some follow-up fixes, where we missed adding to the group database (as the passwdArray was used both for system.nssDatabases.passed and system.nssDatabases.group).

It also removes the conditional loading of systemd nss modules, as requested in #86940 (comment).

closes #86350.

Motivation for this change

#86350

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[dasJ]

@GrahamcOfBorg test google-oslogin avahi

Samba test doesn't seem to be testing the right stuff.
LDAP test is broken as in #86305.

[dasJ]

The code looks good to me, but I haven't tested it (as I don't use most of the stuff), which is why I'm commenting instead of approving.

Thanks for spotting my mistake with the groups, looks good now.

[flokli]

Maybe ping @xastor and @ajs124 on the samba changes, as there are no VM tests testing this currently.

[ajs124]

I say what @dasJ says.

[dasJ]

@ajs124 As a general rule of thumb or only in this particular case?

[flokli]

squashed the fixup commit and rebased on master.

[andir]

Does look reasonable to me.

Do we have some tests or can you write some integration tests with beaker? ;)

[flokli]

Improved the error message as described, and rebased on top of master another time. PTAL.

[flokli]

Okay, let's cook this in unstable.

[orivej]

The current error message is not very helpful, I still had to look at the source code, look up the commit and this PR to understand what is going on:

Loading NSS modules from system.nssModules (/nix/store/…), requires services.nscd.enable being set to true.

I'd suggest a more actionable error message:

NSS modules from system.nssModules (/nix/store/…) will not be loaded without nscd, please set system.nssModules = lib.mkForce [ ]; or services.nscd.enable = true;

(I guess that those who have already disabled nscd would rather keep it disabled and do not need this assertion at all. However, the new users might like to be warned when they disable nscd for the first time…)

[flokli]

@orivej the problem was that people disabling nscd didn't really notice they had their system with a dysfunctional NSS system.

Most code adding to nss modules only did this "optionally" when nscd was enabled (and by doing this, never triggering the assertion). However, there's a lot of places in NixOS where we rely on a functional NSS system, so alerting in these cases by actually triggering the assertion is preferrable.

The suggested error message isn't that clear either on what's preferred now. If we want to avoid people having to read the source, we probably need to be a bit more verbose. What about this?

NSS modules from system.nssModules (/nix/store/…) will not be loaded unless nscd is enabled. Disabling nscd is stongly discouraged, as a dysfunctional NSS system breaks features already used in a base NixOS system, such as systemd dynamic user lookups or container hostname resolution. If you really know what you're doing, you can override this by setting system.nssModules = lib.mkForce [ ];.

Can you elaborate on usecases to disable nscd? When would one explicitly want to opt in to have broken NSS lookups?

[orivej]

I have disabled nscd because I do not want to erase the boundary between Linux network namespaces when it comes to DNS — otherwise the requests from nscd-aware applications originate from the nscd namespace rather than the application namespace. (Here are the relevant bits of my config: #52411 (comment).) I know that this disables some systemd-based name resolution and I'm OK with that since I never encounter such names.

I'd suggest this edit:

NSS modules from system.nssModules (/nix/store/…) will not be loaded unless nscd is enabled. Disabling nscd breaks systemd dynamic user lookup and container hostname resolution. To enable nscd, do not set services.nscd.enable = false; to proceed without nscd, set system.nssModules = lib.mkForce [ ].

[flokli]

@orivej thanks for the pointer! That's an interesting usecase. I wonder if you could just make nscd unavailable from these namespaced units, via BindPaths, or whether there's a way to restrict this to tell nscd-aware applications to not resolve hosts via nscd from that namespace.

I don't remember exactly how the breakages looked (need to check), but "systemd dynamic user lookup and container hostname resolution" are only examples on a basic installation - with disabled nscd, all custom nss modules will break.