Increase the system user id range #65698

infinisil · 2019-07-31T22:15:59Z

This is now a full RFC at NixOS/rfcs#52

This enlarges the system uid/gid range 6-fold, from 100 to 600 ids. This
is a preventative measure against running out of dynamically allocated
ids for NixOS services with isSystemUser, which should become the
preferred way of allocating uids for non-real users if DynamicUser isn't applicable.

Motivation for this change

We're running out of static uid/gid's in the standard range from 0 to 400, only ~85 are left:

nixpkgs/nixos/modules/misc/ids.nix

Lines 341 to 344 in 9fe0552

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

While it might be possible to assign another range for static id's, that's just an ugly solution, and having to declare static id's has always been a bit of a pain.

A better solution is to not assign static id's for services, but to use NixOS dynamic user allocation (happening by default, when uid/gid = null). Specifically with isSystemUser = true such that ids get allocated in the range SYS_{U,G}ID_MIN (400) - SYS_{U,G}ID_MAX (499 before this change, 999 after), meaning the range above 1000 can be used exclusively by real users.

Why extend it to 999? Because a limit of 100 ids means that over the lifetime of a NixOS system, users can only ever run 100 different services, since id's aren't repurposed after a service is disabled (See a57bcd3), which is a bit on the low side. And 999 (={U,G}ID_MIN-1) is also the default value anyways, see man login.defs.

This means that instead of having a limit of 400 static uids for all NixOS services in nixpkgs, we have a limit of 600 dynamic uids for all NixOS services ever enable on a single system.

But isn't it bad to not use static id's for services?

I don't think so. One reason I can think of for having static id's is for some service that needs to transfer its files across NixOS machines, but this is not the case for most services. Another reason might be that loading data from backups into a new NixOS installation will make services not work due the mismatch of data and service ids. This is however not a problem if /var/lib/{u,g}id-map gets restored as well, and also not a problem if services use StateDirectory or systemd.tmpfiles which fixes permissions on service start.

See #60732 (comment) for a previous discussion

cc @ryantm @arianvp @aanderse @edolstra

infinisil · 2019-07-31T22:18:08Z

While not directly a problem, this is not beneficial for @jameysharp's move to all-static uid's in #64594

arcnmx · 2019-07-31T23:56:39Z

Is it possible and/or are there plans to unassign the existing ~300 IDs, moving them to either isSystemUser or DynamicUser? (assuming that the fact they already exist in passwd/uid-map/whatever means they can just remain as-is on existing systems)

infinisil · 2019-08-01T00:07:18Z

