nixos/security/wrappers: Broken wrapper definition breaks login

[gmacon]

Nixpkgs version

• Stable (24.11)

Describe the bug

Having a bad configuration value in security.wrappers prevents login without clear errors.

Steps to reproduce

Define a system with this NixOS module:

{ lib, pkgs, ... }:
{
    security.wrappers.tcpdump = {
        owner = "root";
        group = "root";
        capabilities = "cap_net_admin,net_cap_raw+ep";  # NOTE net_cap instead of cap_net
        source = lib.getExe pkgs.tcpdump;
    };
}

then launch a VM of that system nix run .#nixosConfigurations.test.config.system.build.vm. Observe that you cannot log in even with correct credentials.

Expected behaviour

Either the configuration should fail to build or it should not prevent login.

Screenshots

No response

Relevant log output

Additional context

I was able to resolve the issue by commenting out half of the configuration at a time until I isolated what was causing the problem, at which point my coworker noticed the typo. At that point, the problem was solved, but I continued looking into it to figure out why it was causing that particular symptom.

The script that creates the wrappers works atomically (creating either all or none of the wrappers) and so a broken configuration is similar to #369441; the unix_chkpwd wrapper being missing prevents login from working. This suggests to me that the correct behavior is either:

1. The build script should build each wrapper independently so that only the broken ones are missing. This is probably simple to implement but can hide errors until someone notices that the wrapped program isn't working as expected.
2. The module should somehow verify that the configuration is correct and fail at the eval stage if it isn't. This feels like it might be difficult because what makes a valid configuration might depend on the kernel version and configuration.

System metadata

• system: "x86_64-linux"
• host os: Linux 6.8.0-51-generic, Ubuntu, 22.04.4 LTS (Jammy Jellyfish), nobuild
• multi-user?: yes
• sandbox: yes
• version: nix-env (Lix, like Nix) 2.92.0 System type: x86_64-linux Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux Features: gc, signed-caches System configuration file: /etc/nix/nix.conf User configuration files: /home/gmacon3/.config/nix/nix.conf:/etc/xdg/xdg-gnome-xorg/nix/nix.conf:/etc/xdg/nix/nix.conf Store directory: /nix/store State directory: /nix/var/nix Data directory: /nix/store/m9x3y8acqnm2jvn2papmq6bl5z1qpfck-lix-2.92.0/share
• nixpkgs: /nix/store/v1h40ld1w8wr4s9iksiz5j7fz3n12gqw-source

Notify maintainers

@ixmatus

Note for maintainers: Please tag this issue in your pull request description. (i.e. Resolves #ISSUE.)

I assert that this issue is relevant for Nixpkgs

• I assert that this is a bug and not a support request.
• I assert that this is not a duplicate of an existing issue.
• I assert that I have read the NixOS Code of Conduct and agree to abide by it.

Is this issue important to you?

Add a 👍 reaction to issues you find important.

[5225225]

FWIW, capsh --supports=cap_net_admin is a thing, so we probably could verify that the configuration is correct (or at least that capsh knows what the named cap is, even if we don't know if the kernel you're about to boot into knows what it is).