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.)

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, Add Comment.
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.