Don't default to nogroup for the primary group of users.

[symphorien]

Motivation for this change

This is unsafe. #130649 shows that most objections raised are about the UX for modules that need adaption so I added a better error message. I also fixed a lot of modules in nixpkgs. Now no nixos test fails to evaluate because of this change.

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 packages 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/)
• 21.11 Release Notes (or backporting 21.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[bjornfor]

I guess changing the name here was intentional?

[symphorien]

The user with the same uid is dhcpd, so I think the c in the comment was a typo.

[infinisil]

Why are these being revived?

[symphorien]

because currently, user rtkit has a static uid and group nogroup. The static uid is there so that files created by this daemon have a constant numerical owner, so the group rtkit I create in this PR must also have a static gid.

It might be the case that neither the user nor the group need a static id at all, but I think this is out of scope of the PR.

[infinisil]

I'm pretty sure we can let all of these just be allocated dynamically, which we should do according to https://github.com/NixOS/rfcs/blob/master/rfcs/0052-dynamic-ids.md. You can do that by just not setting a gid in the group definition.

[symphorien]

My point is merely that a static uid is required iff a static gid is required. So I'm not the one to make the decision to remove the static uid. The maintainers of each module should.

[infinisil]

I don't think a a static uids and gids are linked together? Or where do you see that? Is there an error if you don't assign a static gid?

[symphorien]

we fix uids because filesystems retain ownership by uid, not user name (as attested by the header of ids.nix, which mentions services with many files). This rationale applies equally to group ownership.

[symphorien]

does that look reasonable to you, @infinisil?

[bjornfor]

That last commit seems to be fixups that can be squashed.

[r-rmcgibbo]

Result of nixpkgs-review pr 133166 at a1225538 run on x86_64-linux 1

2 packages built successfully:

• nixos-install-tools
• tests.trivial

---

Result of nixpkgs-review pr 133166 at a1225538 run on aarch64-linux 1

1 package built successfully:

• nixos-install-tools

[rnhmjoj]

I'm facing a similar problem with #126289.
Basically security.wrappers defaults to create files with root:nogroup or nobody:something ownership and consequently many NixOS modules are potentially unsafe. What should I do with these: create new ad-hoc groups for each module or use root when unspecified?

[symphorien]

as far as I understand, root group for setuid and root user for setgid should be best. These should not be written at all anyway, and they only work because they are world readable/executable.

[symphorien]

I fixed the merge conflict

[infinisil]

Re #133166 (comment), you can change this to

Suggested change

	users.groups.rtkit.gid = config.ids.gids.rtkit;
	users.groups.rtkit = {};

Which will work just as well as the current version of this PR, but without requiring a static gid (so the rtkit entry in ids.nix can be deleted). This is exactly what NixOS/rfcs#52 is about, to not use static uid/gid's, which this PR goes against in its current state.

But also like, this PR breaks file ownership either way: Previously the files were owned by nogroup, but now the service will be run by gid rtkit (whether it be dynamically allocated or statically).

[symphorien]

ok but then I should also remove the static uid

[infinisil]

Some more info: We discussed this on matrix. @symphorien made a good argument that whether we choose static or dynamic ids, it should be the same for uid and gid, because any reason to use either static or dynamic can equally be applied to both uid's and gid's.

I suggested to then make them both dynamic, in order to go towards the RFC's direction

[symphorien]

done.

[symphorien]

I think all reviews were addressed. I would like to merge next week unless someone speaks up.

[symphorien]

@GrahamcOfBorg test gnome

[infinisil]

Looking good!

[Izorkin]

System not building with vsftpd enabled

building Nix...
building the system configuration...
error: while evaluating the attribute 'config.system.build.toplevel' at /home/user/works/src-nix/nixpkgs/nixos/modules/system/activation/top-level.nix:298:5:
while evaluating 'foldr' at /home/user/works/src-nix/nixpkgs/lib/lists.nix:52:20, called from /home/user/works/src-nix/nixpkgs/nixos/modules/system/activation/top-level.nix:133:12:
while evaluating 'fold'' at /home/user/works/src-nix/nixpkgs/lib/lists.nix:55:15, called from /home/user/works/src-nix/nixpkgs/lib/lists.nix:59:8:

Failed assertions:
- users.users.vsftpd.group is unset. This used to default to
nogroup, but this is unsafe. For example you can create a group
for this user with:
users.users.vsftpd.group = "vsftpd";
users.groups.vsftpd = {};

After add:

  users = {
    users.vsftpd.group = "vsftpd";
    groups.vsftpd = { };
  };

...
activating the configuration...
warning: user ‘systemd-coredump’ has unknown group ‘systemd-coredump’
setting up /etc...
...