nixos/users: require one of users.users.name.{isSystemUser,isNormalUser}

[symphorien]

As the only consequence of isSystemUser is that if the uid is null then
it's allocated below 500, if a user has uid = something below 500 then
we don't require isSystemUser to be set.

Motivation: #112647

Things done

I visually checked that all users.users instances in nixpkgs have either isNormalUser or isSystemUser or uid set. There are more than 500 so I may have missed some.

I tested by evaluating all nixos tests and grepping for the new assertion message.

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

[aanderse]

Additionally should we throw a warning (and eventually error) if createHome = true; when isSystemUser = true; as well?

[symphorien]

Why is this a problem ?

[aanderse]

I'm glad you asked. For a long time I have been observing issues in nixos related to state directory provisioning. createHome is the culprit of some of these issues, but there are other sources too. Here are a few points which should highlight why createHome is a bad idea for system users which are provisioned for system services:

• createHome and mkdir can be a bit too presumptuous about the underlying filesystem that users.users.<name>.home points to: postgresql fails to start if dataDir is not default  #80827
• createHome enforces permissions on system activation, not service activation: nixos/users-groups: createHome: Ensure HOME permissions, fix description #106995
  • this causes confusion on why permissions on the .home directory change and breaks a number of services, presumably more we aren't aware of yet
• there is no way to modify permissions reliably on directories provisioned by createHome

[symphorien]

Interesting. Maybe you should open a tracking issue and we can tackle this in a follow up PR ? Another possible follow up is requiring to set a group (the current default is nogroup and it's not good).

[aanderse]

That is a good point because nobody/nogroup shouldn't be used. Someone should open an issue about createHome, but I'm not sure when I'll get around to it. I haven't been able to prioritize it yet. The issue exists in my brain, at least 😄