diff options
author | Lennart Poettering <lennart@poettering.net> | 2022-02-15 22:40:34 +0100 |
---|---|---|
committer | Lennart Poettering <lennart@poettering.net> | 2022-02-16 13:37:01 +0100 |
commit | dfdaf9f2aa81815599d653cafd606100bfdfff95 (patch) | |
tree | 62e7b75960fb5d08eb4fd757ef4e9e9022a84b08 /NEWS | |
parent | 9df83788c1f19eca2f0ffe051d0e2b99e5cc77a8 (diff) | |
download | systemd-dfdaf9f2aa81815599d653cafd606100bfdfff95.tar.gz |
NEWS: update excerpt on container UID/GID mappings
Diffstat (limited to 'NEWS')
-rw-r--r-- | NEWS | 45 |
1 files changed, 33 insertions, 12 deletions
@@ -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: |