Merge pull request #29546 from poettering/run-invoc-id

run: output invocation ID when starting service and scope units

Merge pull request #29272 from enr0n/coredump-container

coredump: support forwarding coredumps to containers

mount-util: use mount beneath to replace previous namespace mount

Instead of mounting over, do an atomic swap using mount beneath, if
available. This way assets can be mounted again and again (e.g.:
updates) without leaking mounts.

Merge pull request #29548 from poettering/sysext-varlink

sysext: add a varlink IPC interface

Merge pull request #29562 from poettering/namespace-fuckup-fix

namespace: normalize memory management of mount list

update TODO

run: pin the unit we invoke continously while we are running

We read properties of the unit, hence it shouldn't be GC'ed as long as
we run. Hence, let's just set AddRef unconditionally for the units we
create.

run: output invocation ID when starting service and scope units

namespace: add // FIXME comments on some suplicate logging

@bluca thinks duplicate logging as a feature, hence simply mark these
log messages as // FIXME, but don't bother.

 namespace: downgrade log messages to LOG_DEBUG

almost all code in namespace.c only logs at debug level as it is
"library-like" code. But there are some outliers. Adjust them to match
the rest of the code

(Well, there are some left)

namespace: don't retry to a mount if we didn't actually manage to create an inode

namespace: downgrade log message of error we ignore to LOG_WARNING

frankly, the log message shouldn't be there at all, but the error path
be propagated up, with a recognizable error code. But apparently this is
important to @bluca.

namespace: convert ProtectHostname= logic to a static table

Let's simplify things, and make them more alike handling more similar to
the other ProtectXYZ= settings.

namespace: normalize memory management of mount list

So far we calculated exactly how many mounts we will generate, which is
a bit fragile, and easy to get wrong.

Let's normalize this, and grow the array of mounts as we need.

Various other modernizations while we are at it, such as FOREACH_ARRAY
usage, or `_cleanup_` usage.

update TODO

sysext: make some calls available via varlink

stub: NULL checks for DeviceHandle and FilePath

UKIs may be loaded in a way, that there can not be a device handle to
the filesystem, that contains the image, for example when using a
bootloader to load the image from a partition with a file system that is
not supported by the firmware.

With the current systemd stub, this causes a failed assertion, because
stub gets passed a NULL DeviceHandle and FilePath. Inserting two
explicit checks enables proper boot even in this case.

Fixes: #29331

Merge pull request #29558 from mrc0mmand/varlinkctl-tests

varlink: add a couple of tests + accompanying fixes

resolve: fix no mDNS announcement after probing

According to RFC 6762 section 8, an mDNS responder is supposed to announce its
records after probing.
Currently, there is a check in dns_scope_announce which returns if there are any
pending transactions. This prevents announcements from being sent out even if there
are pending non-probe transactions.

To fix this, return only if there are active probe transactions.

fuzz: Add fuzzer for efi conf/osrel parsing

boot: Fix OOB reads in conf/osrel parsing

boot: Move line_get_key_value to efi-string

No functional changes.

boot: Move parse_boolean to efi-string

No functional changes.

test: Remove unnecessary test prefix

core: don't downgrade multi-state settings to boolean

Protect{Home,System,Proc,Subset}= are not booleans, so make sure we use
the intended value instead of just true/false.

See: https://github.com/systemd/systemd/pull/29552
Follow-up to: 79d956d

docs: update fuzzers docs

test: update Ubuntu CI instructions

varlink: drop dead code

'#' is never part of either allowed_chars or allowed_delimiters when we
parse structs/enums.

varlink: use int for log level

varlink: don't panic on malformed method definition

test: add a fuzzer for the varlink IDL stuff

test: add a couple of tests for varlinkctl

core: fix deserialization copypasta

CID#1522788

core/exec-invoke: rename parameters of get_fixed_{user,group}

Follow-up for 1c9433559a40982785011aa187e2b34420a67e7e

The user/group passed in could be either the name or the uid/gid.

Merge pull request #29569 from YHNdnzj/foreach-array

core: use FOREACH_ARRAY more and some other minor changes

Merge pull request #29525 from poettering/confext-sysext-multimodal

dissect: make sure we can dissect and inspect DDIs that are both confext *and* sysext

core: add MemoryKSM and SetLoginEnvironment to exec_context_dump

core/execute: correct alignment

core/execute: use FOREACH_ARRAY more

core/execute-serialize: use FOREACH_ARRAY more

run: support --scope on old service managers that lack native PIDFD support

