In practice, Debian (and Ubuntu) have fixed minimum system UIDs and GIDs

January 7, 2022

Debian, like many Linux distributions (and probably many Unixes) has the idea of 'system' logins and groups as distinct from normal, non-system users and groups. System users and groups are created by Debian packages for their own use, for either or both of file access permissions (such as making TLS keys accessible by group 'Debian-exim' so that your Exim can read them) or for processes and daemons to run as. The UIDs and GIDs for these logins and groups mostly aren't preassigned; instead, the package gets the next available UID or GID from the system UID or GID range. In theory Debian allows you to control these ranges through /etc/adduser.conf, so that you can (for example) alter them to avoid a range of low UIDs or GIDs that your environment has for historical reasons.

Unfortunately, in practice the start of the range for both system UIDs and GIDs is fixed. This comes about through two things combined together. First, a certain number of system logins and groups are created early in system installation, well before you can normally customize the system. These early system logins and groups will use the standard starting point for system UIDs and GIDs (currently 100 for both), and so be assigned low UIDs and GIDs. This includes things like the 'systemd-network' login and the 'systemd-journal' group.

(Systemd isn't the only only here, but as we'll see it's a pivotal one for the second issue. Other early logins include 'syslog', 'sshd', and '_apt', while early groups include 'crontab', 'syslog', and 'ssh'.)

The second problem is that Debian packages generally re-run their install time postinstall commands on upgrades, which includes re-running the commands that create their system logins and groups. Unfortunately the Debian adduser and addgroup commands include by default a safety measure that checks that existing, theoretical 'system' logins and groups are within the official UID and GID ranges for those, as set in your adduser.conf. If this check fails, adduser and addgroup normally exit with a failure status (as well as printing an error message).

The combined effect of these two together is that if you change the start of the system UID or GID range and then upgrade a core package like systemd, you will get errors during the upgrade of the form:

adduser: The user `systemd-network' already exists, but is not a system user. Exiting.
The group `systemd-journal' already exists and is not a system group. Exiting.

As far as we know, there's no particularly good fix for this. As a result, in practice the minimum system UID and GID are fixed at 100. All you get to really control is the maximum system UID and GID, and there's usually not much point in changing them.

(All of this applies to Ubuntu as well, because Ubuntu inherits all of this stuff from Debian.)


Comments on this page:

By Chris H at 2022-01-11 03:51:24:

Changing the system UID/GID range should not have been exposed in adduser.conf, in my opinion. As demonstrated by your post, its pointless to change it on almost all systems, and thus could just been a compile-time setting.

But if you must change it, then the documentation should tell you to also update all existing system user UIDs/GIDs. It does not spell this out today :-(

By cks at 2022-01-11 09:46:41:

I have the opposite view to you. I feel that changing the system UID and GID range is perfectly reasonable and there are sometimes good reasons to do so. If you have to change the range, renumbering existing system UIDs and GIDs that you're okay with is pointless make-work. All of the problems with the inability to change it and the need to renumber if you do come about from Debian's decision to make 'adduser --system' not idempotent (and the equivalent for groups).

This is where it would be very useful for Debian packages to distinguish between updates and installs, because the situations are not equivalent. If you're installing a package, run 'adduser --system', and a non-system login of that name already exists, you should abort, because it's likely that you're about to use a login for something it wasn't intended for. If you're updating a package and find the same situation, you should not abort; the existing installed package is already using that login, so the situation is no worse off with the updated package.

Written on 07 January 2022.
« An annoyance with Debian postinstall scripts during package upgrades
Good web scraping is not just about avoiding load »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Jan 7 23:12:34 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.