Hello, On Mon 17 Mar 2025 at 10:49am +01, Chris Hofstaedtler wrote:
> * Sean Whitton <spwhit...@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. Whoops, neither of us noticed these ranges overlap! 600000001 belongs to the non-subuids range, I think? -- Sean Whitton
signature.asc
Description: PGP signature
