struct timex is defined by sys/timex.h -> bits/timex.h.
Glibc includes the header in time.h, but let's explicitly include it
when the struct is used.
Similar to 4f18ff2e29, but for sys/timex.h.
These source files uses symbols provided by sys/stat.h, e.g. struct stat,
S_IFREG, S_IFBLK, and so on. Let's explicitly include sys/stat.h where
necessary.
Glibc's fcntl.h includes bits/stat.h, which provides these symbols, so
these symbols can be used without explicitly including sys/stat.h. But,
based on the discussion in #37922, we should explicitly include relevant
headers, and should not rely on the indirect inclusion.
Similar to 4f18ff2e29, but for sys/stat.h.
For some fields, we perform careful parsing and verification on the sender
side. For other fields, we accept any string or strv. I think that actually
this is fine: we should optimize for the correct case, i.e. the user runs a
command that is valid. The server must perform parsing in all cases, so doing
the verification on the sender side doesn't add value. When doing parsing
locally, in case of invalid or unsupported input, we would generate the error
message locally, so we would avoid the D-Bus call, but the message itself is
not better and from the user's point of view, the result is the same. And by
doing the parsing only on the server side, we deal better with the case where
the sender has an older version of the software. By not doing verification, we
implicitly "support" new values. And when the sender has a newer version that
supports additional fields, that does not help as long as the server uses an
older version. So in case of version mismatches, parsing on the server side is
as good or better.
Resolves https://github.com/systemd/systemd/issues/37174.
This changes little in behaviour, the conceptual part is more important. The
non-Ex variant is the actual name on the command line, and we should use the
non-Ex D-Bus property too, if it works. This increases compatibility with old
versions. But the code was mostly doing the right thing. Even the tests tested
the right thing.
Follow-up for b3d593673c and
898fc00e79.
The test is simplified by taking advantage of the fact that both names
on the commandline are supposed to behave identically.
Partially resolves https://github.com/systemd/systemd/issues/37174.
We generally want to have error messages with a fixed structure that convey the
important information, i.e. field name, error value, and the offending text for
options that take short values. (The text is not printed for strings encoded with
base64 and hexmem or for credentials.)
Let's use a helper that prints the message in a fixed format in the majority of
cases. In the few places where a custom message is useful, the helper is not
used. The helper:
- prints the field name, value, and error info,
- quotes the value,
- handles -ENOMEM, so we don't need to handle it separately everywhere.
When this code was originally written, parse functions would return -1
as error. Nowadays day all return a good errno, so it is fine if we print
the corresponding strerror.
exec_command_flags_to_strv() should not fail, unless we screwed up, so assert
instead of returning an error. Also, no need to strdup constant _PATH_BSHELL;
drop that so that we can get rid of the oom error handling. Finally, rename
l → cmdline for clarity.
If one of the header is included in a C++ source file, then using
_Static_assert() triggers compile error for some reasons.
Let's use static_assert(), which can be used by both C and C++ code.
The source file uses symbols e.g. execl(), execvp(), _exit(), and so on,
without including unistd.h.
Continuation of 4f18ff2e29.
Follow-up for 9a08000d18.
These source files uses symbols provided by sched.h, e.g.
setns(), unshare(), CLONE_NEWNS, and friends, but they do not explicitly
include sched.h. Currently, it is included indirectly via missing_syscall.h,
which is included by e.g. pidfd-util.h.
Let's explicitly include headers that provides symbols used in the code.
This is similar to 4f18ff2e29, but for sched.h.
- use unsigned for the return value of read_nr_open(), as it does not
fail, and the kernel internally uses unsigned for the value,
- when bumping the value by PID1, let's start from the kernel's maximum
value defined in fs/file.c. The maximum value should be mostly an API
of the kernel, but may changed in a future, hence still try several
times if we fail to bump the value.
Co-authored-by: Jared Baur <jaredbaur@fastmail.com>
Co-authored-by: John Rinehart <johnrichardrinehart@gmail.com>
SYSTEMD_LANGUAGE_FALLBACK_MAP is used by the localed test, and
language_fallback_map is defined by the localed meson.
If the feature is disabled, the test is not built so the env var
is not needed, and the meson variable is not defined so the build
fails.
Follow-up for c5de7b14ae
chase() is arguably a hot path in our code, hence it deserves
some caching whether open_tree() is available. Moreover,
the manual set of r to -EPERM feels kinda ugly. Let's
instead extract this bit into its own function.
Now that we make use of open_tree() in places we previously used
openat() with O_PATH, it makes sense to move it from @mount to
@file-system. Without the OPEN_TREE_CLONE flag open_tree() is after all
unprivileged.
Note that open_tree_attr() I left in @mount, since it's purpose is
really to set mount options when cloning, and that's clearly a mount
related thing, not so much something you could use unpriv.
Follow-up for: c5de7b14ae
This addresses an issue tracked down by Antonio Feijoo: since the commit
that started to use open_tree() various apps started to crash because
they used seccomp filters and sd-device started to use open_tree()
internally.
Before, for empty input, we'd send an array with one item with an empty
pattern. Use the helper which sends an empty array instead.
bus_exec_context_set_transient_property() ignores items with an empty
pattern, so the result should be the same.
Request in review:
https://github.com/systemd/systemd/pull/37665#discussion_r2182375988.
The samples were partially generated using claude.ai. Those examples are
usually fairly boring. I tried to remove obvious repetitions and add some more
interesting examples, but certainly more edge cases could be added.
In some cases, we are quite lenient and do almost no verification on the sender
side.
ssh-generator: generate /etc/issue.d/ with VSOCK ssh info data
I find myself trying to log into a fresh ParticleOS VM started via
systemd-vmspawn all the time, but I don't know its CID. Let's show it on
the getty screen, to make it immediately visible.
Otherwise it will fail as it's an archive, not a PE file:
Invalid DOS header magic
Can't open image /boot/vmlinuz.old
/boot/vmlinuz.old is compressed and cannot be loaded by UEFI, decompressing
+ sbverify --list /boot/vmlinuz.old
=========================== short test summary info ============================
FAILED ../src/ukify/test/test_ukify.py::test_efi_signing_sbsign[3650] - subprocess.CalledProcessError: Command '['sbverify', '--list', PosixPath('/boot/vmlinuz.old')]' returned non-zero exit status 1.
FAILED ../src/ukify/test/test_ukify.py::test_efi_signing_sbsign[None] - subprocess.CalledProcessError: Command '['sbverify', '--list', PosixPath('/boot/vmlinuz.old')]' returned non-zero exit status 1.
FAILED ../src/ukify/test/test_ukify.py::test_inspect - subprocess.CalledProcessError: Command '['sbverify', '--list', PosixPath('/boot/vmlinuz.old')]' returned non-zero exit status 1.
Follow-up for 0dd03215f1
So far, when we tried to match a component to eent log entries we
skipped those components if they were outside of our location window.
That however is too aggressive, since it means any components that are
already in the logs, but outside of the location window will be
considered unrecognized in the logs, and thus removed from the PCR
policy.
Change things around: always try to match up all components, regardless
if inside the location window or outside, but then make it non-fatal we
can't find a component outside of the location window.
Fixes: #36079
As it turns out open() with O_PATH does *not* trigger autofs, you get a
reference to the autofs inode, if not triggered.
But there's a way out: open_tree() (when specified without
OPEN_TREE_CLONE) is actually fully equivalent to open() with O_PATH –
with the exception of one thing: it *does* trigger automounts.
Thanks for Christian Brauner for pointing me to this and saving my day.
Fixes: #33155
This makes it possible to build systemd with
-Dc_args='-DOPENSSL_NO_UI_CONSOLE=1'. Hopefully, now systemd can be
built with other openssl implementations, like BoringSSL, which deos not
support UIs.
Closes#38024.
Those are user-controlled strings, so let's use heap allocations in the usual
fashion. (Though, with strndupa_safe, the allocations were bounded anyway, so
ultimately this doesn't matter.)
Related to https://github.com/systemd/systemd/pull/37641.
The name "transient settings" was used in docs/TRANSIENT-SETTINGS.md.
Using "setting" helps distinguish this from D-Bus "properties", which are
a much larger set, partially overlapping.
bus_append_unit_property() and associated functions accept a long list of
properties. But the specific names are only available through code. But it is
useful to be able to know the specific list of properties that is supported, in
particular for shell completions. Thus, add a way to list the properties that
are supported by the code.
In the future we could also turn this into a test for the documentation. For
various reasons, the list of properties listed in the docs is a partially
overlapping set. E.g. for service type, the pull request
https://github.com/systemd/systemd/pull/37661 creates a list with 212 entries,
and this code generates 7 entries less and 184 more. I didn't check all the
differences, but in the few cases I did, the list generated here was actually
correctly supported by 'systemd-run -p'.
A smoke test is added.
Lennart Poettering
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Mike Yuan
DaanDeMeyer
Luca Boccassi
ZIHCO