Hello, 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.
--
Sean Whitton
signature.asc
Description: PGP signature
