So far, we supported two modes:
1. when running unpriv we'd get the mounts from mountfsd, and the userns
from nsresourced
2. when running priv we'd do the mounts/userns ourselves
This untangles this a bit, so that we can also use mountfsd/nsresourced
when running privilged.
I think this is generally a bit nicer, and probably something we should
switch to entirely one day, as it reduces the variety of codepaths.
With this patch the default behaviour remains unchanged, but by
selecting the new "managed" option for --private-users= the codepaths
via mountfsd/nsresourced can be explicitly requested even when running
with privs.
This is mostly just reworks that we check for arg_userns_mode !=
USER_NAMESPACE_MANAGED rather than arg_privileged for a number of
codepaths, but requires more fixes, too. The devil is in the details.
This adds a new "foreign" value to --private-users-ownership= which is a
lot like "map", but maps from the host's foreign UID range rather than from the
host's 0.
(This has nothing much to do with making unprivileged directory-based
containers work, it's just very handy that we can run privileged
contains with such a mapping too, with an easy switch)
This simply calls into mountfsd to acquire the root mount and uses it as
root for the container.
Note that this also makes one more change: previously we ran containers
directory off their backing directory. Except when we didn't, and there
were a variety of exceptions: if we had no privs, if we ran off a disk
image, if the directory was the host's root dir, and some others.
This simplifies the logic a bit: we now simply always create a temporary
directory in /tmp/ and bind mount everything there, in all code paths.
This simplifies our code a bit. After all, in order to control
propagation we need to turn the root into a mount point anyway, hence we
might just do it at one place for all cases.
systemd-mountfsd so far provided a MountImage() API call for mounting a
disk image and returning a set of mount fds. This complements the API
with a new MountDirectory() API call, that operates on a directory
instead of an image file. Now, what makes this interesting is that it
applies an idmapping from the foreign UID range to the provided target
userns – and in which case unpriveleged operation is allowed (well,
under some conditions: in particular the client must own a parent dir of
the provided path).
This allows container managers to run fully unprivileged from
directories – as long as those directories are owned by the foreign UID
range. Basic operation is like this:
1. acquire a transient userns from systemd-nsresourced with 64K users
2. ask systemd-mountfsd for an idmapped mount of the container dir
matching that userns
3. join the userns and bind the mount fd as root.
Note that we have to drop various sandboxing knobs from the mountfsd
service file for this to work, since the kernel's security checks that
try to ensure than an obstructed /proc/ cannot be circumvented via
mounting a new procfs will otherwise prohibit mountfsd to duplicate the
mounts properly.
Recently, we introduce 'clock' system group, and set it for rtc/ptp
devices. See af96ccfc24.
However, if non-system group with the same name is already exist,
previously the devices were owned by the non-system group. That may
possibly happen on updating systemd.
Let's avoid accidentally devices being owned by non-system user/group.
Previously, when an unknown or invalid user/group is specified,
a token was installed with UID_INVALID/GID_INVALID. That's not only
meaningless in most cases, but also clears previous assignment,
if multiple OWNER=/GROUP= token exist for the same device, e.g.
KERNEL=="sda", GROUP="disk"
KERNEL=="sda", GROUP="nonexistentuser"
This makes when an unknown user/group is specified, the line will be
ignored. Hence, in the above example, the device will be owned by the
group "disk".
This drops -ENOENT error check for get_user_creds()/get_group_creds(),
as nowadays they always return -ESRCH when the specified user/groups
cannot be found.
This also adds short comments for NULL arguments.
File system modules should be something the kernel can autoload
automatically, and according to my testing that works fine, hence let's
drop the explicit deps, in particular as systems usually stick to one fs
for these things, not both.
I inquired bluca about the reason to add it, and didn't remember
anymore, and was fine with me removing this. So let's remove this for
now, should issues arise we can revert this.
mountfsd is supposed to be available during early boot aleady, before
systemd-tmpfiles-setup-dev-early.service completes, hence make sure
loopback devices and DM already work before that.
As suggested by yuwata here:
https://github.com/systemd/systemd/pull/35685#issuecomment-2608157569
Previously, if e.g. DRIVER=foo is specified in uevent file, the value is
only saved as property, but was not set to sd_device.driver.
That was inconsistent to the case when a device is created through
netlink uevent.
Let's always set when we get e.g. sd_device.driver when DRIVER=foo
from both uevent file and netlink uevent.
This makes sd_device_get_sysattr_value()/sd_device_set_sysattr_value()
refuse to read/write files outside of sysfs for safety.
Also this makes
- use chase() to resolve and open the symlink in path to sysfs attribute,
- use delete_trailing_chars(),
- include error code in cache entry, so we can cache more error cases,
- refuse caching value written to uevent file of any devices, i.e.
sd_device_set_sysattr_value(dev, "../uevent", "add") will also not
cache the value "add".
Also, when a filename is specified, also search udev rules file in
udev/rules.d directories.
This also refuses non-existing files, and file neither nor a regular
nor a directory, e.g. /dev/null.
- set destructors to catalog_hash_ops,
- acquire OrderedHashmap when necessary,
- gracefully handle NULL catalog directories and output stream,
- rename function output arguments,
- add many many assertions,
- use RET_GATHER().
