GitLab

This feature is now compile-time conditional, and off by default.

pam_console appears to have been in Fedora and Gentoo until 2007.
pam_foreground seems to be specific to Debian and Ubuntu, where it was
unmaintained since 2008 and removed in 2010. The replacement for both
was ConsoleKit, which has itself been superseded by systemd-logind and
ConsoleKit2.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/101629Reviewed-by: Philip Withnall <withnall@endlessm.com>

It's initialized to a non-trivial value whenever container_type
is DBUS_TYPE_DICT_ENTRY, and subsequently only used if
container_type is DBUS_TYPE_DICT_ENTRY, but Debian's gcc 7.2.0-7
doesn't seem to be able to infer that any more, causing build failure
under -Werror=maybe-uninitialized.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102979Reviewed-by: Philip Withnall <withnall@endlessm.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

This means we respect the destination keyword in arguments to
BecomeMonitor.

In bus_dispatch(), this means that we need to defer capturing until
we have decided whether there is an addressed recipient; so instead
of capturing once, we capture at each leaf of the decision tree.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92074Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Reviewed-by: Lars Uebernickel <lars@uebernic.de>
(cherry picked from commit f3be583b)
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/92853Reviewed-by: Philip Withnall <withnall@endlessm.com>

If we add a rule like

    <allow send_destination="com.example" send_broadcast="true"/>

then it cannot possibly match anything, because to be a broadcast, the
message would have to have no destination. The only value of
send_destination that can be combined with send_broadcast="true" is
the wildcard "*", but by this point in the function we already
replaced "*" with NULL.

Adapted from an earlier implementation of send_broadcast by
Alban Crequy.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/92853Reviewed-by: Philip Withnall <withnall@endlessm.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

This is a better match for the way we use it in practice.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102686Reviewed-by: Philip Withnall <withnall@endlessm.com>

dbus-sysdeps-unix.c: In function ‘_dbus_read_credentials_socket’:
dbus-sysdeps-unix.c:2061:9: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
         adt_session_data_t *adth = NULL;
         ^
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102145Reviewed-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@debian.org>

Previously, the listen() backlog was set to an arbitrary 30. This means
that if dbus-daemon is overloaded only 30 more connections may be queued
by the kernel, before connect() fails with EAGAIN. (Note that EAGAIN !=
EINPROGRESS -- the latter is what is returned if a connection is queued
and being processed for asynchronous sockets; EAGAIN in this case is
really an error, that cannot be recovered from).

Most software simply sets SOMAXCONN as backlog for AF_UNIX sockets, to
allow queuing of as many connections as the kernel allows. SOMAXCONN is
128 on Linux, which is not particularly high, but at least higher than
30.

This patch changes dbus-daemon to do the same.

I noticed this when flooding dbus-daemon with a lot of connections,
where it pretty quickly ceased to respond, much earlier than it really
should.

Note that the backlog has nothing to do with the number of concurrent
connections allowed, it simply controls how many queued, but not
accept()ed connections there may be on the listening socket.

(cherry picked from commit 12bd6e89)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=95264
Bug-Debian: https://bugs.debian.org/872144Reviewed-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Thiago Macieira <thiago@kde.org>

This is just enough to demonstrate that they work - I'm deliberately
not doing a mass change throughout all tests, and we should definitely
not rush to introduce these into production code, because it would
hinder cherry-picking and merging fixes between branches. However,
new code on master can use them freely.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101895

These are inspired by GLib's g_clear_pointer() and g_clear_object(),
which in turn is descended from CPython's Py_CLEAR_OBJECT. They should
make our code a lot less repetitive.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101895

We use this directory as the temporary home directory.

Fixes: 3f377c51Signed-off-by: Simon McVittie <smcv@debian.org>

This lets cooperating processes with the same value of $HOME
interoperate for DBUS_COOKIE_SHA1 by reading and writing $HOME, even
if their $HOME differs from the uid's "official" home directory
according to getpwuid(). Out of paranoia, we only do this if the uid
and the euid are equal, since if they were unequal the correct thing
to do would be ambiguous.

