* Sean Whitton <spwhitton@spwhitton.name> [250317 03:32]:
On Sun 16 Mar 2025 at 02:04pm +01, Chris Hofstaedtler wrote:These ranges are in the range currently documented in policy 9.2.2 as: | 65536-4294967293: | Dynamically allocated user accounts. By default adduser will not | allocate UIDs and GIDs in this range, to ease compatibility with | legacy systems where uid_t is still 16 bits. Given this concept exists since at least jessie, I think it should finally be documented in policy, too. I'm not sure about a text. Maybe: diff --git i/policy/ch-opersys.rst w/policy/ch-opersys.rst index 1501076..37b4674 100644 --- i/policy/ch-opersys.rst +++ w/policy/ch-opersys.rst @@ -292,11 +292,16 @@ The UID and GID numbers are divided into classes as follows: This value *must not* be used, because it was the error return sentinel value when ``uid_t`` was 16 bits. -65536-4294967293: +65536-99999, 600100000-4294967293: Dynamically allocated user accounts. By default ``adduser`` will not allocate UIDs and GIDs in this range, to ease compatibility with legacy systems where ``uid_t`` is still 16 bits. +100000-600100000: + Dynamically allocated subordinate user ids. See subuid(5). + ``useradd`` (and thus ``adduser``) automatically allocate these + when non-system users are created.Thanks for this, we should definitely document this. How about Dynamically allocated subordinate user ids. See subuid(5). ``useradd`` in its default configuration (and thus ``adduser``) automatically allocate a range of 65536 of these to each new non-system user created.
Seconded. Chris
Attachment:
signature.asc
Description: PGP signature