The differences has been found out by comparing with the cross compiled
mingw..-dbus packages.
[exclude system bus support bits on Windows -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83583
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
On Unix, the thing that can be made close-on-exec is a file descriptor,
which is an int.
On Windows, the thing that can be made close-on-exec is a HANDLE,
which is pointer-sized (but not necessarily a pointer!). In practice,
on Windows we only called _dbus_fd_set_close_on_exec() on socket
pseudo-file-descriptors (SOCKET, which is an unsigned int);
every SOCKET can validly be cast to HANDLE, but not every HANDLE
is a SOCKET.
Before this commit we used an intptr_t as a sort of fake
union { int; HANDLE; }, which just obscures what's going on.
In practice, everything that called _dbus_fd_set_close_on_exec()
is really platform-specific anyway, so let's just have two separate
functions and call this solved.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39610
This requires a little bit of code re-ordering, because
_DBUS_STATIC_ASSERT can appear anywhere that a variable declaration
would be valid, i.e. not after executable code.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83767
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
This means we can use _DBUS_STATIC_ASSERT at non-global scope without
tripping -Wunused-local-typedefs.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83767
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Whenever I forget to turn off corekeeper, the regression tests
take ages to record all test-segfault's crashes.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83772
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
systemd 209 merged all the libraries to libsystemd. Old
libraries can still be enabled with --enable-compat-libs
switch in systemd but this increases the binary size.
Implement a fallback library check in case compat libraries
dont exist.
[Fixed underquoting; switched priority so we try libsystemd first -smcv]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This patch doesn't do any function change, but only the function name,
to align its name with the struct RestorePendingData.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=72254
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
DBUS_TYPE_G_BYTE_ARRAY does not exist. It should be DBUS_TYPE_G_UCHAR_ARRAY
Signed-off-by: Thomas Haller <thaller@redhat.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80795
Since Linux commit 25888e (from 2.6.37-rc4, Nov 2010), sendmsg() on Unix
sockets returns -1 errno=ETOOMANYREFS ("Too many references: cannot splice")
when the passfd mechanism (SCM_RIGHTS) is "abusively" used recursively by
applications. A malicious client could use this to force a victim system
service to be disconnected from the system bus; the victim would likely
respond by exiting. This is a denial of service (fd.o #80163,
CVE-2014-3532).
This patch silently drops the D-Bus message on ETOOMANYREFS and does not close
the connection.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80163
Reviewed-by: Thiago Macieira <thiago@kde.org>
[altered commit message to explain DoS significance -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
There were two bugs here: we would previously overwrite the unused
fds with the already-used fds instead of the other way round, and
we would copy n bytes where we should have copied n ints.
Additionally, sending crafted messages in a chosen sequence to a victim
system service could cause an invalid file descriptor to be present
when dbus-daemon tries to forward one of those crafted messages to the
victim, causing sendmsg() to fail with EBADF, which resulted in
disconnecting the victim service, which would likely respond to that
by exiting. This is a denial of service (fd.o #80469, CVE-2014-3533).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=79694
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80469
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
On Linux, poll accepts any negative value as infinity.
On at least FreeBSD and NetBSD, only -1 is acceptable.
[adjusted whitespace for correct coding style -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=78480
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
How it should work:
When a D-Bus message activates a service, LSMs (SELinux or AppArmor) check
whether the message can be delivered after the service has been activated. The
service is considered activated when its well-known name is requested with
org.freedesktop.DBus.RequestName. When the message delivery is denied, the
service stays activated but should not receive the activating message (the
message which triggered the activation). dbus-daemon is supposed to drop the
activating message and reply to the sender with a D-Bus error message.
However, it does not work as expected:
1. The error message is delivered to the service instead of being delivered to
the sender. As an example, the error message could be something like:
An SELinux policy prevents this sender from sending this
message to this recipient, [...] member="MaliciousMethod"
If the sender and the service are malicious confederates and agree on a
protocol to insert information in the member name, the sender can leak
information to the service, even though the LSM attempted to block the
communication between the sender and the service.
2. The error message is delivered as a reply to the RequestName call from
service. It means the activated service will believe it cannot request the
name and might exit. The sender could activate the service frequently and
systemd will give up activating it. Thus the denial of service.
The following changes fix the bug:
- bus_activation_send_pending_auto_activation_messages() only returns an error
in case of OOM. The prototype is changed to return TRUE, or FALSE on OOM
(and its only caller sets the OOM error).
- When a client is not allowed to talk to the service, a D-Bus error message
is pre-allocated to be delivered to the client as part of the transaction.
The error is not propagated to the caller so RequestName will not fail
(except on OOM).
[fixed a misleading comment -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=78979
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