I believe it would be safe to switch services that don't need static uid's to isSystemUser (because existing systems will get the same id's from /var/lib/nixos/{u,g}id-map). DynamicUser might also be safe if systemd can handle this transition, this should be tested first.

arcnmx · 2019-08-01T00:14:37Z

Last I recall reading about DynamicUser it was explicitly stated as a goal that it be able to handle seamless transitions for existing systems (I believe their particular approach is just to treat it as if DynamicUser weren't set if the user already exists on the system?). Certainly yeah stuff to test, just wondering since it seems like it may be unnecessary to keep many of them reserved for the future, which could widen the range of usable system IDs further.

(though systemd is meant to handle the transition, if nixos removes deleted users from passwd that may or may not cause problems; really depends on whether StateDirectory= is the whole story or not for a given service I guess? but even then if it's fine and then you tried rolling back... poof?)

aanderse · 2019-08-01T01:06:38Z

Unfortunately moving to DynamicUser for many of the existing nixos modules will be difficult because the dataDir pattern (or maybe in this case anti-pattern).

reanimus · 2019-08-07T18:39:47Z

So, after some discussion in the IRC channel, it looks line roon-server doesn't work with DynamicUser enabled, as the backup mechanism needs to be able to write to a persistent location and DynamicUser would make managing permissions for this directory impossible.

infinisil · 2019-08-07T18:42:02Z

Yeah so it might be the case that we can't use DynamicUser as much as we'd like to

edolstra · 2019-08-09T13:02:50Z

My understanding is that DynamicUser is only intended for services that don't have persistent state.

aanderse · 2019-08-09T13:20:16Z

@edolstra there is some allowance for persistent data. See 'Persistent Data' section of http://0pointer.net/blog/dynamic-users-with-systemd.html

arianvp · 2019-08-09T13:23:16Z

My understanding is that DynamicUser is only intended for services that don't have persistent state.

Incorrect. It's only meant for services that don't share state between services. Persistent state is definitely possible, as long as it's defined through StateDirectory=,CacheDirectory=,LogDirectory= etc

infinisil · 2019-08-09T13:27:12Z

@volth StateDirectory and co. won't chown recursively when the top-most directory already has the correct perms (source: man systemd.exec), so this can be used for such cases.

systemd.tmpfiles doesn't have such a mechanism unfortunately. It can either chown recursively with Z or it doesn't chown at all if that's not used (the d directive only does anything if the directory doesn't exist yet) (see man tmpfiles.d)

globin · 2019-08-19T11:55:37Z

I'd prefer this being a proper RFC :)

infinisil · 2019-09-05T02:16:46Z

I made this a full RFC, see above

asymmetric · 2019-09-18T19:40:02Z

AFAIK, systemd ignores /etc/login.defs and instead relies on compilation flags to decide the uid pool size.

So it seems you'd have to change this.

infinisil · 2019-10-03T12:13:41Z

@asymmetric Yeah, but I think this is only relevant for users created through useradd, because the dynamic ids allocated by NixOS use the limits in update-users-groups.pl to write /etc/passwd directly

Will do that change too

globin · 2019-10-08T22:47:59Z

FYI NixOS/rfcs#52 is in Final Comment Period

infinisil · 2019-10-12T20:42:49Z

@asymmetric Now applied the change to the systemd build flags too. Will probably have to switch to staging because of this.

@GrahamcOfBorg eval

pkgs/os-specific/linux/systemd/default.nix

nixos/modules/programs/shadow.nix

This enlarges the system uid/gid range 6-fold, from 100 to 600 ids. This is a preventative measure against running out of dynamically allocated ids for NixOS services with isSystemUser, which should become the preferred way of allocating uids for non-real users.

infinisil · 2019-10-14T00:03:40Z

Turns out that the ranges defined in the systemd compile time options really don't matter that much, they're only used by systemd features like ConditionUser=@system and systemd-sysusers (which is apparently another way to allocate ids, maybe we could even use that for NixOS at some point).

The ranges in login.defs are only used for mutable users/groups added with useradd/groupadd/newusers.

And the ones in update-users-groups.pl are used by NixOS to allocate its declaratively defined users.

I added this info to a comment.

Also added links to the issues regarding runtime configuration of systemd ranges.

infinisil · 2019-10-22T12:32:09Z

NixOS/rfcs#52 is now accepted and I think this is ready to be merged.

c0bw3b · 2019-10-24T07:15:38Z

@GrahamcOfBorg test systemd

infinisil · 2019-10-25T22:13:49Z

Hehe, the error on aarch64 is deceivingly related-looking:

error: all build users are currently in use; consider creating additional users and adding them to the 'nixbld' group

But really that only seems to occur as a result of heavy aarch64 builder usage, nothing with this PR.

ofborg bot added 6.topic: nixos 8.has: module (update) 10.rebuild-darwin: 0 10.rebuild-linux: 0 labels Jul 31, 2019

This was referenced Aug 7, 2019

roon-server: disable DynamicUser #66291

Merged

arangodb: Add arangodb as a NixOS service #40167

Closed

infinisil mentioned this pull request Aug 9, 2019

metabase: service module and test #66399

Merged

10 tasks

infinisil mentioned this pull request Aug 18, 2019

rivalcfg: init at 3.6.0 #66534

Closed

10 tasks

infinisil mentioned this pull request Aug 27, 2019

WIP: update mailman to version 3.2.2 #67461

Closed

infinisil mentioned this pull request Sep 5, 2019

[RFC 0052] Away from static IDs NixOS/rfcs#52

Merged

c0bw3b approved these changes Oct 5, 2019

View reviewed changes

infinisil mentioned this pull request Oct 12, 2019

treewide: Switch to system users #71055

Merged

10 tasks

infinisil changed the title ~~[RFC] Away from static id's for services~~ Increase the system user id range Oct 12, 2019

infinisil force-pushed the system-users branch from 5b3ed92 to 306e7f6 Compare October 12, 2019 20:41

ryantm approved these changes Oct 12, 2019

View reviewed changes

ofborg bot requested review from edolstra and andir October 12, 2019 21:08

ofborg bot added 10.rebuild-darwin: 101-500 10.rebuild-linux: 501+ 10.rebuild-linux: 5001+ and removed 10.rebuild-darwin: 0 10.rebuild-linux: 0 labels Oct 12, 2019

asymmetric reviewed Oct 13, 2019

View reviewed changes

pkgs/os-specific/linux/systemd/default.nix Outdated Show resolved Hide resolved

nixos/modules/programs/shadow.nix Outdated Show resolved Hide resolved

infinisil force-pushed the system-users branch from 306e7f6 to 0a94f7f Compare October 13, 2019 23:19

infinisil changed the base branch from master to staging October 13, 2019 23:20

ofborg bot requested a review from Mic92 October 13, 2019 23:34

infinisil force-pushed the system-users branch from 0a94f7f to 23d920c Compare October 13, 2019 23:59

dasJ approved these changes Oct 23, 2019

View reviewed changes

asymmetric approved these changes Oct 24, 2019

View reviewed changes

infinisil merged commit de357d5 into NixOS:staging Oct 27, 2019

infinisil deleted the system-users branch November 1, 2019 12:19

infinisil added the significant Novel ideas, large API changes, notable refactorings, issues with RFC potential, etc. label Apr 19, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Increase the system user id range #65698

Increase the system user id range #65698

infinisil commented Jul 31, 2019 •

edited

infinisil commented Jul 31, 2019

arcnmx commented Jul 31, 2019

infinisil commented Aug 1, 2019

arcnmx commented Aug 1, 2019 •

edited

aanderse commented Aug 1, 2019

reanimus commented Aug 7, 2019

infinisil commented Aug 7, 2019

edolstra commented Aug 9, 2019

aanderse commented Aug 9, 2019

arianvp commented Aug 9, 2019

infinisil commented Aug 9, 2019

globin commented Aug 19, 2019

infinisil commented Sep 5, 2019

asymmetric commented Sep 18, 2019 •

edited

infinisil commented Oct 3, 2019

globin commented Oct 8, 2019

infinisil commented Oct 12, 2019

infinisil commented Oct 14, 2019

infinisil commented Oct 22, 2019

c0bw3b commented Oct 24, 2019

infinisil commented Oct 25, 2019

	zoneminder = 314;
	paperless = 315;

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

Increase the system user id range #65698

Increase the system user id range #65698

Conversation

infinisil commented Jul 31, 2019 • edited

Motivation for this change

But isn't it bad to not use static id's for services?

infinisil commented Jul 31, 2019

arcnmx commented Jul 31, 2019

infinisil commented Aug 1, 2019

arcnmx commented Aug 1, 2019 • edited

aanderse commented Aug 1, 2019

reanimus commented Aug 7, 2019

infinisil commented Aug 7, 2019

edolstra commented Aug 9, 2019

aanderse commented Aug 9, 2019

arianvp commented Aug 9, 2019

infinisil commented Aug 9, 2019

globin commented Aug 19, 2019

infinisil commented Sep 5, 2019

asymmetric commented Sep 18, 2019 • edited

infinisil commented Oct 3, 2019

globin commented Oct 8, 2019

infinisil commented Oct 12, 2019

infinisil commented Oct 14, 2019

infinisil commented Oct 22, 2019

c0bw3b commented Oct 24, 2019

infinisil commented Oct 25, 2019

infinisil commented Jul 31, 2019 •

edited

arcnmx commented Aug 1, 2019 •

edited

asymmetric commented Sep 18, 2019 •

edited