system/systemd
system/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd synced 2024-07-23 19:25:39 +00:00
Code Issues Actions 7 Packages Projects Releases Wiki Activity

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
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: