We already check existences of quotaon in quotaon@.service and
quotacheck in systemd-quotacheck@.service.
Let's also check if kmod command exists.
Closes#38179.
Follow-up for 495e75ed5c
The mentioned commit switched scope unit's "pids" deserialization
to call unit_watch_pid() already, meaning all later invocations
in scope_coldplug() are no-op. Remove the cruft altogether.
Systemd-stub supports loading addons, credentials, system and
configuration
extensions from ESP and while addons and credentials can be both global
and
per-UKI, sysext/confext are only per-UKI.
Add support for global sysext/confext to systemd-stub/systemd-sysext.
Fixes#37993
This adds missing glue to reasonably allow unpriv users VMs/containers
to register with the system machined.
This primarily adds two things:
1. machined can now properly track VMs/containers residing in subcgroups
of units, because that's effectively what happens for per-user
VMs/containers: they are placed below the system unit `user@….service`
in some user unit.
2. machines registered with machined now have an owning UID: users can
operate on their own machines withour re-authentication, but not on
others.
Note that this is only a first step regarding machined's hookup of
nspawn/vmspawn in the long run for unpriv operation.
I think eventually we should make it so that there's both a per-user and
a per-system machined instance (so far, and even with this PR there's
still one per-system instance), and per-user containers/VMs would
registering with *both*. Having two instances makes sense I think,
because it would mean we can make machined reasonably manage the
per-user image discovery, and also do the per-system network/hostname
handling.
Let's add a superficial test for the code we just added: spawn a
container unpriv, make sure registration fully worked, then kill it via
machinectl, to ensure it all works properly.
Not too thorough but a good start.
vmspawn systems might take quite a while to boot in particular if they
go through uefi and wait for a network lease. Hence let's increase the
start timeout to 2min (from 45s). We'll do that for both nspawn and
vmspawn, even though the UEFI thing certainly doesn't apply there (but
the DHCP thing still does).
This mimics the switch of the same name from nspawn: it controls whether
we expect a READY=1 message from the payload or not. Previously we'd
always expect that. This makes it configurable, just like it is in
nspawn.
There's one fundamental difference in behaviour though: in nspawn it
defaults to off, in vmspawn it defaults to on. (for historical reasons,
ideally we'd default to on in both cases, but changing is quite a compat
break both directly and indirectly: since timeouts might get triggered).
This beefs up the cgroup logic, adding --slice=, --property= to vmspawn
the same way it already exists in nspawn.
There are a bunch of differences though: we don't delegate the cgroup
access in the allocated unit (since qemu wouldn't need that), and we do
registration via varlink not dbus. Hence, while this follows a similar
logic now, it differs in a lot of details.
This makes in particular one change: when invoked on the command line
we'll only add the qemu instance to the allocated scope, not the vmspawn
process itself (this follows more closely how nspawn does this where
only the container payload has its scope, not nspawn itself). This is
quite tricky to implement: unlike in nspawn we have auxiliary services
to start, with depencies to the scope. This means we need to start the
scope early, so that we know the scope's name. But the command line to
invoke is only assembled from the data we learn about the auxiliary
services, hence much later. To addres we'll now fork off the child that
eventually will become early, then move it to a scope, prepare the
cmdline and then very late send the cmdline (and the fds we want to
pass) to the prepared child, which then execs it.
Just like in nspawn, there's a chance we need to PK authenticate the
registration, hence let's spawn off the agent for that during that
phase, and terminate it once we don't need it anymore.
Let's also send out a STATUS= message when we get READY=1 if it didn't
come with a STATUS= message itself.
Also, let's initially say the container is "started", and only once the
READY=1 is seen claim it was "running".
This cleans up allocation of a scope unit for the container: when
invoked in user context we'll now allocate a scope through the per-user
service manager instead of the per-system manager. This makes a ton more
sense, since it's the user that invokes things after all. And given that
machined now can register containers in the user manager there's nothing
stopping us to clean this up.
Note that this means we'll connect to two busses if run unpriv: once to
the per-user bus to allocate the scope unit, and once to the per-system
bus to register it with machined.
So far, machined strictly tracked the "leader" process of a machine,
i.e. the topmost process that is actually the payload of the machine.
Its runtime also defines the runtime of the machine, and we can directly
interact with it if we need to, for example for containers to join the
namespaces, or kill it.
Let's optionally also track the "supervisor" process of a machine, i.e.
the host process that manages the payload if there is one. This is
generally useful info, but in particular is useful because we might need
to communicate with it to shutdown a machine without cooperation of the
payload. Traditionally we did this by simply stopping the unit of the
machine, but this is not doable now that the host machined can be used
to track per-user machines.
In the long run we probably want a more bespoke protocol between
machined and supervisors (so that we can execute other commands too,
such as request cooperative reboots/shutdowns), but that's for later.
Some environments call the concept "monitor" rather than "supervisor" or
use some other term. I stuck to "supervisor" because nspawn uses this,
and ultimately one name is as good as another.
And of course, in other implementations of VM managers of containers
there might not be a single process tracking each VM/container. Because
of this, the concept of a supervisor is optional.
The difference between these two operations are large: one is relatively
superficial: for "registration" all resources remain associated with the
invoking user, only the cgroup is reported to machined which then keeps
track of the machine, too. OTOH "creation" a scope is allocated in
system context, hence the invoked code will be owned by the system, and
its resource usage charged against the system.
Hence, use two distinct polkit actions for this, so that we can relax
access to registration, but keep access to creation tough.
Now that unpriv clients can register machines, let's register their UID
too. This allows us to do two things:
1. make sure the scope delegation is assigned to the right UID (so that
the unpriv user can actually create cgroups below the delegated
scope)
2. permit certain types of access (i.e. killing, or pty access) to the
client without auth if it owns the machine.
We also run in a VM if we're not running as root, yet we weren't
checking this when deciding whether to pass --capability=CAP_BPF or
not. Let's fix that.
Follow up for 9554ac3052
Fixes a bug in a4a6e21673.
Fixes the following memleak:
```
$ sudo valgrind --leak-check=full build/udevadm cat /usr/lib/udev/rules.d
==3975939==
==3975939== HEAP SUMMARY:
==3975939== in use at exit: 640 bytes in 1 blocks
==3975939== total heap usage: 7,657 allocs, 7,656 frees, 964,328 bytes allocated
==3975939==
==3975939== 640 bytes in 1 blocks are definitely lost in loss record 1 of 1
==3975939== at 0x4841866: malloc (vg_replace_malloc.c:446)
==3975939== by 0x4ACA71F: malloc_multiply (alloc-util.h:92)
==3975939== by 0x4ACF988: _hashmap_dump_entries_sorted (hashmap.c:2167)
==3975939== by 0x4ACFC76: _hashmap_dump_sorted (hashmap.c:2209)
==3975939== by 0x4AA60A4: hashmap_dump_sorted (hashmap.h:311)
==3975939== by 0x4AA9077: dump_files (conf-files.c:397)
==3975939== by 0x4AAA14E: conf_files_list_strv_full (conf-files.c:596)
==3975939== by 0x42426A: search_rules_file (udevadm-util.c:301)
==3975939== by 0x424768: search_rules_files (udevadm-util.c:334)
==3975939== by 0x41287D: cat_main (udevadm-cat.c:110)
==3975939== by 0x4A7B911: dispatch_verb (verbs.c:139)
==3975939== by 0x427272: udevadm_main (udevadm.c:121)
==3975939==
==3975939== LEAK SUMMARY:
==3975939== definitely lost: 640 bytes in 1 blocks
==3975939== indirectly lost: 0 bytes in 0 blocks
==3975939== possibly lost: 0 bytes in 0 blocks
==3975939== still reachable: 0 bytes in 0 blocks
==3975939== suppressed: 0 bytes in 0 blocks
==3975939==
==3975939== For lists of detected and suppressed errors, rerun with: -s
==3975939== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
```
This renames and splits link_may_have_ipv6ll() into
link_ipv6ll_enabled_harder() and link_multicast_enabled(),
as they are completely irrelevant to each other.
Also, this makes link_ipv6ll_enabled_harder() work non-Wireguard
interfaces.
Load global sysext/confext from /.extra/global_{sysext,confext} which
systemd-stub puts there from ESP/loader/credentials/*.{sysext,confext}.raw.
Global extensions are handled the exact same way as per-UKI ones.
Systemd-stub support loading addons, credentials, system and configuration
extensions from ESP and while addons and credentials can be both global and
per-UKI, sysext/confext are only per-UKI.
Add support for loading ESP/loader/credentials/*.{sysext,confext}.raw to
systemd-stub.
Note: for backwards compatibility reasons, per-UKI sysexts can also be
*.raw (not only *.sysext.raw) but as global extensions are new, there's
no need to bring this legacy there.
Google Compute Engine are not only virtual but can be also physical
machines. Therefore checking only the dmi is not enough to detect if it
is a virtual machine. Therefore systemd-detect-virt return "google"
instead of "none" in c3-highcpu-metal machine.
SMBIOS will not help us to make the difference as for EC2 machines.
However, GCE use KVM hypervisor for these VM, we can use this
information to detect virtualization. [0]
Issue and changes has been tested on SUSE SLE-15-SP7 images with
systemd-254 for both GCE, bare-metal and VM.
[0] -
https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervisor-at-google-cloud-security-in-plaintext
Backticks are good in markdown files, where they signify text to be rendered
with a mono-space font. But our text files doesn't use markdown, and backticks
are just a particularly bad type of quote (ugly, assymetrical, with a special
significance in shell context). Update older NEWS entries to not use them.
