Please read /etc/login.defs at runtime

[bigon]

Hi,

ATM, SYS_UID_MAX and SYS_GID_MAX from /etc/login.defs are read at compilation time.

As a local admin can change these values, shouldn't these be read at runtime instead?

[poettering]

I am strongly against this. Sorry. These defines should be chosen by the distro vendor, not by users. And it's not realistic to change these definitions during runtime anyway (as you cannot reasonably move the IDs allocated during installation).

Quite frankly, these settings should never have been in /etc as this suggests all would be fine with randomly changing the values for this, but this cannot work. Sorry.

[bigon]

Well I can see several uses cases where changing the distribution default doesn't require renumbering. Nothing force the admin to create a user with UID = SYS_UID_MAX+1 (or even have any "real" user created during the installation).

For example, a colocation place where all the applications (or even customers) are running in a different UID and where the user are assigned from a LDAP in the complete network. That would mean ~1000 (or 500, depending the distribution default) system users for the whole setup, that's not a lot.

[xsuchy]

It starts to be relevant, when you upgrade from older release where UID_MIN is 500 to recent one where it is 1000. Similar change can happen in future.

[nethershaw]

Hello. Sysadmin, here. Allow me please to inject some real-world experience; it is 2018, and I am still seeing this problem in the wild where the effective SYS_UID_MAX has inconsistent and changing values.

@poettering -- Your argument appears to be philosophical. Whether or not SYS_UID_MAX and SYS_GID_MAX should be in /etc/login.defs or not is moot. They are in /etc/login.defs. Furthermore, distributions change their minds as to what the cutoff for system UIDs ought to be often enough to cause problems. And they do it inconsistently. Here is an example of one distribution handling such a change very, very poorly (and admitting to that fact).

The fact that some distributions engage in the unjustifiable practice of hard-coding this threshold does not in itself excuse importing that same bad behavior. It leads to the software deferring to the distribution, and the distribution deferring to the software (see the Fedora bugzilla link above), which ultimately results in circular reasoning and no choices.

In this comment you indicate that these settings are "not really up to admins to change," but as an admin, I beg to differ. Because distributions cannot be relied upon to be consistent, and because distributions change with time, and because I have an enterprise environment to support where UID/GID assignments given by my organization apply additional constraints to what may be considered a 'system' user or group, I contend that it is in fact solely up to me as the sysadmin to change.

All indeed would not be fine with "randomly changing values" for SYS_UID_MAX, and that is precisely the reason it needs to be under the system administrator's absolute control -- that is the only way I can stop it from changing when I very much cannot allow it to.