For some time now I've started telling people to stop giving static uid's to users, because it's not needed anymore. NixOS can choose uid's on its own, while reusing previously deleted users uid's since a57bcd38b49. There are only very few cases where it makes sense for a service to have a static uid, such as in multi-machine services that need matching uid's on their files or whatever.

If you look at the file that assigns static uid, you'll notice this comment here:

Lines 340 to 343 in bd94143

    
           cockroachdb = 313; 
        
           zoneminder = 314; 
        
           # When adding a uid, make sure it doesn't match an existing gid. And don't use uids above 399!

This means, we have about 85 uid's left in that range! Over the past years, people have been adding static uid's in this file, almost completely filling up our reserved range from 0-400, see

nixpkgs/nixos/modules/programs/shadow.nix

Lines 13 to 16 in bd94143

    
                 SYS_UID_MIN  400 
        
                 SYS_UID_MAX  499 
        
                 UID_MIN      1000 
        
                 UID_MAX      29999

Yes, we might be able to extend the ranges, but that's ugly and only temporarily solves the problem.

I think there's two things we could do improve this situation:

Make the user/group modification script error out when there's a conflict.
Reserve different ranges of uid's for uid = null and uid = <number> in non-nixpkgs code. So perhaps uid's in the range 1000-20000 could be used by uid = <number>, so the user is free to choose any of those without fear of conflict, because uid = null will only give out uid's above 20000.

	cockroachdb = 313;
	zoneminder = 314;

	# When adding a uid, make sure it doesn't match an existing gid. And don't use uids above 399!

Uh oh!

UIDs are not assigned for all service module users #60732

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions