From 9e4b88936694a3339ce56190b6d77187b40b920c Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Thu, 11 Jan 2018 13:08:57 +0100 Subject: [PATCH] UIDS-GIDS: document early on, that 32bit uids are a linux 2.4 thing --- UIDS-GIDS.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/UIDS-GIDS.md b/UIDS-GIDS.md index d44d93d..71e91fa 100644 --- a/UIDS-GIDS.md +++ b/UIDS-GIDS.md @@ -26,13 +26,13 @@ i.e. 0…4294967295. However, four UIDs are special on Linux: call the `nobody` group `nogroup`. I wish they didn't.) 3. 4294967295, aka "32bit `(uid_t) -1`" → This UID is not a valid user ID, as - setresuid(), chown() and friends treat -1 as a special request to not change - the UID of the process/file. This UID is hence not available for assignment - to users in the user database. + `setresuid()`, `chown()` and friends treat -1 as a special request to not + change the UID of the process/file. This UID is hence not available for + assignment to users in the user database. -4. 65535, aka "16bit `(uid_t) -1`" → Once upon a time `uid_t` used to be 16bit, and - programs compiled for that would hence assume that `(uid_t) -1` is 65535. This - UID is hence not usable either. +4. 65535, aka "16bit `(uid_t) -1`" → Before Linux kernel 2.4 `uid_t` used to be + 16bit, and programs compiled for that would hence assume that `(uid_t) -1` + is 65535. This UID is hence not usable either. The `nss-systemd` glibc NSS module will synthesize user database records for the UIDs 0 and 65534 if the system user database doesn't list them. This means -- 2.7.4