This series of renaming patches has a few overlapping motivations:
- when functions are named uniformly, it code is more obvious
- I want to add a parameter to all verb functions
- in #40880 uniform naming of verb functions will be necessary too.
So let's do this cleanup. Some tools had a mix of functions w/ and
w/o "verb_", which looked messy.
Relicense sd-dlopen.h from LGPL-2.1-or-later to MIT-0 so that
downstream projects can copy/paste the macros directly without
introducing a build dependency on the systemd headers.
Acked-by: Lennart Poettering <lennart@amutable.com>
Acked-by: Luca Boccassi <luca.boccassi@gmail.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Switch all internal callers from the private ELF_NOTE_DLOPEN() macro to
the new public SD_ELF_NOTE_DLOPEN() API from sd-dlopen.h, and remove
the now-redundant macro definitions from dlfcn-util.h.
Signed-off-by: Christian Brauner <brauner@kernel.org>
Expose ELF note dlopen annotation macros as a public header-only API in
sd-dlopen.h. This allows any project to embed .note.dlopen metadata in
their ELF binaries by simply including the header - no runtime linkage
against libsystemd is required.
The header provides SD_ELF_NOTE_DLOPEN() and associated macros/constants
implementing the ELF dlopen metadata specification for declaring optional
shared library dependencies loaded via dlopen() at runtime.
Signed-off-by: Christian Brauner <brauner@kernel.org>
Add %I (TID in initial PID namespace) to the core_pattern, so the
kernel passes the crashing thread's TID to systemd-coredump. Use it
to read the thread's comm name from /proc/<tid>/comm and log both as
new journal fields:
COREDUMP_TID= — TID of the crashing thread
COREDUMP_THREAD_NAME= — comm name of the crashing thread
These fields are also stored as xattrs on external coredump files
(user.coredump.tid, user.coredump.thread_name) and displayed by
coredumpctl info alongside the PID line.
For single-threaded processes the TID equals the PID and thread_name
equals comm; for multi-threaded programs with named worker threads
(pthread_setname_np / PR_SET_NAME) this identifies which thread
crashed without needing to open the coredump file itself.
The new fields are optional in the socket forwarding path, so older
systemd-coredump senders are handled gracefully.
Co-developed-by: Claude <claude@anthropic.com>
These functions take so many return paramaters, and in many of our cases
we don't actually needt them. Hence introduce _full() flavours of the
funcs, and hide the params by default.
The previous version in the PR changed variable and sanitized it
in place. The second version switched to skip if CCs are in the
string instead, but didn't move back to the original variable.
Because it's an existing variable, no CI caught it.
Follow-up for 16325b35fa
In a project I'm working on I recently observed a boot failure
with the most recent version of systemd. It seems it is triggered
by bb19b61049 which fixed a bug that now leads to the function
being excuted differently. The code is missing a check if
`*ret_version` is actually valid in the `ret_measured = true`
case.
Add the libfido2 dependency to cryptenroll and cryptsetup's
meson files. If libfido2's not installed in the default path
the build wasn't finding its headers correctly.
Let's harden ourselves against shitty firmware which might report an
invalid PCR.
(This is not really a security issue, more a robustness issue, after all
firmware generally comes with highest privileges and trust, even though
it might just be shit)
Fixes an issue found with Claude code review
We have two places where those fields can be set: config and the dbus
interface. Let's clamp down on the number in both places. But in
principle, we could also be upgrading (through
serialization/deserialization) from an older systemd which didn't
enforce this limit, so also check on deserialization. A user could have
a unit with lots and lots of ExtraFields, but not enough to cause the
issue in #40916. To handle this gracefully, ignore the extra fields,
like we do in the parser. Where the field is used, assert that we are
within the expected bounds.
Fixes#40916.
Reproducer:
```console
$ python3 -c 'from pydbus import SystemBus; from gi.repository import GLib; SystemBus().get("org.freedesktop.systemd1", "/org/freedesktop/systemd1").StartTransientUnit("crash.service", "fail", [("ExecStart", GLib.Variant("a(sasb)", [("/bin/true", ["/bin/true"], False)])), ("LogExtraFields", GLib.Variant("aay", [b"F%d=x" % i for i in range(140000)]))], [])' Traceback (most recent call last):
File "<string>", line 1, in <module>
from pydbus import SystemBus; from gi.repository import GLib; SystemBus().get("org.freedesktop.systemd1", "/org/freedesktop/systemd1").StartTransientUnit("crash.service", "fail", [("ExecStart", GLib.Variant("a(sasb)", [("/bin/true", ["/bin/true"], False)])), ("LogExtraFields", GLib.Variant("aay", [b"F%d=x" % i for i in range(140000)]))], [])
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.14/site-packages/pydbus/proxy_method.py", line 102, in __call__
raise error
File "/usr/lib/python3.14/site-packages/pydbus/proxy_method.py", line 97, in __call__
result = instance._bus.con.call_sync(*call_args)
gi.repository.GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Too many extra log fields. (16)
```
We have two places where those fields can be set: config and the dbus
interface. Let's clamp down on the number in both places. But in principle, we
could also be upgrading (through serialization/deserialization) from an older
systemd which didn't enforce this limit, so also check on deserialization. A
user could have a unit with lots and lots of ExtraFields, but not enough to
cause the issue in #40916. To handle this gracefully, ignore the extra fields,
like we do in the parser. Where the field is used, assert that we are within
the expected bounds.
Fixes#40916.
Reproducer:
$ python3 -c 'from pydbus import SystemBus; from gi.repository import GLib; SystemBus().get("org.freedesktop.systemd1", "/org/freedesktop/systemd1").StartTransientUnit("crash.service", "fail", [("ExecStart", GLib.Variant("a(sasb)", [("/bin/true", ["/bin/true"], False)])), ("LogExtraFields", GLib.Variant("aay", [b"F%d=x" % i for i in range(140000)]))], [])'
Traceback (most recent call last):
File "<string>", line 1, in <module>
from pydbus import SystemBus; from gi.repository import GLib; SystemBus().get("org.freedesktop.systemd1", "/org/freedesktop/systemd1").StartTransientUnit("crash.service", "fail", [("ExecStart", GLib.Variant("a(sasb)", [("/bin/true", ["/bin/true"], False)])), ("LogExtraFields", GLib.Variant("aay", [b"F%d=x" % i for i in range(140000)]))], [])
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.14/site-packages/pydbus/proxy_method.py", line 102, in __call__
raise error
File "/usr/lib/python3.14/site-packages/pydbus/proxy_method.py", line 97, in __call__
result = instance._bus.con.call_sync(*call_args)
gi.repository.GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Too many extra log fields. (16)
[] has higher precedence than pointer dereference, hence hilarity
ensues as soon as there are multuple images
Originally reported on yeswehack.com as:
YWH-PGM9780-122
Follow-up for dfdeb0b1cb
pe_section_table_from_file already checks with SECTION_TABLE_BYTES_MAX,
do the same in pe_section_table_from_base() just in case.
Originally reported on yeswehack.com as:
YWH-PGM9780-117
Follow-up for f4e081051d
Mark realName, emailAddress, and location as sensitive in JSON user
records so that they are excluded from debug log output. These fields
contain personally identifiable information that should not be leaked
in logs, which are generally more accessible than the user database
itself.
- Extract common logic to client_send_release_or_decline().
- Do not send DECLINE message on BOOTP protocol.
- Drop redundant assignment of chaddr, as it is already set by
client_message_init() -> dhcp_message_init().
- Do not assign acquired address in ciaddr field of DECLINE message,
but use Requested IP Address option.
- Broadcast DECLINE message, rather than unicast.
- Set server identifier in both cases.
Fixes#39299.
After commit "core: reuse existing dm-verity device for single
filesystem images pinned by policy" (0bd766553c), when I attach a
portable image (erofs+verity) and try to start a service, it fails with:
Partition root discovered with policy 'unprotected' but 'verity+read-only-on+growfs-off+erofs' was required, refusing.
Failed to dissect image: Operation not possible due to RF-kill
The image does have verity, in fact the RootImagePolicy= field was added
automatically.
The inconsistency between what is found at attach vs when starting the
service comes from the fact that dissect_image() is called with a
different policy as parameter and the recent shortcut added.
At attach we do this:
dissect_image(policy="*")
partition_policy_determine_fstype(policy)
partition_policy_flags_to_string(...) // mask is 0, returns 0
-> returns NULL // root_fstype_string is not set
if (root_fstype_string) // false
sym_blkid_probe_lookup_value()...
At start, as we do have the policy set, we do:
dissect_image(policy="root=verity+...+erofs:root-verity=...")
partition_policy_determine_fstype(policy)
partition_policy_flags_to_string(...) // returns 1
-> sets root_fstype_string to "erofs"
if (root_fstype_string) // true
usage = "filesystem"
Then, the service is blocked to start with the aforementioned error.
It's correct for partition_policy_determine_fstype() to set erofs in
that case, and other callers seem to expect this behavior on similar
cases, but what is not correct is to assume that this means it's a
filesystem. Usage in this case should still be unset.
Let's just always do the lookup, as that gets us the correct answer reliably
and we already did the slow part that is the probe.
The call to `sym_blkid_do_safeprobe()` is a few lines above. The call to
the lookup function isn't very expensive. blkid_probe_lookup_value()[1]
calls __blkid_probe_lookup_value(), which searches on a list[2], IIUC in
memory and no IO is used. It's a linear search of the property.
[1]: https://github.com/util-linux/util-linux/blob/0fd08f19e7a3bc37509491d06a664cfb47be7cd8/libblkid/src/probe.c#L2299
[2]: https://github.com/util-linux/util-linux/blob/0fd08f19e7a3bc37509491d06a664cfb47be7cd8/libblkid/src/probe.c#L2343
bus_cgroup_set_tasks_max_scale() used a hand-rolled percentage format
that produced values ~10x too small (e.g., "TasksMax=4.0%" instead of
"TasksMax=40.00%").
On daemon-reload, the incorrect value was re-read, silently reducing
the effective TasksMax by ~10x and causing fork rejections on systems
with high thread counts.
Fix by using the existing PERMYRIAD macros, consistent with memory
property handlers (MemoryMax, MemoryHigh, MemoryLow, etc.).
Fixes: #41009
When a DHCP client uses SendOption=82:string:..., option_append() calls
the SD_DHCP_OPTION_RELAY_AGENT_INFORMATION case which was written for
the server relay path. It casts optval to sd_dhcp_server* and calls
strlen() on its members, but optval is actually raw binary data from
the client, causing SIGSEGV. The same is applicable when option 43 and
option 77 are passed to SendOption.
Fix by checking optlen > 0 and appending the option as a plain TLV,
skipping the server-specific relay agent logic.
This is very noisy as there's a dozen of these message every
time it gets called, and it's not really an error but an
expected situation, so downgrade from info to debug
Zbigniew Jędrzejewski-Szmek
Christian Brauner
noxiouz
Lennart Poettering
Luca Boccassi
Michael Vogt
Dan McGregor
Daan De Meyer
Dylan M. Taylor
Yu Watanabe
Rodrigo Campos
Cyrus Xi
Nandakumar Raghavan