Before this we'd fail with a complaint that PIDFDs is not supported by
the service manager. Add some compat support by falling back to classic
numeric PIDs in that case.

update TODO

Merge pull request #27890 from bluca/executor

core: add systemd-executor binary

tpm: update comment on transient handle GetCapability bug in kernel tpm resource manager

Add clarification and link to kernel bug.

nspawn: set CoredumpReceive=yes on container's scope when --boot is set

When --boot is set, and --keep-unit is not, set CoredumpReceive=yes on
the scope allocated for the container. When --keep-unit is set, nspawn
does not allocate the container's unit, so the existing unit needs to
configure this setting itself.

Since systemd-nspawn@.service sets --boot and --keep-unit, add
CoredumpReceives=yes to that unit.

man: document CoredumpReceive= setting

man: move NFTSec= entry to "Network Accouting and Control" section

Currently it is in the "Memory Pressure and Control" section, which does
not seem accurate.

test: add a test for container support in coredump

coredump: add support for forwarding coredump to containers

If a process crashes within a container, try and forward the coredump to
that container. To do this, check if the crashing process is in a
different pidns, and if so, find the PID of the namespace leader. We
only proceed with forwarding if that PID belongs to a cgroup that is
descendant of another cgroup with user.delegate=1 and
user.coredump_receive=1 (i.e. Delegate=yes and CoredumpReceive=yes).

If we proceed, attach to the namespaces of the leader, and send the
coredump to systemd-coredump.socket in the container. Before this is
done, we need to translate the PID, UID, and GID, and also re-gather
procfs metadata. Translate the PID, UID, and GID to the perspective of
the container by sending an SCM_CREDENTIALS message over a socket pair
from the original systemd-coredump process, to the process forked in the
container.

If we cannot successfully forward the coredump, fallback to the current
behavior so that there is still a record of the crash on the host.

process-util: introduce namespace_get_leader helper

For a given PID and namespace type, this helper function gives the PID
of the leader of the namespace containing the given PID. Use this in
systemd-coredump instead of using the existing get_mount_namespace_leader.

This helper will be used again in a later commit.

coredump: store crashing process UID and GID in Context

For convenience, store the crashing process's UID and GID in Context (as
uid_t and gid_t, respectively), as is currently done for the PID. This
means we can just parse the UID/GID once in save_context(), and use
those values in other places.

This is just re-factoring, and is a preparation commit for container
support.

core: add CoredumpReceive= setting

This setting indicates that the given unit wants to receive coredumps
for processes that crash within the cgroup of this unit. This setting
requires that Delegate= is also true, and therefore is only available
where Delegate= is available.

This will be used by systemd-coredump to support forwarding coredumps to
containers.

cgroup-util: add cg_is_delegated helper

Take is_delegated from cgroup-show.c, and make it a generic helper
function. This new helper will be used again in a later commit.

core/varlink: make sure we setup non-serialized varlink sockets

Before this PR, if m->varlink_server is not yet set up during
deserialization, we call manager_setup_varlink_server rather than
manager_varlink_init, the former of which doesn't setup varlink
addresses, but only binds to methods. This results in that
newly-added varlink addresses not getting created if deserialization
takes place.

Therefore, let's switch to manager_varlink_init, and add some
sanity checks to it in order to prevent listening on the same
address twice.

Fixes #29373

Replaces #29421

