From dfdaf9f2aa81815599d653cafd606100bfdfff95 Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Tue, 15 Feb 2022 22:40:34 +0100 Subject: [PATCH] NEWS: update excerpt on container UID/GID mappings --- NEWS | 45 +++++++++++++++++++++++++++++++++------------ 1 file changed, 33 insertions(+), 12 deletions(-) diff --git a/NEWS b/NEWS index 1dfefd3c0dc..ab6e61a1e46 100644 --- a/NEWS +++ b/NEWS @@ -12,18 +12,39 @@ CHANGES WITH 251: * Services with Restart=always and a failing ExecCondition= will no longer be restarted, to bring ExecCondition= in line with Condition*= settings. - * In v250 systemd-homed started making use of UID mapped mounts for the - home areas if the kernel and used file system support it. Files are - now internally owned by the "nobody" user (i.e. the user typically - used for indicating "this ownership is not mapped"), and dynamically - mapped to the UID used locally on the system via the UID mapping - mount logic of recent kernels. - In the current implementation systemd-homed only maps a limited - number of UIDs and GIDs making it impossible to run unprivileged - containers that want to map a full POSIX compliant UID and GID range - with their rootfs located within the systemd-homed managed home area. - This will be fixed in subsequent releases. See - https://github.com/systemd/systemd/pull/22239 for a proposal. + * Starting with v250 systemd-homed uses UID/GID mapping on the mounts + of activated home directories it manages (if the kernel and selected + file systems support it). So far it mapped three UID ranges: the + range from 0…60000, the user's own UID, and the range 60514…65534, + leaving everything else unmapped (in other words, the 16bit UID range + is mapped almost fully, with the exception of the UID subrange used + for systemd-homed users, with one exception from that: the user's own + UID). Unmapped UIDs may not be used for file ownership in the home + dirctory — any chown() attempts with them will fail. With this + release a fourth range is added to these mappings: + 524288…1879048191. This range is the UID range intended for container + uses, see: + + https://systemd.io/UIDS-GIDS + + This range may be used for container managers that place container OS + trees in the home directory (which is a questionable approach, for + quota, permission, SUID handling and network file system + compatibility reasons, but nonetheless apparently commonplace). Note + that this mapping is mapped 1:1 in a pass-through fashion, i.e. the + UID assignments from the range are not managed or mapped by + `systemd-homed`, and must be managed with other mechanisms, in the + context of the local system. + + Typically, a better approach to user namespacing in relevant + container managers would be to leave container OS trees on disk at + UID offset 0, but then map them to a dynamically allocated runtime + UID range via another UID mount map at container invocation + time. That way user namespace UID ranges become strictly a runtime + concept, and do not leak into persistent file systems, persistent + user databases or persistent configuration, thus greatly simplifying + handling, and improving compatibility with home directories intended + to be portable like the ones managed by systemd-homed. CHANGES WITH 250: -- 2.47.3