Note to self: should I ever become a black hat hacker, this is how I'd
hide a vulnerability. ;-)
(No, this one is not a vulnerability)
Follow-up for: 163d1ea5dd
We have the journal file open already, hence reference it via the fd
insted of the file name. After all, some other tool might have
renamed/deleted it already.
Let's not actually reuse the fd though, since we want a separate file
offset for the copying, hence just make it simply and reopen via
/proc/self/fd/.
Follow-up for d71ece3f0b
to let them use reproducible identifiers, which should make it possible
to really use files copied from OSS-Fuzz to reproduce issues on
GHActions and locally. Prompted by https://github.com/systemd/systemd/pull/22365
No actual code changes, just renaming.
Rationale: the focus here should be on the fact that these are "unified"
images, whether our stub is used or not, or something else doesn't
really matter. Moreover, these are still Linux entries. Hence, emphasize
that these are *unified* images, and *Linux* images, and deemphesize
that our sd-stub is likely used.
it might be totally inaccessible, hence weaken our language a bit and
just say "not readable", thus making not claim whether it is writable or
not.
Follow-up for 3a90bef55a
It's a follow-up to https://github.com/systemd/systemd/pull/10200 where
that fuzzer was introduced. At the time it was run regularly on machines
where machine-id wasn't present so it was kind of reproducible. Now
it's run on CIFuzz and CFLite using GHActions with the public OSS-Fuzz
corpora (based on that particular machine-id) so to fully utilize
those corpora it's necessary to use it always. Other than that
it makes it possible for fuzzers targeting outgoing packets
based on incoming packets like https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1795921
to get past client_parse_message on my machine :-)
Fixes a regression caused by 3008a6f21c.
Before the commit, when `mkdir_parents_internal()` is called from `mkdir_p()`,
it uses `_mkdir()` as `flag` is zero. But after the commit, `mkdir_safe_internal()`
is always used. Hence, if the path contains a symlink, it fails with -ENOTDIR.
To fix the issue, this makes `mkdir_p()` calls `mkdir_parents_internal()` with
MKDIR_FOLLOW_SYMLINK flag.
Fixes#22334.
It's totally not OK to write to the strings returned by it, the data is
shared by all code that references the message.
While we are at it, simplify the code via
json_variant_set_field_string().
Follow-up for: 5ef599b324
This partially undoes the effect of
ab6e257b3e.
Originally, we always used the mmap logic to determine the current end
of the file. ab6e257b3e changed this so
that we always used pread().
With this change we'll use pread() from the synchronization thread and
mmap otherwise.
C macros are nasty. We use them, but we try to be conservative with
them. In particular passing literal, complex code blocks as argument is
icky, because of "," handling of C, and also because it's quite a
challange for most code highlighters and similar. Hence, let's avoid
that. Using macros for genreating functions is OK but if so, the
parameters should be simple words, not full code blocks.
hence, rework DEFINE_CUSTOM_TEST_MAIN() to take a function name instead
of code block as argument.
As side-effect this also fixes a bunch of cases where we might end up
returning a negative value from main().
Some uses of DEFINE_CUSTOM_TEST_MAIN() inserted local variables into the
main() functions, these are replaced by static variables, and their
destructors by the static destructor logic.
This doesn't fix any bugs or so, it's just supposed to make the code
easier to work with and improve it easthetically.
Or in other words: let's use macros where it really makes sense, but
let's not go overboard with it.
(And yes, FOREACH_DIRENT() is another one of those macros that take
code, and I dislike that too and regret I ever added that.)
When classless static routes option is provided, then static routes
option should not be used. Hence, let's not mix and store them in one
storage.
This introduce sd_dhcp_lease_get_static_routes() and
sd_dhcp_lease_get_classless_routes().
This is a follow-up for d5ee050ffc, and
reintroduces a requirement dep from systemd-journal-flush.service onto
systemd-journald.service, but a weaker one than originally: a Wants= one
instead of a Requires= one.
Why? Simply because the service issues an IPC call to the journald,
hence it should pull it in. (Note that socket activation doesn't happen
for the Varlink socket it uses, hence we should pull in the service
itself.)
Since test-resolved-stream brings up a simple DNS server on 127.0.0.1:12345,
only one instance could run at a time, so it would fail when run like
`meson test -C build test-resolved-stream --repeat=1000`.
Similarly, if by chance something is up on port 12345, the test would fail.
To make the test more reliable, run it in an isolated user + network namespace.
If this fails (some distributions disable user namespaces), just run as before.
In commit 2aaf6bb6e9, an issue was fixed where
systemd-resolved could get stuck for multiple seconds waiting for incoming data,
since GnuTLS/OpenSSL can buffer a TLS record, so data could be available, but
no EPOLLIN event would be generated.
To fix this, a somewhat elaborate logic consisting on asking the TLS library
whether it had buffered data, then "faking" an EPOLLIN event was implemented.
However, there is a much simpler solution: Always read as much data as available
(i.e. until we get an event like EAGAIN when trying to read) from the stream
when we get an EPOLLIN event, instead of at most a single packet per event.
This approach does not require asking the TLS library whether it has buffered
data, and the logic is exactly the same for both the TCP and TLS case.
test-resolved-stream is fixed to avoid a latent double free bug.
Since when handling a DNS over TLS stream, the TLS library can override the
requested events through dnstls_events for handshake/shutdown purposes,
obtaining the event flags through sd_event_source_get_io_events and checking
for EPOLLIN or EPOLLOUT does not really tell us whether we want to read/write
a packet. Instead, it could just be OpenSSL/GnuTLS doing something else.
To make the logic more robust (and simpler), save the flags that tell us
whether we want to read/write a packet, and check them instead of the IO flags.
(& use uint32_t for the flags like in sd_event_source_set_io_events prototype)
This fixes a bunch of issues:
pread() returns ssize_t, and returns errors in 'errno', handle that
correctly.
More importantly: it might incompletely read data in case we hit
EOF. Check for that, and handle it.
Finally, rename the function to journal_file_read_object_header(), since
it really doesn't read full objects, but only their headers.
Follow-up for: 117e21121e