systemd-journal-upload: Increase failure tolerance (#19426, #2877)

As systemd-journal-upload deals mostly with remote servers, add
some failsafes to its unit to restart on failures.

```
[Service]
Restart=on-failure
RestartSteps=10
RestartMaxDelaySec=60
```

Merge pull request #29551 from poettering/no-empty-structs-in-varlink

varlink: properly refuse empty structs/enums in varlink IDL

varlinkctl: generate slightly more useful error messages

Merge pull request #29502 from keszybz/sd-boot-config-tweaks

Tweaks to sd-boot UX

po: Translated using Weblate (French)

Currently translated at 100.0% (227 of 227 strings)

Co-authored-by: Pierre GRASSER <pierre.grasser@proton.me>
Translate-URL: https://translate.fedoraproject.org/projects/systemd/master/fr/
Translation: systemd/main

core: move code from execute.c to exec-invoke.c

No functional changes, only moving code that is only needed in
exec_invoke, and adding new dependencies for seccomp/selinux/apparmor/pam
in meson for the sd-executor binary.

core: add systemd-executor binary

Currently we spawn services by forking a child process, doing a bunch
of work, and then exec'ing the service executable.

There are some advantages to this approach:

- quick: we immediately have access to all the enourmous amount of
  state simply by virtue of sharing the memory with the parent
- easy to refactor and add features
- part of the same binary, will never be out of sync

There are however significant drawbacks:

- doing work after fork and before exec is against glibc's supported
  case for several APIs we call
- copy-on-write trap: anytime any memory is touched in either parent
  or child, a copy of that page will be triggered
- memory footprint of the child process will be memory footprint of
  PID1, but using the cgroup memory limits of the unit

The last issue is especially problematic on resource constrained
systems where hard memory caps are enforced and swap is not allowed.
As soon as PID1 is under load, with no page out due to no swap, and a
service with a low MemoryMax= tries to start, hilarity ensues.

Add a new systemd-executor binary, that is able to receive all the
required state via memfd, deserialize it, prepare the appropriate
data structures and call exec_child.

Use posix_spawn which uses CLONE_VM + CLONE_VFORK, to ensure there is
no copy-on-write (same address space will be used, and parent process
will be frozen, until exec).
The sd-executor binary is pinned by FD on startup, so that we can
guarantee there will be no incompatibilities during upgrades.

core: add serialization/deserialization for CGroupContext

core: add serialization/deserialization for ExecRuntime

core: add serialization/deserialization for ExecParameters

core: add serialization/deserialization for ExecCommand

core: add serialization/deserialization for ExecContext

test: add simple test for two common kind of errors

varlink: don't generate %m error message if we are synthesizing the error

We are outputting a more useful log message anyway, the "Bad message"
error string is just confusing.

varlink: refuse empty () structs/enums

If we encounter an empty struct in the varlink IDL it could also be an
empty enum. Refuse this to avoid the ambiguity.

The spec doesn't cover this case clearly, hence let's better be on the
safe side and refuse it rather than making a decision what it means.

Merge pull request #29544 from yuwata/network-dhcp-bus-command

network: several fixlets for DBus methods for DHCP client and server

core: add cgroup_add_or_update_device_allow()

serialize: add serialize_image_policy()

serialize: add open_serialization_file()

serialize: add serialize_string_set()

serialize: add serialize_item_tristate()

serialize: add serialize_item_base64mem()

serialize: add serialize_item_hexmem()

core: ensure execute/spawn functions can work without Unit object

When switching to serialization later, the Unit object will not be
serialized, move parameters around instead

core: ensure execute/spawn functions can work without manager object

When switching to serialization later, the Manager object will not be
serialized, move parameters around instead

core: add exec_params_dump helper

process-util: add posix_spawn helper

This provides CLONE_VM + CLONE_VFORK semantics, so it is useful to
avoid CoW traps and other issues around doing work between fork()
and exec().

env-util: add helper to replace env block

test: add space-separated test for LogFilterPatterns

core: fix checking for extension-releases for ExtensionImages/Directories

The parsing is done after the image has been opened, not before, as it
cannot be done on an block device. Also fix returning on any error for
ExtensionDirectories, not just ENOENT.

Follow-up for 55ea4ef096543d2bceea9315868d5aca945d7a57

update TODO

man/systemd.exec: Update service result table

exec-condition and oom-kill were added without updating this table.

hibernate-resume: remove kernel/image version comparison when resuming

We already had a similar check that was removed, see
8340b762e4f597e98a72de1385e74b9be04e521d (*). The kernel supports loading of a
resume image from a different kernel version. This makes sense, because the
goal of "resume" is to replace the running system by a saved memory image, so
it doesn't really matter that the short-lived kernel is different.

By removing the check, we make the process more reliable: for example, the user
may select a different kernel from a list, or not have the previously running
kernel in /boot at all, etc. Requiring the exact same kernel version makes the
process more fragile for no benefit.

Similar reasoning holds for the image version: the image may be updated, and
for example an older kernel+initrd might be used, with an embedded VERSION_ID
that is not the latest. This is fine, and the check is not useful.

I left the check for ID/IMAGE_ID: we probably don't want to use the resume
image if the hibernation was done from a different installation.

(Note: why not check VERSION_ID/IMAGE_VERSION? Because of the following
scenario: a user has an installation of Fedora 35, and they upgrade to Fedora
36, which means that the os-release file on disk gets replaced and now
specifies VERSION_ID=36. But the running kernel is not replaced, and its
package is not removed because the running kernel version is never removed, so
we still have a boot entry that in initrd-release says VERSION_ID=35. Without
rebooting, the user does hibernation. When resuming, we want to resume, no
matter if one of the new entries with VERSION_ID=36 or one of the old entries
with VERSION_ID=35 is picked in the boot loader menu.

If the installation is image-based, i.e. it has IMAGE_ID+IMAGE_VERSION, the
situation is similar: after an upgrade, we may still have an boot entry from
before the upgrade. Using an older kernel+initrd to boot and switch-root into a
newer installation is supported and is rather common.

In fact, it is a rather common situation that the version reported by the boot
entry (or stored internally in the initrd-release in the initrd) does not match
the actual system on disk. Generally, this metadata is saved when the boot menu
entry is written and does not reflect subsequent upgrades. Various
distributions generally keep at least 3 kernels after a upgrade, and during an
upgrade only install one new, which means that after a major upgrade, generally
there will be at least two kernels which have mismatched version information.)

OTOH, I think it is useful to *write* all the details to the EFI var. As
discussed in https://github.com/systemd/systemd/issues/29037, we may want to
show this information in the boot loader. It is also useful for debugging.

(*) Also again discussed and verified in
https://github.com/systemd/systemd/pull/27330#discussion_r1234332080.

", ignored" is dropped, since this failure is likely to cause the following
check to fail. Better not to say anything then to say the misleading thing.

Revert "Revert "meson: use c_args in generator scripts (#10289)""

This reverts commit 0e3cc902faec4f18d5fa606396f602b08bc94e27.

Fixes #10288.
I have confirmed that this does now fix cross-compilation.
It appears that changes upstream in Meson, probably mesonbuild/meson#5263, have made the original MR, #10289, work now.

This needs to be tested to ensure that it doesn't break Travis CI like when it was reverted in #10361.

efi/boot: rename ConfigEntry to BootEntry

Some of the entries are really configured, but we also have a bunch
of automatic entries. Calling them "config entries" is misleading, let's
use the more natural "boot entry".

While at it, rename:
  config_load_entries() → config_load_type1_entries()
  config_entry_add_unified() → config_load_type2_entries()
  config_title_generate() → generate_boot_entry_titles()
  config_entry_add_<type>() → config_add_entry_<type>()

No functional change.

efi/boot: adjust grammar and punctuation in comments

efi/boot: use "else if" instead of explicit "continue"

No functional change.

efi/boot: make timeout changes relative to current value

When the user pressed + or -, we would set the efivar override, starting
from the default of 0. Instead, set an override that starts at the current
value. This means that when user has e.g. a configured override of 5 s, and
they press +, they get an override of 6 s. I think this is leads to a much
smoother experience for a user, who does not necessarilly need to know that
we have three levels of overrides, they just want to easily configure the
timeout with keys. If they press +, the timeout should increase, and not
jump to some low value.

Also, once an override has been set via the boot menu, i.e. the efivar is set,
do not allow unsetting the efivar from the boot menu. This way we also avoid
an unexpected "jump" to whatever the other sources of configuration specify.
The user can configure any value with the keys that they want, so we don't
need to allow unsetting.

efi/boot: split out helper to reduce duplicate formatting code

No functional change.

sd-boot: when rebooting or powering off, save config state

The menu_run() function allows the user to set/unset default entry, or to
increase/decrease menu timeout. After a keypress, status like
  "Menu timeout set to 5 s"
is printed, but there actually isn't any immediate effect. The value is only
written right right before booting a menu entry to avoid unnecessary wear&tear
on the nvram storage. This delayed write is supposed to be invisible to the
user.

Nevertheless, operations like reboot into firmware, reboot, or shutdown were
done immediately. We need to exit the loop first, save the state, and only do
the op afterwards.

Fixup for f6531b11d21931b3952d566ceded672ba21681cc and
e6cab77eca8f6556f381c348b0452b526a752ab7.
Also reverts 498d0cc426afc13fdadb0a385fd16c005645e0cf.

man: use consistent label for "Reboot Into Firmware Interface"

That is what sd-boot actually displays.

efi/boot: use DEFINE_TRIVIAL_CLEANUP_FUNC() in one more place

No functional change.

network: do not trigger assertion by forcerenew command

When DHCP server is not running, sending force-renew command triggers
assertion.

sd-dhcp-server: make sd_dhcp_server_is_running() silently work with NULL

We already do in the same way for sd-dhcp-client and friends.

test-network: drop unnecessary explicit stop of dnsmasq

test-network: add test case for renewing DHCP lease