nixos/users-groups: don't allocate coinciding subuid ranges with autoSubUidGidRange

[mikitsu]

Previously, when adding a new user when at least two users already exist, this new user was assigned the same subuid range as the second existing user.

The removal of $used->{$id} = 1; from allocId is necessary since allocSubUid is called unconditionally for auto-allocated subuids, while uid/gid assignments do not call alloc* for existing ids. As it's purpose is, as far as i can determine, to avoid repeated calls to getpwuid / getgrgid, this shouldn't have much of an impact (only when adding more than one user/group at a time).

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.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.

---

Add a 👍 reaction to pull requests you find important.

[mikitsu]

For systems which currently have coinciding subuid ranges, the current code will silently assign new ranges. There are two ways I can think of to handle this:

1. still assign new ranges, but add a warning when we detect that a subuid range has changed. This warning can include a copy-pastable config snippet to explicitly set the range for the user to the old value, making it opt-in but easy to keep the current ranges. This would require minimal code changes (just the warning).
2. keep the old ranges, and add a warning that some ranges coincide. To get non-coinciding ranges, users will need to manually edit /var/lib/nixos/auto-subuid-map. This requires more extensive code changes.

I'd prefer the first option, since

• I expect relatively few people to be affected: you'd have to have existing coinciding ranges (which implies at least three mot likely human users with autoSubUidGidRange = true) and use podman or other software that makes use of subuids
• if you're affected, you'll probably want to not have coinciding ranges anyway (unless your users all trust each other)
• choosing the non-default is easy

However, if not breaking existing systems under any circumstances is important, I'd be happy to implement the second one.

[adisbladis]

I agree going with option number 1 is the best option here, and gate the warning behind system.stateVersion so that new systems that would have been affected with the old behaviour does not emit warnings.
I'd like for some other people to chime in on whether that's an acceptable solution or not.

Code changes LGTM. I've been trying this PR out on my systems (all non-affected) and haven't had any issues.

[mikitsu]

I've added the warning without the system.stateVersion gate, as it only triggers when a subuid range actually changes, which shouldn't happen on new systems (and exactly once on old systems).

Are you OK with the text?

[leona-ya]

I rebased this PR and added a release notes entry.

[leona-ya]

This looks good to me and I also tried this on an affected machine. I added a release notes entry for more clarity.

[leona-ya]

As discussed on matrix: moving this via staging to avoid hurting hydra even more with that many nixos tests changed.

Also thank you very much for the contribution!

[keysmashes]

@leona-ya I feel like a few words are missing in "it could happen that collided with others" – should this say something like "it could happen that some users' allocated subuid ranges collided with others"? (I am trying to keep up with release notes and did not at first understand what this was trying to say)

[leona-ya]

Yes, you are right. A better sentence should be

In users.users subuid allocation on systems with multiple users it could happen that some users' allocated subuid ranges collided with others.

[keysmashes]

Opened #408018 – thank you!