* Sean Whitton <[email protected]> [250318 06:29]:
On Mon 17 Mar 2025 at 10:49am +01, Chris Hofstaedtler wrote:* Sean Whitton <[email protected]> [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.Whoops, neither of us noticed these ranges overlap! 600000001 belongs to the non-subuids range, I think?
I had to check how it actually works. (Note there's a '1' in the middle of the
'0's.)
600100000 belongs to the subuid range.
600100001 is in the dynamically allocated user accounts range.
Thus I propose this corrected text:
diff --git i/policy/ch-opersys.rst w/policy/ch-opersys.rst
index 1501076..5ac9855 100644
--- i/policy/ch-opersys.rst
+++ w/policy/ch-opersys.rst
@@ -292,11 +292,17 @@ 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, 600100001-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`` in its default configuration (and thus ``adduser``)
+ automatically allocate a range of 65536 of these to each new
+ non-system user created.
+
4294967294:
``(uid_t)(-2) == (gid_t)(-2)`` *must not* be used, because it is
used as the anonymous, unauthenticated user by some NFS
Chris
signature.asc
Description: PGP signature
