This improves operation in unprivileged userns environments, where
unpriv user code might invoke a container with a delegated userns UID
range, and thus ends up with a subcgroup owned by another UID. With this
patch any user is always allowed to remove their own cgroups even if it
has subcgroups owned by other users.
This removes a DoS of sorts, and enforces the rule that users strictly
own everything below cgroups they own.
This is a test for the previous commits: we create an unpriv, delegated cgroup in
--user mode, then create a subcgroup that is owned by some other user
(to mimic the case where an unpriv user got a userns with delegated UIDs
assigned), and then try to stop the unit. traditionally this would fail,
because our unpriv systemd --user instance can't remove the subcrroup
owned by someone else. With the earlier patches this is addressed.
When running unprivileged containers, we run into a scenario where an
unpriv owned cgroup has a subcgroup delegated to another user (i.e. the
container's own UIDs). When the owner of that cgroup dies without
cleaning it up then the unpriv service manager might encounter a cgroup
it cannot delete anymore.
Let's address that: let's expose a method call on the service manager
(primarly in PID1) that can be used to delete a subcgroup of a unit one
owns. This would then allow the unpriv service manager to ask the priv
service manager to get rid of such a cgroup.
This commit only adds the method call, the next commit then adds the
code that makes use of this.
Let's liberalize process migration a bit. Previously, PID 1 would only
allow you to move processes into your own cgroups, if those processes
are owned by you too. This is now slightly relaxed: it's now also OK if
the processes are in a userns owned by you.
This makes process migration more useful in context of unpriv userns.
Avoid showing the files on the ESP (i.e. a FAT formatted volume) as
executable by removing the execute permission from them.
IMO this makes the colored output of `ls` more sensible since the file
system will be mounted with `noexec` anyway.
Add a `fstype_can_fmask_dmask` function that checks if a file system
type can use the `fmask` and `dmask` mount options.
This replaces `fstype_can_umask` since it was only used in
`partition_pick_mount_options` which only cares about the file system
support for fmask & dmask now.
It somewhat reduces the coverage of the feature since there are more file
systems that support umask as opposed to those supporting dmask & dmask,
but it should not be much of an issue since fmask & dmask are supported
by vfat, exfat and ntfs3.
This makes sure the the codepath that derives an nsfd from a pid works
the same for the pidfd case and the non-pidfd case: if we can verify
that /proc/ is mounted but the /proc/$PID/ns/ files are missing, we can
assume the ns type is not supported by the kernel. Hence return the same
ENOPKG error in this case as we already do in the pidfd ioctl based
codepath.
As requested, a list of kernel version to feature mapping
for kernels older than minimum baseline is also included,
in order to ease potential backport work.
Poll fds associated with the bus instead of hardcoding stdin/stdout.
This is consequential under socket activation, when the provided fd
should be used instead of stdin/stdout.
The package is logistically separated, as the rpm sources conflict from Fedora
conflict with the rpm sources from SUSE (some files have the same name and
location but different, incompatible content), so Fedora builds can't be
triggered from the same package. The result is the same.
This is something I think we should have added a long time ago: a
flavour of open() that safely ensures the inode we are opening is a
regular file, before we open it. It does this by means of pinning the
inode via O_PATH first, and after verification actually opening it.
This ports some code over to this, but sooner or later we should
probably use this a lot more, so that we don't accidentally open weird
stuff such as device nodes or pipes, where we should not.
This corrects the closing sequence for the ConEmu progress reporting
final sequence. We by mistake sent two final ;;, where only one was
expected. The terminals I tested this with didn't care, but Ghostty
apparently does. Let's fix things and generate the closing sequence as
per doc:
https://conemu.github.io/en/AnsiEscapeCodes.html#ConEmu_specific_OSC
Lennart Poettering
Daan De Meyer
Mike Yuan
nl6720
Luca Boccassi
Tobias Klauser
Jacob McNamee
Yu Watanabe
