This mimics what we do for systemd-cryptsetup@.service (see
src/shared/generator.c), and makes sense since repart might lock up the
root volume against a TPM, which ideally has its SRK already set up by
then.
More importantly though, this ensures that we ordered correctly after
tpm2.target (which systemd-tpm2-setup-early.service has a dependency
on), for systems where the TPM drivers are not compiled into the kernel.
See: https://lists.freedesktop.org/archives/systemd-devel/2024-April/050201.html
This adds a small, socket-activated Varlink daemon that can delegate UID
ranges for user namespaces to clients asking for it.
The primary call is AllocateUserRange() where the user passes in an
uninitialized userns fd, which is then set up.
There are other calls that allow assigning a mount fd to a userns
allocated that way, to set up permissions for a cgroup subtree, and to
allocate a veth for such a user namespace.
Since the UID assignments are supposed to be transitive, i.e. not
permanent, care is taken to ensure that users cannot create inodes owned
by these UIDs, so that persistancy cannot be acquired. This is
implemented via a BPF-LSM module that ensures that any member of a
userns allocated that way cannot create files unless the mount it
operates on is owned by the userns itself, or is explicitly
allowelisted.
BPF LSM program with contributions from Alexei Starovoitov.
stale HibernateLocation EFI variable
Currently, if the HibernateLocation EFI variable exists,
but we failed to resume from it, the boot carries on
without clearing the stale variable. Therefore, the subsequent
boots would still be waiting for the device timeout,
unless the variable is purged manually.
There's no point to keep trying to resume after a successful
switch-root, because the hibernation image state
would have been invalidated by then. OTOH, we don't
want to clear the variable prematurely either,
i.e. in initrd, since if the resume device is the same
as root one, the boot won't succeed and the user might
be able to try resuming again. So, let's introduce a
unit that only runs after switch-root and clears the var.
Fixes#32021
Drop connections and caches and reload config from files, to allow
for low-interruptions updates, and hook up to the usual SIGHUP and
ExecReload=. Mark servers and services configured directly via D-Bus
so that they can be kept around, and only the configuration file
settings are dropped and reloaded.
Fixes https://github.com/systemd/systemd/issues/17503
Fixes https://github.com/systemd/systemd/issues/20604
c0aeff4b99 added this in one unit file, but the
same problem occurs here. (There are no other files where this would apply.)
I think we should solve this systematically somehow, but it's not clear how to
do that, so until we have that better solution, let's apply the manual solution
so that our units work as expected.
Now, networkd accesses the state directory through the file descriptor
passed from systemd-networkd-persistent-storage.service.
Hence, the networkd itself does not need to access the state directory
through its path, and we can use more stronger mode for ProtectSystem=.
Currently the associated units fail if full tpm support is not available
on the system. Similar to systemd-pcrextend, let's add a --graceful option
that exits gracefully if no full TPM support is detected and use it in both
units.
This new passive target is supposed to be pulled in by SSH
implementations and should be reached when remote SSH access is
possible. The idea is that this target can be used as indicator for
other components to determine if and when SSH access is possible.
One specific usecase for this is the new sd_notify() logic in PID 1 that
sends its own supervisor notifications whenever target units are
reached. This can be used to precisely schedule SSH connections from
host to VM/container, or just to identify systems where SSH is even
available.
"Starting Boot Control…" would be a fairly confusing message in the boot logs.
Use "… Service" to mirror what we have in other services like
systemd-{hostnamed,timedated,portabled,machined,…}.service.
We generally don't specify the protocol implementation in unit descriptions.
For journald, we have:
$ git grep Description 'units/*journald*'
units/systemd-journald-audit.socket:Description=Journal Audit Socket
units/systemd-journald-dev-log.socket:Description=Journal Socket (/dev/log)
units/systemd-journald-varlink@.socket:Description=Journal Varlink Socket for Namespace %i
units/systemd-journald.service.in:Description=Journal Service
units/systemd-journald.socket:Description=Journal Sockets
units/systemd-journald@.service.in:Description=Journal Service for Namespace %i
units/systemd-journald@.socket:Description=Journal Sockets for Namespace %i
so we need to keep "Varlink" in the name. But also use "Sockets" (plural)
for the "main" socket unit, since it opens multiple sockets.
I was looking at the logs in some bug and saw this:
Mar 13 15:55:12 fedora systemd[1]: systemd-pcrmachine.service - TPM2 PCR Machine ID Measurement was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
Mar 13 15:55:12 fedora systemd[1]: Starting systemd-remount-fs.service - Remount Root and Kernel File Systems...
Mar 13 15:55:12 fedora systemd[1]: systemd-tpm2-setup-early.service - TPM2 SRK Setup (Early) was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
This is overly technical, for most units we don't provide this level of
detail about the implementation. So retitle the units to be more accessible.
Also, the fact that it's a v. 2 of the TPM is not that important. We don't
support TPM 1.2, but computers without TPM v2 are getting rare. For other
units we don't advertise the version of hardware, and let's not do this here,
to reduce some complexity.
In mkosi, we've been having CI failures caused by
systemd-machine-id-commit.service timing out. Let's bump the timeout
for it and systemd-rfkill.service to 90s which we also use for other
oneshot services to avoid transient failures on slower systems.
ProtectSystem=full remounts /boot and/or /efi read-only, but that
may trigger automount for the paths and delay the service being started.
===
systemd[1]: boot.automount: Got automount request for /boot, triggered by 720 ((networkd))
===
The service does not need to access the paths, so let's hide them.
Follow-up for f90eb08627.
Fixes#31742.
Then, this introduces systemd-networkd-persistent-storage.service.
systemd-networkd.service is an early starting service. So, at the time
it is started, the persistent storage for the service may not be ready,
and we cannot use StateDirectory=systemd/network in
systemd-networkd.service.
The newly added systemd-networkd-persistent-storage.service creates the
state directory for networkd, and notify systemd-networkd that the
directory is usable.
Most of our kernel cmdline options use underscores as word separators in
kernel cmdline options, but there were some exceptions. Let's fix those,
and also use underscores.
Since our /proc/cmdline parsers don't distinguish between the two
characters anyway this should not break anything, but makes sure our own
codebase (and in particular docs and log messages) are internally
consistent.
This ensures that a user-specific blob directory exists in
/var/cache/systemd/homed for as long as the user exists, and gets
deleted if the user gets deleted.
It also advertises this blob directory via the user record, so that
clients can find and use it.
This commit adds a new way of forwarding journal messages - forwarding
over a socket.
The socket can be any of AF_INET, AF_INET6, AF_UNIUX or AF_VSOCK.
The address to connect to is retrieved from the "journald.forward_address" credential.
It can also be specified in systemd-journald's unit file with ForwardAddress=
Before #30884, the user state is tied to user@.service (user service
manager). However, #30884 introduced sessions that need no manager,
and we can no longer rely on that.
Consider the following situation:
1. A 'background-light' session '1' is created (i.e. no user service manager
is needed)
2. Session '1' scope unit pulls in user-runtime-dir@.service
3. Session '1' exits. A stop job is enqueued for user-runtime-dir@.service
due to StopWhenUnneeded=yes
4. At the same time, another session '2' which requires user manager is started.
However, session scope units have JobMode=fail, therefore the start job
for user-runtime-dir@.service that was pulled in by session '2' scope job
is deleted as it conflicts with the stop job.
We want session scope units to continue using JobMode=fail, but we still need
the dependencies to be started correctly, i.e. explicitly requested by logind
beforehand. Therefore, let's stop using StopWhenUnneeded=yes for
user-runtime-dir@.service, and track users' `started` and `stopping` state
based on that when user@.service is not needed. Then, for every invocation
of user_start(), we'll recheck if we need the service manager and start it
if so.
Also, the dependency type on user-runtime-dir@.service from user@.service
is upgraded to `BindsTo=`, in order to ensure that when logind stops the
former, the latter is stopped as well.
Let's make sure that user's cannot DoS services for other users so
easily, and enable MaxConnectionsPerSocket= by default for all of them.
Note that this is mostly paranoia for systemd-pcrextend.socket and
systemd-sysext.socket: the socket is only accessible to root anyway,
hence the accounting shouldn#t change anything. But this is just a
safety net, in preparation that we open up some functionality of these
services sooner or later.
Also= lists units which should be enabled/disabled together with the first unit.
But userdbd is independent of homed, we shouldn't e.g. disable it even if homed
is disabled.
