Let's unconditionally drop privileges before submitting the coredump log
message.
Let's make the codepaths where we acquired a coredump and where we
didn't more alike: let's drop privs in both cases.
This is not only safer, but means that the coredump messages are always
accessible by the owner of the aborted process.
Let's not claim a process dumped core if that was disabled via resource
limits.
While we are at it, switch from stack to heap allocation for the log
message, as it includes a stack trace which can be arbitrarily large.
Fixes: #28559
If we have a DDI that contains only a /usr/ tree (and which is thus
combined with a tmpfs for root on boot) we previously would try to apply
idmapping to the tmpfs, but not the /usr/ mount. That's broken of
course.
Fix this by applying it to both trees.
Let's wait until the child is fully done with mounting it's own
instances of procfs/sysfs before we destroy our fully visible copies of
it.
This borrows heavily from Christian Brauners fix#29521, but splits the
place + sync into two steps so that the child payload is not started
before the parent has destroyed the procfs instance.
Alternative to: #29521Fixes: #28157
The actual default is 2^15 and that is also 32b kernels default.
Fix the value, mention 32b and do not talk about default which may
depend on nr_cpus.
Fix: #29607
The device node may be different from we want to activate, and we may
try to activate different device in the subsequent loop. In such case,
we should enable the automatic removal for the unexpected device.
Otherwise, it will not be removed even when not necessary anymore.
This module reads password from kernel keyring and sets it as PAM authtok.
It's inspired by gdm's pam_gdm, which reads the LUKS password stored by
systemd-cryptsetup, so Gnome Keyring can be automatically unlocked if set
to the same password (when autologin is enabled so the user doesn't enter
a password in gdm).
This is name ".network.example" for now, to match the existing
80-ethernet.network file.
I think it would make sense to actually install this by default if told
so via a meson file (and then hopefully this would happen even on
Fedora, though in a split off RPM or so). However, we aren't there yet,
hence for now, just ship the .network files as example, like the others.
When testing the secureboot enroll feature, it can be hard to distinguish without
using the QMP API of QEMU whether we are in a hang situation of the UEFI firmware.
Making it clear that we reached the `ResetSystem` can be helpful towards that need.
Both sleep_mode_supported and write_mode support this,
but parse_sleep_config currently prohibits this - it always
uses our default value if user specifies HibernateMode=<empty>.