shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2025-02-09 13:57:42 +03:00
Code

NEWS: update excerpt on container UID/GID mappings

Browse Source
This commit is contained in:
Lennart Poettering 2022-02-15 22:40:34 +01:00
parent 9df83788c1
commit dfdaf9f2aa
1 changed files with 33 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
NEWS
View File

@ -12,18 +12,39 @@ CHANGES WITH 251:
* Services with Restart=always and a failing ExecCondition= will no longer * Services with Restart=always and a failing ExecCondition= will no longer
be restarted, to bring ExecCondition= in line with Condition*= settings. be restarted, to bring ExecCondition= in line with Condition*= settings.
* In v250 systemd-homed started making use of UID mapped mounts for the * Starting with v250 systemd-homed uses UID/GID mapping on the mounts
home areas if the kernel and used file system support it. Files are of activated home directories it manages (if the kernel and selected
now internally owned by the "nobody" user (i.e. the user typically file systems support it). So far it mapped three UID ranges: the
used for indicating "this ownership is not mapped"), and dynamically range from 0…60000, the user's own UID, and the range 60514…65534,
mapped to the UID used locally on the system via the UID mapping leaving everything else unmapped (in other words, the 16bit UID range
mount logic of recent kernels. is mapped almost fully, with the exception of the UID subrange used
In the current implementation systemd-homed only maps a limited for systemd-homed users, with one exception from that: the user's own
number of UIDs and GIDs making it impossible to run unprivileged UID). Unmapped UIDs may not be used for file ownership in the home
containers that want to map a full POSIX compliant UID and GID range dirctory — any chown() attempts with them will fail. With this
with their rootfs located within the systemd-homed managed home area. release a fourth range is added to these mappings:
This will be fixed in subsequent releases. See 524288…1879048191. This range is the UID range intended for container
https://github.com/systemd/systemd/pull/22239 for a proposal. 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: CHANGES WITH 250: