Let's extract common capability parsing code into a generic function
parse_capability_set() with a comprehensive set of unit tests.
We also replace usages of UINT64_MAX with CAP_MASK_UNSET where
applicable and replace the default value of CapabilityBoundingSet
with CAP_MASK_ALL which more clearly identifies that it is initialized
to all capabilities.
AI (copilot) was used to extract the generic function and write the
unit tests, with manual review and fixing afterwards to make sure
everything was correct.
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).
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.
Needed to implement support for RootHashSignature=/RootVerity=/RootHash=
and friends when going through mountfsd, for example with user units,
so that system and user units provide the same features at the same
level
Needed to implement support for RootHashSignature=/RootVerity=/RootHash=
and friends when going through mountfsd, for example with user units,
so that system and user units provide the same features at the same
level
Let's not leak details from src/shared and src/libsystemd into
src/basic, even though you can't actually do anything useful with
just forward declarations from src/shared.
The sd-forward.h header is put in src/libsystemd/sd-common as we
don't have a directory for shared internal headers for libsystemd
yet.
Let's also rename forward.h to basic-forward.h to keep things
self-explanatory.
https://github.com/systemd/systemd/pull/39168 made verity sharing
opt-in, and enabled it for system services.
Also enable it for user services for RootImage/etc, and for nspawn, for
the same reasons.
Just like RootImage=, ExtensionImages= etc, nspawn can make use of
this to save a lot of time when starting containers that use an already
open image, since the default was changed to disabled.
Follow-up for 57d1ceffb3
Previously, we'd take the image policy only into consideration when
dissecting the mage, but for the unlock/verity step we'd go via best
effort. Change that. This means we can now enforce policies such as
activating by root hash only even if a signature exists and similar.
Also, introduce a separate error code if we try to unlock a Verity
volume but have no root hash. Previously we'd return ENOKEY for that,
exactly like we do for encrypted volumes where we have no passparse. The
interctive unlock loop dissected_image_decrypt_interactively() is
otherwise very confused and will ask for a root hash, which makes no
sense. Hence use two distinct errors for this.
Let's make sure each container run by unpriv users is known by both
instances. Making it known by the host instance ensures it is resovlable
by nss-myhostname (and various other tools), but making it known by the
per-user instance means the user can fully manage it on their own.
This simplifies the code a bit too, i.e. we always allocate a scope
ourselves now, and just register it, instead of letting machined do that
under some circumstances. THere's little value in that and it simplifies
things for us quite a bit.
Current methods take a numeric PID, but we know that is unreliable for
the usual reasons. Add variants that take a PIDFD instead, or a
PID + PIDFDID combination for remote users.
`runtime_bus` is only used if `!arg_keep_unit`.
`system_bus` is additionally used if `arg_register`.
So for `!arg_register && arg_keep_unit`, none of them should be
necessary, and nspawn should be able to work without any D-Bus
connections.
Fixes https://github.com/systemd/systemd/issues/39044
Follow-up for f2f26f1527
Commit d7bea6b6 ("nspawn: introduce an option for specifying network
namespace path") already did most of the work here enabling a command
line option for specifying the namespace path for a given container.
Someone even took care of the merging code in merge_settings as though
this already worked. All that's then needed is to add a line to the
nspawn-gperf.gperf file to actually enable being able to specify
NamespacePath from nspawn files as well.
This greatly simplifies how we configure nspawn containers by being able
to give all the options we need in .nspawn files instead of needing to
also use command line parameters.
Closes: #27188
Even if there's no uid shift, we still won't be able to bind to privileged
ports in the host network namespace, so drop the capability regardless of
whether we have a uid shift or not.
Aside from the usual boilerplate of moving the shared logic to shared/,
we also rework the implementation of --bind-user= to be similar to what
we'll do in systemd-vmspawn. Instead of messing with the nspawn container
user namespace, we use idmapped mounts to map the user's home directory on
the host to the mapped uid in the container.
Ideally we'd also use the "userdb.transient" credentials to provision the
user records, but this would only work for booted containers, whereas the
current logic works for non-booted containers as well.
Aside from being similar to how we'll implement --bind-user= in vmspawn,
using idmapped mounts also allows supporting --bind-user= without having to
use --private-users=.
Yu Watanabe
Daan De Meyer
Lennart Poettering
Daniel Hast
Luca Boccassi
Luca Boccassi
David Tardon
n0099
Aleksandr Mezin
Alan Brady