14385s [ 66.896852] TEST-87-AUX-UTILS-VM.sh[3744]: + test -x /usr/lib/systemd/systemd-validatefs
14385s [ 66.898544] TEST-87-AUX-UTILS-VM.sh[3744]: + echo 'no systemd-validatefs'
14385s [ 66.899115] TEST-87-AUX-UTILS-VM.sh[3744]: no systemd-validatefs
14385s [ 66.899699] TEST-87-AUX-UTILS-VM.sh[3744]: + return
14385s [ 66.900189] TEST-87-AUX-UTILS-VM.sh[3744]: .//usr/lib/systemd/tests/testdata/units/TEST-87-AUX-UTILS-VM.validatefs.sh: line 13: return: can only `return' from a function or sourced script
Follow-up for 6e003d18bb
This introduces notify_socket_prepare(), which creates an autobind
notify socket and IO event source for the socket. Then, use it where we
send notification messages from worker processes to their manager
process.
Follow-ups for 72586a971b.
- drop 'Options' sections,
- drop underlining for link,
- fix indentation.
Prompted by https://github.com/systemd/systemd/pull/36850#discussion_r2020594171
> the underline stuff we only use for long --help texts that have sections,
> for the section headers. systemctl --help does that for example. This one
> here is not that long, hence doesn't really need section headers, and
> hence no underlining. The clickable links don't need to be explicitly
> underlined, the terminal emulators that supper hyperlinks will underline
> them on their own (for example gnome-terminal uses a dotted line).
Addresses https://github.com/systemd/systemd/pull/36873#discussion_r2017578611
Follow-up for ed024abac6
and 9fbe26cfa8
Also, let's not get too tangled up in the style of defining variables
in between. The functions are short enough, and vars involved are still
effectively at the beginning... Put differently, the separation from
'int r' is too deliberate and brings no actual value in my eyes.
If we have multiple trusted fs (i.e. luks or dm-verity) we generate via
repart at boot, we must make sure they cannot be "misappropriated", i.e.
used for a different mount they were intended for.
Hence, let's introduce "mount constraint" data (encoded in xattrs on the
root inode of the fs) that tells us where a file system has to be
mounted, and what the gpt partition metadata has to be for the fs to be
valid.
Inspired by this thread:
https://lists.freedesktop.org/archives/systemd-devel/2025-March/051244.html
- SO_PEERGROUPS is since kernel v4.13
(28b5ba2aa0f55d80adb2624564ed2b170c19519e),
- SO_BINDTOIFINDEX is since kernel v5.1
(f5dd3d0c9638a9d9a02b5964c4ad636f06cf7e2c).
If the target dir is tmpfs and we run on old kernels we cannot extract
xattrs and the extracting will fail if there are any. hence add
-no-xattrs to the two remaining unsquashfs invocations that don't have
it.
(Also all other invocations across our test tree spell "-dest" instead
of "-d", hence do so here too.)
Let's automatically generate validatefs xattrs by default, that encode
the intended use of partitions.
This defaults to on, since the structure of repart definition files
tells us enough on use for this to be safe. There's an option however,
to turn this off.
Let's turn on validatefs automatically for all auto-discovered
partitions.
Let's add an x-systemd.validatefs option to optionally turn this on for
fstab listed file systems.
This new tool looks for a three xattr on the root inode of a file system
that encode mount constraints of the file system. The tool is supposed
to be hooke into the mount logic and is supposed to protect against
misappropriating trusted file systems in unintended ways.
Consider the following scenario: we boot up on first boot and create a
tpm-locked pair of /var/ and /srv/ partitions via systemd-repart. An
attacker then offline modifies the partition table, exchanging the
metadata of the /var/ and /srv/ partition. So far we'd happily accept
that, honour the modified metadata and boot up. This could be used to
revert changes to /var/ or similar. And all that even though both
partitions are encrypted and locked to TPM!
With this new mechanism we can encode in the protected contents of the
file systems the ways it can be used: the partition type uuid, the
partition label and the intended mount point can be stored in xattrs,
and we can check them automatically on mount, and take action on
mismatch. (action would typically be immediate reboot).