In D-Bus, clients connect to a bus (the usual case), or use direct
questions to each other (the unusual case). A bus is a program one can
connect to and implemented by dbus-daemon or dbus-broker. HOwever,
busses never connect between each other, that doesn't exist. Hence don't
claim so.
This is probably confusion about the fact that sd-bus calls D-Bus
connection objects just "sd_bus" for simplicity, given they are used in
99% of the cases to connect to a bus — only in exceptional cases they
are used for direct connections between peers without involving a bus.
Follow-up for b7bb58ef70
This basically reverts #22079.
Stopping the watchdog is wrong. The reboot watchdog is supposed to cover
the whole time from the point when systemd start systemd-reboot until the
hardware resets.
Otherwise the system may hang in the final shutdown phase.
Add a comment, why keeping the watchdog running is correct here.
If watchdog_set_device() is not called before open_watchdog() then
'watchdog_device' remains 'NULL' while the device is open.
As a result, the "same device" check in watchdog_set_device() does not work
correctly: If no device is specified (e.g. from watchdog_free_device())
then the current fd is not closed.
Fix this by setting 'watchdog_device' to the correct device during
open_watchdog()
Since a long time the D-Bus spec knows a special bit in its message
header for indicating that "interactive" authentication is OK. The
original hostnamed API is before that was added hence most functions
expose that boolean as explicit argument.
For new added functions let's get rid of it, the message flag is good
enough and replaces it with complete functionality.
No new APIs should carry the "interactive" boolean flag explicitly as
argument anymore.
Follow-up for: 9697662915
The warning is correct, since we don't inherit the necessary
unittest.TestCase class, but that's on purpose, since the Utilities
class is not supposed to be instantiated on its own, but should
complement other classes' definitions which do inherit from the
unittest.TestCase class.
It currently works because `\(` and `\)` are not valid escape sequences,
so they're not treated differently. Using raw strings (or double
backslashes) is a more correct solution.
Multiline comments are converted to docstrings only when they're the
first statement in a function/method. Even though they're still a no-op
otherwise, let's use "true" comments to make pylint happy.
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 :-)
Lennart Poettering
Ruben Kerkhof
Michael Olbrich
Davide Cavalca
Luca Boccassi
Anita Zhang
Jan Janssen
Frantisek Sumsal
Leviticoh
Evgeny Vereshchagin
Yu Watanabe
Daan De Meyer