shaba/systemd-stable
1
1
Fork 0
mirror of https://github.com/systemd/systemd-stable.git synced 2025-01-10 01:17:44 +03:00
Code

docs/UID-GIDS: mention that ranges are actually configurable

Browse Source 
It silly for our docs to say that they aren't when we added support for this a
few years ago.

Also, drop some mentions of "runtime". This implied that those values can be
changed almost at will, but actually, they can only be meaningfully changed
_before_ the allocations are made.

(cherry picked from commit 7e4f30c3d0)
(cherry picked from commit 00ed84c34b)
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2024-01-09 12:10:18 +01:00 committed by Luca Boccassi
parent b9c6e35f71
commit 8992968463
1 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
docs/UIDS-GIDS.md
View File

@ -21,7 +21,7 @@ validity for GIDs too.
In theory, the range of the C type `uid_t` is 32-bit wide on Linux, In theory, the range of the C type `uid_t` is 32-bit wide on Linux,
i.e. 0…4294967295. However, four UIDs are special on Linux: i.e. 0…4294967295. However, four UIDs are special on Linux:
1. 0 → The `root` super-user 1. 0 → The `root` super-user.
2. 65534 → The `nobody` UID, also called the "overflow" UID or similar. It's 2. 65534 → The `nobody` UID, also called the "overflow" UID or similar. It's
where various subsystems map unmappable users to, for example file systems where various subsystems map unmappable users to, for example file systems
@ -57,20 +57,20 @@ Distributions generally split the available UID range in two:
2. 1000…65533 and 65536…4294967294 → Everything else, i.e. regular (human) users. 2. 1000…65533 and 65536…4294967294 → Everything else, i.e. regular (human) users.
Note that most distributions allow changing the boundary between system and Some older systems placed the boundary at 499/500, or even 99/100,
regular users, even during runtime as user configuration. Moreover, some older and some distributions allow the boundary between system and regular users to be changed
systems placed the boundary at 499/500, or even 99/100. In `systemd`, the via local configuration.
boundary is configurable only during compilation time, as this should be a In `systemd`, the boundary is configurable during compilation time
decision for distribution builders, not for users. Moreover, we strongly and is also queried from `/etc/login.defs` at runtime,
discourage downstreams to change the boundary from the upstream default of if the `-Dcompat-mutable-uid-boundaries=true` compile-time setting is used.
999/1000. We strongly discourage downstreams from changing the boundary from the upstream default of 999/1000.
Also note that programs such as `adduser` tend to allocate from a subset of the Also note that programs such as `adduser` tend to allocate from a subset of the
available regular user range only, usually 1000..60000. And it's also usually available regular user range only, usually 1000..60000.
user-configurable, too. This range can also be configured using `/etc/login.defs`.
Note that systemd requires that system users and groups are resolvable without Note that systemd requires that system users and groups are resolvable without
networking available — a requirement that is not made for regular users. This network — a requirement that is not made for regular users. This
means regular users may be stored in remote LDAP or NIS databases, but system means regular users may be stored in remote LDAP or NIS databases, but system
users may not (except when there's a consistent local cache kept, that is users may not (except when there's a consistent local cache kept, that is
available during earliest boot, including in the initrd). available during earliest boot, including in the initrd).