Compared to PID1 where systemd-oomd has to be the client to PID1
because PID1 is a more privileged process than systemd-oomd, systemd-oomd
is the more privileged process compared to a user manager so we have
user managers be the client whereas systemd-oomd is now the server.
The same varlink protocol is used between user managers and systemd-oomd
to deliver ManagedOOM property updates. systemd-oomd now sets up a varlink
server that user managers connect to to send ManagedOOM property updates.
We also add extra validation to make sure that non-root senders don't
send updates for cgroups they don't own.
The integration test was extended to repeat the chill/bloat test using
a user manager instead of PID1.
Gets rid of a few gotos, allows removing the extra ret variable and
will also be used in a future commit by the codepath that receives
cgroups from user instances of systemd.
Pressure remains > 1% after a kill for some time and could cause
testchill to get killed. Bumping the limit from 1% to 20% should help
with this.
Fixes#20118
cryptenroll allows to specify a custom TPM driver separated from
parameters with colon e.g. `systemd-cryptenroll --tpm2-device=swtpm:`
tells to load swtpm tss driver and use it as a device.
Unfortunately it does not work, swtpm driver init() fails with
```
debug:tcti:src/tss2-tcti/tcti-swtpm.c:570:Tss2_Tcti_Swtpm_Init() Dup'd conf string to: 0x562f91cbc000
debug:tcti:src/util/key-value-parse.c:85:parse_key_value_string() parsing key/value: swtpm:
WARNING:tcti:src/util/key-value-parse.c:50:parse_key_value() key / value string is invalid
Failed to initialize TCTI context: tcti:A parameter has a bad value
```
It turns out that cryptenroll suppose to use the driver name internally
and strip it before passing the rest of parameters to init() function.
Without doing it swtpm receives incorrect key-value property and gets
confused.
Fix it by passing the correct parameter (without driver name) to the
init() function.
Fixes#20708
Currently, SYSTEMD_LOG_LEVEL set in the ManagerEnvironment property in system.conf
or user.conf doesn't affect the manager's logging level. Parsing the logging environment
variables again after pushing the manager environment into the process environment
block makes sure any new environment changes also get taken into account for logging.
Our code logic doesn't support images with two verity partitions at the
moment, hence refuse this early (with ENOTUNIQ)
Also, go even further and refuse any combinations of verity enabled root
with verity-less /usr, simplify because that is unsafe and defeats the
point of verity. (i.e. we want to give the guarantee that for
auto-discovered verity magic we guarantee that the data afterwards
available in /usr is safe).
We already check whether we discovered a /usr verity partition without a
/usr partition when initially mangling the partitions, a bunch of lines
further up, no need to repeat this here.
Previously, we'd clean up discovered /usr/ partition data only if we did
not find a root partition. Given that we allow combinations of root and
/usr partitions clean things up in both cases however.
Our code doesn't support setting up verity with an external verity data
file unless we operate in non-partitioned mode. Let's refuse this
clearly and early if attempted anyway.
For the GPT partitioned logic we also consult the fstype to determine whether
a partition is read-only (i.e. squashfs is already read-only). For the
non-partitioned mode we didn't do that so far. Fix that.
Let's also pick more precise names for these helpers that are used for
the tabular output: one checks whether a partition is candidate for
verity at all, and the other checks if it is ready to be used for it.
Let's make this clearer in the name.
Let's make the booleans indicating verity state a bit more descriptive.
Let's rename:
can_verity → has_verity: because that's really what this about
whether verity data is included in the image. Whether we actually
can use it is a different story.
verity → verity_ready: this one should tell us if we have everything
need to actually set it up, hence explicitly say "ready to use" in
the name.
No change in behaviour. Just a bit of renaming.
Currently, link_stop_engines(), link_drop_config(), and link_drop_foreign_config()
do nothing when the interface is unmanaged. So this does not change anything.
But returning earlier should be clear and safer for protecting configs
on unmanaged interfaces.
The Bootloader Specification says "devicetree refers to the binary
device tree to use when executing the kernel..", but systemd-boot
didn't actually do anything when encountering this stanza until now.
Add support for loading, applying fixups if relevant, and installing the
new device tree before executing the kernel.
Jamie Bainbridge found an issue where glib's g_get_user_database_entry()
may crash after doing:
```
error = getpwnam_r (logname, &pwd, buffer, bufsize, &pw);
// ...
pw->pw_name[0] = g_ascii_toupper (pw->pw_name[0]);
```
in order to uppercase the first letter of the user's real name. This is
a glib bug, because there is a different codepath that gets the pwd from
vanilla getpwnam instead of getpwnam_r as shown here. When the pwd
struct is returned by getpwnam, its fields point to static data owned by
glibc/NSS, and so it must not be modified by the caller. After much
debugging, Jamie Bainbridge has fixed this in https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2244
by making a copy of the data before modifying it, and that resolves all
problems for glib. Yay!
However, glib is crashing even when getpwnam_r is used instead of
getpwnam! According to getpwnam_r(3), the strings in the pwd struct are
supposed to be pointers into the buffer passed by the caller, so glib
should be able to safely edit it directly in this case, so long as it
doesn't try to increase the size of any of the strings.
Problem is various functions throughout nss-systemd.c return synthesized
records declared at the top of the file. These records are returned
directly and so contain pointers to static strings owned by
libsystemd-nss. systemd must instead copy all the strings into the
provided buffer.
This crash is reproducible if nss-systemd is listed first on the passwd
line in /etc/nsswitch.conf, and the application looks up one of the
synthesized user accounts "root" or "nobody", and finally the
application attempts to edit one of the strings in the returned struct.
All our synthesized records for the other struct types have the same
problem, so this commit fixes them all at once.
Fixes#20679
