Look at /etc/login.defs for the system_max_[ug]id values

It makes little sense to make the boundary between systemd and user guids
configurable. Nevertheless, a completely fixed compile-time define is not
enough in two scenarios:
- the systemd_uid_max boundary has moved over time. The default used to be
  500 for a long time. Systems which are upgraded over time might have users
  in the wrong range, but changing existing systems is complicated and
  expensive (offline disks, backups, remote systems, read-only media, etc.)
- systems are used in a heterogenous enviornment, where some vendors pick
  one value and others another.
So let's make this boundary overridable using /etc/login.defs.

Fixes #3855, #10184.

1 files changed, 5 insertions, 4 deletions

diff --git a/docs/UIDS-GIDS.md b/docs/UIDS-GIDS.md
index 67e6d083ff..e289a9b68e 100644
--- a/docs/UIDS-GIDS.md
+++ b/docs/UIDS-GIDS.md
@@ -171,10 +171,11 @@ pick — given that 64K UIDs are assigned to each container according to this
 allocation logic, the maximum UID used for this range is hence
 1878982656+65535=1879048191.)
 
-Note that systemd does not make any of these values runtime-configurable. All
-these boundaries are chosen during build time. That said, the system UID/GID
-boundary is traditionally configured in /etc/login.defs, though systemd won't
-look there during runtime.
+Systemd has compile-time default for these boundaries. Using those defaults is
+recommended. It will nevertheless query `/etc/login.defs` at runtime, when
+compiled with `-Dcompat-mutable-uid-boundaries=true` and that file is present.
+Support for this is considered only a compatibility feature and should not be
+used except when upgrading systems which were creating with different defaults.
 
 ## Considerations for container managers