As general principle, we generally check command line args first, the
enviroment second, and external configuration and system state only later.
In case of the invocation ID, checking the keyring before the environment
was implemented as a poor-man's security measure. But this is not really
useful, since we're moving within the same security boundary. So let's just
do the expected thing, and check environment first.
Prompted by https://github.com/systemd/systemd/pull/11991#issuecomment-474647652.
Fixes#12036.
../../../src/systemd/src/libsystemd/sd-bus/bus-objects.c: In function ‘add_object_vtable_internal’:
../../../src/systemd/src/basic/macro.h:423:19: error: duplicate case value
Introduced in 6d586a1371.
Reported by Felix Riemann in https://bugzilla.redhat.com/show_bug.cgi?id=1685286.
Reproducer:
for i in `seq 1 100`; do gdbus call --session -d org.freedesktop.systemd1 -m org.freedesktop.systemd1.Manager.StartUnit -o "/$(for x in `seq 0 28000`; do echo -n $x; done)" & done
The dbus external authentication takes as optional argument the UID the
sender wants to authenticate as. This uid is purely optional. The
AF_UNIX socket already conveys the same information through the
auxiliary socket data, so we really don't have to provide that
information.
Unfortunately, there is no way to send empty arguments, since they are
interpreted as "missing argument", which has a different meaning. The
SASL negotiation thus changes from:
AUTH EXTERNAL <uid>
NEGOTIATE_UNIX_FD (optional)
BEGIN
to:
AUTH EXTERNAL
DATA
NEGOTIATE_UNIX_FD (optional)
BEGIN
And thus the replies we expect as a client change from:
OK <server-id>
AGREE_UNIX_FD (optional)
to:
DATA
OK <server-id>
AGREE_UNIX_FD (optional)
Since the old sd-bus server implementation used the wrong reply for
"AUTH" requests that do not carry the arguments inlined, we decided to
make sd-bus clients accept this as well. Hence, sd-bus now allows
"OK <server-id>\r\n" replies instead of "DATA\r\n" replies.
Signed-off-by: David Rheinsberg <david.rheinsberg@gmail.com>
The correct way to reply to "AUTH <protocol>" without any payload is to
send "DATA" rather than "OK". The "DATA" reply triggers the client to
respond with the requested payload.
In fact, adding the data as hex-encoded argument like
"AUTH <protocol> <hex-data>" is an optimization that skips the "DATA"
roundtrip. The standard way to perform an authentication is to send the
"DATA" line.
This commit fixes sd-bus to properly send the "DATA" line. Surprisingly
no existing implementation depends on this, as they all pass the data
directly as argument to "AUTH". This will not work if we want to pass
an empty argument, though.
Signed-off-by: David Rheinsberg <david.rheinsberg@gmail.com>
Previously, 'degraded' state is ambiguous for bonding or bridge master:
1. one or more slave interfaces does not have carrier,
2. no link local address is assigned to the master,
3. combination of the above two.
This makes the above case 1 and 3 are in the new 'degraded-carrier'
state, and makes 'degraded' state as all slaves are active but no
link local address on master.
When enabled, three samples are used to determine the value of a
received bit by majority rule.
This patch adds support for the TripleSampling= option in the [CAN]
section of .network files.
Same as with the other users, any non-trivial use of the objects requires
use from a single thread only or external locking. Using atomic operations
just for reference counts is not useful.
The sd-hwdb objects cannot be used concurrently from two threads in any
meaningful way, because query and iteration operations modify the object.
Thus atomic reference counts are pointless.
We had atomic counters, but all other operations were non-serialized. This
means that concurrent access to the bus object was only safe if _all_ threads
were doing read-only access. Even sending of messages from threads would not be
possible, because after sending of the message we usually want to remove it
from the send queue in the bus object, which would race. Let's just kill this.
Before this commit bus messages had a single reference count: when it
reached zero the message would be freed. This simple approach meant a
cyclic dependency was typically seen: a message that was enqueued in a
bus connection object would reference the bus connection object but also
itself be referenced by the bus connection object. So far out strategy
to avoid cases like this was: make sure to process the bus connection
regularly so that messages don#t stay queued, and at exit flush/close
the connection so that the message queued would be emptied, and thus the
cyclic dependencies resolved. Im many cases this isn't done properly
however.
With this change, let's address the issue more systematically: let's
break the reference cycle. Specifically, there are now two types of
references to a bus message:
1. A regular one, which keeps both the message and the bus object it is
associated with pinned.
2. A "queue" reference, which is weaker: it pins the message, but not
the bus object it is associated with.
The idea is then that regular user handling uses regular references, but
when a message is enqueued on its connection, then this takes a "queue"
reference instead. This then means that a queued message doesn't imply
the connection itself remains pinned, only regular references to the
connection or a message associated with it do. Thus, if we end up in the
situation where a user allocates a bus and a message and enqueues the
latter in the former and drops all refs to both, then this will detect
this case and free both.
Note that this scheme isn't perfect, it only covers references between
messages and the busses they are associated with. If OTOH a bus message
is enqueued on a different bus than it is associated with cyclic deps
cannot be recognized with this simple algorithm, and thus if you enqueue
a message associated with a bus A on a bus B, and another message
associated with bus B on a bus A, a cyclic ref will be in effect and not
be discovered. However, given that this is an exotic case (though one
that happens, consider systemd-bus-stdio-bridge), it should be OK not to
cover with this, and people have to explicit flush all queues on exit in
that case.
Note that this commit only establishes the separate reference counters
per message. A follow-up commit will start making use of this from the
bus connection object.
Don't try to be smart, don't bypass the ref counting logic if there's no
real reason to.
This matters if we want to tweak the ref counting logic later.
Let's make sure our own code follows coding style and initializes all
return values on all types of success (and leaves it uninitialized in
all types of failure).
Let's do this like we usually do and size arrays with size_t.
We already do this for the "allocated" counter correctly, and externally
we expose the queue sizes as uint64_t anyway, hence there's really no
point in usigned "unsigned" internally.
Apparently this happens IRL. Let's carefully deal with issues like this:
when we overrun, let's not go back to zero but instead leave the highest
cookie bit set. We use that as indication that we are in "overrun
territory", and then are particularly careful with checking cookies,
i.e. that they haven't been used for still outstanding replies yet. This
should retain the quick cookie generation behaviour we used to have, but
permits dealing with overruns.
Replaces: #11804Fixes: #11809
Paths are limited to BUS_PATH_SIZE_MAX but the maximum size is anyway too big
to be allocated on the stack, so let's switch to the heap where there is a
clear way to understand if the allocation fails.
Even though the dbus specification does not enforce any length limit on the
path of a dbus message, having to analyze too long strings in PID1 may be
time-consuming and it may have security impacts.
In any case, the limit is set so high that real-life applications should not
have a problem with it.
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Yu Watanabe
David Rheinsberg
Susant Sahani
Clemens Gruber
Giacinto Cifelli
Riccardo Schirone