This way we have can expose identical behaviour everywhere, can make use
of our atomic replacement calls, and openat() logic, and later apply
additional tracks while unpacking, such as putting limits on UID ranges
and similar.
dissect-image: take policy into consideration when unlocking verity, too
Previously, we'd take the image policy only into consideration when
dissecting the mage, but for the unlock/verity step we'd go via best
effort. Change that. This means we can now enforce policies such as
activating by root hash only even if a signature exists and similar.
Also, introduce a separate error code if we try to unlock a Verity
volume but have no root hash. Previously we'd return ENOKEY for that,
exactly like we do for encrypted volumes where we have no passparse. The
interctive unlock loop dissected_image_decrypt_interactively() is
otherwise very confused and will ask for a root hash, which makes no
sense. Hence use two distinct errors for this.
dissect-image: turn verity device sharing into opt-in
Sharing verity volumes is problematic for a veriety of reasons, for
example because it might pin the wrong backing device at the wrong time.
Let's hence turn this around: unless verity sharing is enabled, leave it
off, and turn $SYSTEMD_VERITY_SHARING into a true boolean that can be
set both ways.
The primary usecase for verity sharing is RootImage=, where it probably
makes sense to leave on, hence set the flag there.
This is crucial when putting together installers which install an OS on
a second disk: if verity sharing is always on we might mount the wrong
of the two disks at the wrong time.
Daan De Meyer [Mon, 13 Oct 2025 08:43:16 +0000 (10:43 +0200)]
sd-id128: Drop _sd_const_ from sd_id128_in_setv()
Both the const and pure attributes disallow modifying input arguments
but sd_id128_in_setv() clearly modifies its ap input argument by iterating
over it with va_arg() so drop the _sd_const_ attribute from
sd_id128_in_setv().
If systemd-pcrphase-initrd.service and friends failed for some reasons,
the test VM will reboot infinitely and the test will timeout. Let's
propagate the failure to the host and fail the test earlier in that case.
Duy Nguyen Van [Tue, 7 Oct 2025 04:09:19 +0000 (13:09 +0900)]
Fix build fail when add option "-fstack-protector-all"
When using canary check with "-fstack-protector-all" option. It causes a configure
error in systemd-boot when meson.build executes compile simple code to test linker option
"-static-pie" because -nolibstd option prevents using libc. It need for
canary to provide some function as "__stack_chk_guard". So need to turn off
canary check when compile sanity check.
mkosi: install test dependencies for EnterNamespace= test (#39268)
The test for the EnterNamespace= feature [0] has been both broken and
disabled since the migration to the mkosi framework, as it's missing the
libdw.pc file for pkg-config, so the test is skipped completely, and
it's also missing gcc to actually build the test binary.
Frantisek Sumsal [Fri, 10 Oct 2025 18:09:51 +0000 (20:09 +0200)]
test: temporarily skip the EnterNamespace= test w/o embedded debuginfo
The EnterNamespace= feature currently doesn't work if the debuginfo is
separated from the crashing binary. Until that's resolved, let's run the
test only if the test binary has embedded debuginfo (.debug_info
section; e.g. when systemd is built without WITH_DEBUG=1) or it contains
MiniDebugInfo (.gnu_debugdata section; default on Fedora and CentOS).
mkosi: install test dependencies for EnterNamespace= test
The test for the EnterNamespace= feature [0] has been both broken and
disabled since the migration to the mkosi framework, as it's missing the
libdw.pc file for pkg-config, so the test is skipped completely, and
it's also missing gcc to actually build the test binary.
logind: emit PropertiesChanged when lingering is enabled/disabled
Cockpit's podman plugin needs to know the lingering status so the UI can
advertise enabling `podman-restart` (which depends on lingering to
work). Currently it relies on watching `/var/lib/systemd/linger/${user}`
but that isn't a public API.
Drop `machine-id` OSC event field if /etc/machine-id doesn't exist
While we can safely assume that `/proc/sys/kernel/random/boot_id`
exists, the same can't be said for `/etc/machine-id` in environments
where systemd is installed, but not running. An example would be OCI
containers like with the official Arch Linux image, see [0].
Without this check the prompt would constantly output `/etc/machine-id:
no such file or directory` with the OSC events introduced in dadbb34
(v258).
First, let's say "must" rather than "shall" regarding creation of these
files, because without them group memberships will not work.
Secondly, suggest placing an empty JSON object in them, rather than
making them empty, simply to avoid issues with older systems that didn't
backport d6570eafe3b86584ca42979d1ced5bfd2228a5c7.
userdb: add support for looking up users or groups by uuid. (#37097)
Followon to #37024.
This implements (mostly) what was suggested there, except that only a
single UUID is accepted (modifying things to support multiple is a
relatively straightforward change from here)
I'm not really convinced this is the right approach:
* I can't really think of any cases where you'd need to query by
multiple UUIDs (I guess you might want to lookup multiple users, but in
that case why aren't there "usernames" or "uids" arrays?)
* If I specify username "foo" and UID 1234 and UID 1234 exists and has
username "bar", I get back the error `ConflictingRecordFound`
* If I specify username "foo" and UUID abcdef... and username "foo"
exists but has UUID 123456..., I get back the error
`NonMatchingRecordFound`
This makes the two ID types behave differently.
Additionally, when querying by `uuid`, the multiplexer will always sends
`more: true`, which is fine but a little unexpected.
I do think unifying things through the `UserDBMatch` struct could make
sense, but in that case I think it would make sense to unify all query
types in that way (username, uid, uuid), identify when the filter is for
a single or multiple records, and centralise determination of conflict
vs non matching record errors.
`userdb_by_name`/`userdb_by_uid` could then become helper functions for
the simple case where no additional filtering is needed.
Thoughts?
One other thought: Should the multiplexer just pass through all
parameters, even unknown ones, to the backend services? Even if it
doesn't know how to filter by every property, the backends might, and it
would be useful to allow them to optimise things. (I realise the
disadvantage of this, ofc, is loss of error checking)
creds: add explicit control on whether to allow null key decryption
The ability to encrypt/authenticate encryption with a null key was
originally just a fallback concept for cases where during early boot we
have no host key, but the local system has no TPM2. Nowadays it is used
for other stuff as well, such as pcrlock data propagation (i.e. data
that needs no protection itself and required to properly to TPM key
derivation).
Let's give better, explicit control over null key usage, i.e. let's make
it a tristate both on the systemd-creds command line and in the Varlink
IPC to control three cases:
- the default that we allow it only if SecureBoot is off
- explicitly allowed
- explicitly refused (this is new)
Ideally systemd-creds --allow-null switch would take a boolean argument
to control this as a tristate. Alas, that would be a compat break, hence
I added --refuse-null instead (which also maps to the low-level flag for
this).
This also normalizes that the null key is always called "null key" in
messages, and not sometimes "empty key" or "fallback key".
sysctl: support reading configuration from stdin and command line arguments (#39219)
This makes systemd-sysctl support following syntax, like
systemd-sysusers and systemd-tmpfiles:
```sh
$ /usr/lib/systemd/systemd-sysctl --inline 'foo.bar=42'
$ /usr/lib/systemd/systemd-sysctl - <<EOF
foo.bar=42
EOF
```
```
$ build/systemd-mute-console -q
Code should not be reached at src/mute-console/mute-console.c:103, function parse_argv(). Aborting. 💥
Aborted (core dumped)
```
Daan De Meyer [Mon, 6 Oct 2025 10:59:44 +0000 (12:59 +0200)]
copilot: Tell the AI to be thorough
At least when doing a local review, asking it to be thorough results
in a lot more comments on coding style violation so let's add such an
instruction to the global instructions.
Daan De Meyer [Mon, 6 Oct 2025 08:42:10 +0000 (10:42 +0200)]
Add copilot instructions
This was generated using copilot itself with Claude Sonnet 4.5 as
the backing model.
The idea is to test this out on some PRs to see whether copilot can
provide useful PR reviews. The idea is that it'll be able to take care
of the low hanging fruit like coding style issues and such. Once we get
some feedback on how it performs, we can make more changes to this document
to get it to behave better (assuming we decide to keep using it at all).
* e50fce1d4b Fix installation of new manpages
* 8b45d3d793 Install new files for upstream build
* a401468f75 autopkgest: install bsdutils and bsdextrautils for unit tests
* 587584577e Explicitly disable bpf-framework for stage1 builds
* 209a8475d9 systemd: recommend login package
Yu Watanabe [Sat, 4 Oct 2025 21:35:54 +0000 (23:35 +0200)]
shared/bootspec: don't warn for new `loader.conf` options and correctly parse new `uki` and `profile` boot entry options (#39165)
Commit e2a3d562189c413de3262ec47cdc1e1b0b13d78b added the `uki` option
to sd-boot, and 1e9c9773b994f2f703a5aa5ba80961e90be3a892 added
`profile`, but because these were not added in src/shared/bootspec,
bootctl still shows warnings like `Unknown line 'uki', ignoring.` when
parsing the config. This PR allows parsing and displaying them correctly
in `bootctl` output. It also stops it from printing a warning for any of
the new `loader.conf` options (`log-level`, `reboot-on-error`, etc.).
Note that `uki-url` is still not handled as I can't easily test it.
man: fix advice regarding thread safety of libsystemd
The prohibition to move libsystemd objects between threads was added in 64a7ef8bc06b5dcfcd9f99ea10a43bde75c4370f ('man: be more explicit about thread
safety of sd_journal'). At the time, this was valid, because we were using the
mempool for allocation and it apparently didn't handle access from different
threads. Sadlly, the commit links to a bugzilla entry referenced in the commit
is not publicly visible anymore, so the details are murky. But we stopped using
the mempool in a5d8835c78112206bbf0812dd4cb471f803bfe88 ('mempool: only enable
mempool use when linked to libsystemd-shared.so'), with subsequent followup in b01f31954f1c7c4601925173ae2638b572224e9a ('Turn mempool_enabled() into a weak
symbol'). The restriction added in the man page is not necessary since then.
The text in the man page was arguably incorrect in calling the code
"thread-agnostic". If the code does not support being touched from threads at
all and has global state to tied to the main thread, it is not "agnostic", but
just doesn't support threads.
(I'm looking into https://github.com/systemd/python-systemd/issues/143, and
with the current scheme, the python-systemd module and all python code using
libsystemd would be very hard to use. With the change to free-threaded python
in python3.13, i.e. the replacement of single Global Interpreter Lock by
locking on individual objects, this limitation would become even more
constraining.)
val4oss [Wed, 1 Oct 2025 15:32:53 +0000 (17:32 +0200)]
TEST-74-AUX-UTILS: use sshd_config.d
* From the TEST-74-AUX-UTILS.ssh.sh writing directly into
/etc/ssh/sshd_config can hide config from distro using /usr/etc.
* Using directory configuration /etc/ssh/sshd_config.d/* suits for all
cases.
Most of those were dropped in 7d247d3cb875e1778e6cc81dbf255b13092b29e0. I left
behind the few cases where the 'output' name was different from the target name.
But we actually don't need those either, so get rid of those. (And one case
where I missed the name argument.)
No functional change, except that e.g. 'ninja -C build update-man-rules-impl'
doesn't work, but I hope nobody was using that.
projects / thirdparty / systemd.git / log
