Submounts will always be located further in the mountinfo file, so
when we're unmounting, iterating backwards is likely to be more
efficient than iterating forwards. It'll also reduce the amount of
EBUSY debug logging we'll get since we'll stop trying to unmount
parent mounts with submounts which will always fail with EBUSY.
Check whether the argument of the `--background` option of
`systemd-run`, `run0`, `systemd-nspawn`, `systemd-vmspawn`, and
`systemd-pty-forward` is either empty or looks like an ANSI color code,
and reject invalid values when parsing arguments.
We consider a string to look like an ANSI color code if it consists of
one or more sequences of ASCII digits separated by semicolons. This
permits every valid ANSI color code, and should reject anything that
results in garbled output.
Marking a whole directory tree OS image as read-only is difficult
privilege-wise, because so far we rely on the FS_IMMUTABLE_FL which is
not accessible to unpriv clients.
One fundamental place where we currently rely on marking images
read-only is for keeping pristine copies of the originally downloaded
image around, which we place in "hidden" image directories. This is
probably the most relevant usecase for the read-only flag. And moreover,
the only usecase for the hidden images are these read-only pristine
copies.
Hence, let's make this work reasonably in the unpriv case, and simply
imply the read-only flag for hidden images. This is strictly speaking a
change in behaviour, but effectively it shouldn't be, because for nspawn
containers that are executed we insist on names that are hostname
compatible, and hidden names aren't (because they start with a dot).
Previously, we'd first empty a dir, and then remove it. This works fine
as long as we have access to a dir. But in some cases (like for example
a foreign owned container tree) we might not have access to the dir, but
are still able to remove it (because it is empty, and in a dir we own).
Hence let's try that first. If it works, we do not need to enter the dir
(and thus fail).
Let's address #38672 comprehensively: let's avoid BLKRRPART as much as
we can, and always do careful userspace controlled, incremental updates
to the kernel partition tables.
This simply iterates through blkid's partition parsing, and turns it
into a BLKPG ioctls, adding, updating, removing partitions as necessary,
suppressing unnecessary changes. This has the major benefit that the
call becomes truly idempotent: if nothing changed then nothing is
removed/readed, like BLKRRPART is doing it.
This then ports over all code currently doing partition refreshing,
specifcially: udev, repart, and homed.
Fixes: #38672
udev's block device locking protocol has one pitfall not even the
example in the documentation got right so far (even though this is
explained in all detail above): udev's rescanning is only triggered when
an fd that is opened for writing is closed. This means that if a
separate locking fd is opened on a block device – one that is maintained
independently of the fd actually used for writing – it must be opened for
writing too, so that closing the lock definitely triggers a rescan. This
matters in cases where the lock fd is kept for longer than the fd used
for writing to disk. (Because otherwise udev might get the
IN_CLOSE_WRITE event, but when it tries to rescan will find the device
locked, and never retry because no IN_CLOSE_WRITE is triggred anymore.)
Let's fix that across the codebase, at 4 places:
1. in makefs (a lock fd is kept, and mkfs then invoked as child, which
uses a different fd, and the lock fd is closed only once the child
died)
2. in udevadm lock (embarassing!): which is intended to be used to wrap tools
that modify disk contents, very similar to the makefs case. The lock
is also kept until after the tool exited.
3. In storagetm: the kernel nvme-tcp layer writes to the device
directly, we just keep a lock fd.
4. the example in BLOCK_DEVICE_LOCKING.md
This is a flags type and a flag function argument, let's name it in
plural, because it allows many flags combinations. Internally, the
implementation already used plural, but let's fix the prototypes too.
See the second commit for details.
I think we might want to apply the same treatment to nss and pam
modules. Asserting in such "plugin code" seems iffy. But this PR doesn't
change those in any way.
Previously, when compiled in developer mode, a call into libsystemd with
invalid parameters would result in an abort. This means that it's effectively
impossible to install such libsystemd in a normal system, since various
third-party programs may now abort. A shared library should generally never
abort or exit the calling program.
In python-systemd, the test suite calls into libsystemd, to check if the proper
return values are received and propagated through the Python wrappers.
Obviously with libsystemd compiled from git, the test suite now fails
in a nasty way.
So rework the code to set assert_return_is_critical similarly to how we handle
mempool enablement: the function that returns true is declared as a week
symbol, and we "opt in" by linking a file that provides the function in
libsystemd-shared. Effectively, libsystemd and libudev always have
assert_return_is_critical==false, and our binaries and modules enable it
conditionally.
When invoked unprivileged, let's use a transiently allocated userns, so
that we can properly untar UIDs/GIDs so that the trees appear owned by
the foreign UID/GID range.
Let's introduce a single helper that determines where to download images
to, taking all three primary parameters into account: the image class,
the runtime scope and whether to do runtime or persistency.
Then port everything over to this.
This not only cleans things up, but makes sure the importd backends
actually properly can deal with per-user downloads, as before we never
took the runtime scope into account for determining download location.
When operating in unprivileged mode we might not be able to execute the
necessary operations to make a disk image read-only (because
FS_IMMUTABEL_FL needs privs for example), and syncing (because for that
we might need to open the root inode, but that might not be possible
from the outside).
Let's deal with that by making these operation optional: if they work
great, if not they don't.
Sometimes it's quite useful to pin a source dir via an fd, as well as a
target dir the same way, and then ask copy_tree_at_full() to copy the
contents from one to the other. Make this possible, by allowing 'to' be
NULL. (Previously, it had to be non-NULL, i.e. the function would always
create a new dir, no matter what.)
Note that we only support that for dir inodes.
By giving priority to --background= we prevent users from opting
out of coloring if an explicit color is chosen by a tool wrapping
one of our own tools. Instead, let's give priority to the environment
variable, so that even if our tools are wrapped by another tool with
a different background, users can still opt out of coloring just by
setting the environment variable, which has a high chance of being
forwarded to the invocation of our own tools which makes it easy to
use to disable color tinting globally if requested by the user.
Daan De Meyer
Lennart Poettering
Yu Watanabe
Daniel Hast
Zbigniew Jędrzejewski-Szmek
Mike Yuan
Ivan Kruglov
nkraetzschmar