E.g. sd_device object of network interface 'hoge!foo' has sysname 'hoge/foo'.
So, previously udevd assigned 'hoge/foo' rather than 'hoge!foo' to ID_NET_NAME,
hence even when renaming is not requested, such interface was renamed to 'hoge_foo'
(note '/' cannot be used in network interface name, hence escaped to underbar).
We have RestartMaxDelaySec= + RestartSteps= to exponentially increase
auto restart durations, but it currently cannot be reset by the service
itself, which makes it sometimes awkward to use. A typical pattern
in real life is that a service was once down (e.g. due to temporary
network interruption) and multiple restarts were attempted. Then,
future restarts would always wait for increated amount of time based on
RestartMaxDelaySec=, even after the original problem got resolved.
Such "persistence" could result in longer unavailablity than there
should be for failures that come later.
(C.f. https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdResettingUnitBackoff)
Let's introduce a new sd_notify() notification for resetting the restart
counter. There were discussions about making this timer-based, but I think
it's more flexible to leave the decision-making to the service. This enables
them to do a combination of N successful requests + uptime check for instance.
- bump the requred minimum version of meson to 0.62.0,
- use install_symlink(), which is supported since meson-0.61.0,
- use more features provided by newer meson with careful
conditionalization.
Follow-up for 8442ac9c02.
Closes#35967.
Now our baseline of meson is 0.62, hence install_symlink() can be used.
Note, install_symlink() implies install_emptydir() for specified
install_dir. Hence, this also drops several unnecessary
install_emptydir() calls.
Note, the function currently does not support 'relative' and 'force' flags,
so several 'ln -frsT' inline calls cannot be replaced.
Support including the data that was signed inside the PKCS#7 signature.
This creates a self-contained file where the signature of the data can
be verified without any other information, since the file contains the
data, signature, and certificate (which contains the public key used for
the signing).
One use case of this is IPE which requires a PKCS#7 signature that is
not "detached", i.e. includes the IPE configuration that has been
signed.
This also slightly adjusts the test case to use the x509 certificate
inside the PKCS#7 signature instead of supplying it externally during
verification.
Let's define a clean way how we can reestablish file watches in homed.
This is a relevant in case we overmount /home/ as a whole. It's very
useful for our testcase in particular.
Currently homed scans /home/ via inotify for new .home + .homedir/
popping up to register as local users. Let's also add an explicit way to
request this form of "adoption": a bus call that takes a path and that
makes a home dir activatable locally.
(Usecase: you cross boot between two systems – let's say your traditional
fedora and your ParticleOS – and want to use the same homedir from both:
simply mount the /home dir from the other somewhere, and then hit
"homectl adopt /somewhere/lennart.home" and you have the user locally
too).
When services start up they might query for passwords, or issue polkit
requests. Hence it makese sense to run the password query agent and
polkit agent from systemd-run. We already ran the polkit agent, this
also ensures we run the password query agent.
There's one tweak to the story though: running the agents and the pty
forwarder concurrently is messy, since they both try to read from stdin
(one potentially, the other definitely). Hence, let's time the agents
properly: invoke them when we initialize, but stop them once the start
job for the unit we are supposed to run is complete, and only then run
the pty forwarder.
With this in place, the following series of commands starts to work
really nicely (which previously deadlocked):
# homectl create foobar
# run0 -u foobar
What happens in the background in run0 is this: a new session is invoked
for "foobar", which pulls in the user@.service instance for the user.
That user@.service instance will need to unlock the homedir first. Since
8af1b296cb this will happen via the askpw
logic. With this commit here this prompt will now be shown by run0. Once
the password is entered the directory is unlocked and the real session
begins. Nice!
This new behaviour is conditioned behind --pty-late (distinct from the
existing --pty switches). For systemd-run we will never enable this mode
by default, for compat with command lines that use ExecStartPre=
(because we won't process the pty anymore during that command) For
run0 however this changes the default to --pty-late (unless
--no-ask-password is specified). This reflects the fact that run0 is
more of an interctive tool and unlikely to be used in more complex
service start-up situations with ExecStartPre= and suchlike.
This also merges JobDoneContext into RunContext, since it doesn't really
make sense to have two contexts around to communicate between outer
stack frame and event handlers. Let's just have one, and pass it around
to all handlers the same way. In particular as we should delay exit only
until both the unit's job is complete *and* in case of --wait the unit
is exited, one of the two should not suffice.
This introduces a bunch of facilities:
1. The factory-reset.target unit that requests a factory reset is now
complemented by factory-reset-now.target that executes it at next
boot.
2. This latter is added to the initial transaction via the new trivial
systemd-factory-reset-generator.
3. A tool systemd-factory-reset has been added to query, request,
cancel, complete factory reset operations (via EFI variables). Two of
these are wrapped into units that are plugged into
factory-reset.target and factory-reset-now.target respectively. The
tool also provides a simple Varlink API.
This should make things a lot cleaner, and both be useful as explicit
implementation on UEFI, and as template + hookpoints for alternative
implementations on non-UEFI.
It's sometimes very useful to be able to terminate a container quickly
but cleanly while talking to it. Introduce a hotkey for that: ^]^]p for
powering it off. In similar style add ^]^]r for rebooting it.
This reverts commit b6a2df6307.
The functionality is entirely redundant, we already have
sd_json_variant_filter() which does the same, and is in fact even more
powerful, since it takes a list instead of a single field to remove.
This delegates one or more namespaces to the service. Concretely,
this setting influences in which order we unshare namespaces. Delegated
namespaces are unshared *after* the user namespace is unshared. Other
namespaces are unshared *before* the user namespace is unshared.
Fixes#35369
In 2cc58b6c8a and related we established
rules on naming certs/public-keys/private-keys:
*-public-key.pem
*-private-key.pem
*-certificate.pem
Let's follow that naming in repart's man page too.
Let's move pam_systemd_home before pam_unix in the authentication hook.
Since a while we are exposing shadow entries for homed log entries via
NSS. This means that pam_unix now potentially has enough data for
authenticating a user on its own, without letting pam_systemd_home do
that. This is superficially OK, but also means that authentication will
always go via password, even if pkcs11/fido2 is registered.
Let's move this around, but be careful about it: let's list the precise
errors which we think are enough to terminating further PAM processing,
so that pam_unix comes into control in all cases where it's not clear
that pam_systemd_home owns the user record.
This previously wasn't visible to me, because on Fedora until authselect
1.5.1 (released earleir this year) the NSS shadow stuff was not enabled.
This does the same also for the "account" stack, except that the order
there already was as we want it.
Finally, shorten the account stack, by just requiring pam_unix.so and
dropping pam_permit.so, because it doesn't really serve much purpose
(and Fedora doesn't use it by default either.)
This has been depracted since v254 (2023). Let's kill it for
good now, it has been long enough with 2y. Noone has shown up who wants
to keep it. And given it doesn't work in SB world anyway, and is not
measured is quite problematic security wise.
Expose /sys/class/dmi/id/chassis_asset_tag in varlink/dbus commonly used
by companies to track inventory such as laptops.
On desktops and other products the `chassis_asset_tag` can contain
rubbish similar to product_name/product_vendor.
Closes: #36442