In particular, Debian autobuilders run as a user whose "official"
home directory in /etc/passwd is "/nonexistent", as a mechanism to
detect non-deterministic build processes that rely on the contents of
the home directory. Until now, this meant we couldn't run dbus'
build-time tests, because every test that used DBUS_COOKIE_SHA1 would
fail in this environment.

In the tests, set HOME as well as DBUS_TEST_HOMEDIR. We keep
DBUS_TEST_HOMEDIR too, because Windows doesn't use HOME, only HOMEDRIVE
and HOMEPATH.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101960
Bug-Debian: https://bugs.debian.org/630152Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Philip Withnall <withnall@endlessm.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101848Reviewed-by: Thiago Macieira <thiago@kde.org>
[smcv: Revert an incorrect comment change]
Signed-off-by: Simon McVittie <smcv@collabora.com>

This test-case is actually in the test for monitoring the bus,
because it's easier to see what's going on there - the error reply
to a rejected broadcast is not visible unless you are monitoring.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92853

<allow send_broadcast="true" ...> only matches broadcasts,
which are signals with a NULL destination. There was previously
no way for the policy language to express "NULL destination",
only "any destination".

<allow send_broadcast="false" ...> only matches non-broadcasts,
which are non-signals or signals with a non-NULL destination.
There was previously no way for the policy language to express
"any non-NULL destination", only "any destination".
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: improved documentation as per Philip's review]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92853

Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92853

We don't allow sending unrequested replies, but the documentation
implied that we did.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92853

Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92853

Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92853

Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92853

Until the previous commit, this would have worked. Now it correctly fails
with "send and receive attributes cannot be combined".
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92853

The giant conditionals used to check policy attributes are increasingly
unwieldy, so let's try something else. Bundle together the send_
attributes, the receive_ attributes, the eavesdrop attribute
(which can go on either send or receive rules) and the other attributes
into equivalence classes, and write the conditionals in terms of those
equivalence classes.

In particular, this correctly forbids
    <allow receive_type="..." send_destination="..."/>
which was previously allowed but nonsensical (the send part took
precedence and the receive part was ignored).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92853

By default, Expat uses cryptographic-quality random numbers as a salt for
its hash algorithm, and since 2.2.1 it gets them from the getrandom
syscall on Linux. That syscall refuses to return any entropy until the
kernel's CSPRNG (random pool) has been initialized. Unfortunately, this
can take as long as 40 seconds on embedded devices with few entropy
sources, which is too long: if the system dbus-daemon blocks for that
length of time, important D-Bus clients like systemd and systemd-logind
time out and fail to connect to it.

We're parsing small configuration files here, and we trust them
completely, so we don't need to defend against hash collisions: nobody
is going to be crafting them to cause pathological performance.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101858Tested-by: Christopher Hewitt <hewitt@ieee.org>
[smcv: Adjust build-system changes for 1.11.x]
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Philip Withnall <withnall@endlessm.com>

By default, Expat uses cryptographic-quality random numbers as a salt for
its hash algorithm, and since 2.2.1 it gets them from the getrandom
syscall on Linux. That syscall refuses to return any entropy until the
kernel's CSPRNG (random pool) has been initialized. Unfortunately, this
can take as long as 40 seconds on embedded devices with few entropy
sources, which is too long: if the system dbus-daemon blocks for that
length of time, important D-Bus clients like systemd and systemd-logind
time out and fail to connect to it.

We're parsing small configuration files here, and we trust them
completely, so we don't need to defend against hash collisions: nobody
is going to be crafting them to cause pathological performance.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101858Signed-off-by: Simon McVittie <smcv@debian.org>
Tested-by: Christopher Hewitt <hewitt@ieee.org>
Reviewed-by: Philip Withnall <withnall@endlessm.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>