Age | Commit message (Collapse) | Author | Files | Lines |
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41252
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
|
|
|
|
Bug-Gentoo: https://bugs.gentoo.org/show_bug.cgi?id=507232
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=81043
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
|
|
There is no point to attemp a reload if the system bus is not running and
we avoid a warning upon initial installation this way.
Update the comment to reflect recent changes.
|
|
|
|
update-rc.d/invoke-rc.d as added by dh_installinit. This prevent some odd-corner when being triggered during init system upgrade (Closes: #754404)
|
|
|
|
- fix two local DoS vulnerabilities (CVE-2014-3532, CVE-2014-3533)
|
|
Upstream version 1.8.6
|
|
|
|
|
|
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>
|
|
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=74698
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
|
|
|
|
|
|
Upstream version 1.8.4
|
|
|
|
|
|
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>
|
|
|
|
|
|
Upstream version 1.8.2
|
|
|
|
|
|
On W32 dbus daemon will print output in text mode, with 0x0d0a EOLs instead
of just 0x0a. Be able to handle that.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75863
Reviewed-by: Simon McVittie
|
|
|
|
The timeline of events in dbus-launch's main process goes something like this:
* do initial X calls
[1]
* do some other stuff
* fork
(child process starts doing some other stuff)
* return "intermediate parent" pid from fork()
* obtain bus daemon pid from bus_pid_to_launcher_pipe
[2]
* do things that might include X11 calls or killing the dbus-daemon
Meanwhile, the "babysitter" child goes like this:
* return 0 from fork()
[3]
* obtain bus daemon pid from parent process via bus_pid_to_babysitter_pipe
[4]
* do things that might include X11 calls or killing the bus daemon
Before [1] or [3], the right thing to do about an X error is to just
exit. The current implementation called kill(-1) first, which is
undesirable: it kills unrelated processes. With this change, we
just exit.
After [2] or [4], the right thing to do is to kill the dbus-daemon,
and that's what the existing code did.
Between [1] and [2], or between [3] and [4], there is no correct thing
that we can do immediately: we would have to wait for the end of the
"critical section", *then* kill the dbus-daemon. This has not yet been
implemented, so this patch relies for its correctness on the fact that
there are no libX11 calls between those points, so we cannot receive
an X error between them.
dbus-launch deserves more comments, or a reimplementation that is easier to
understand, but this change is certainly better than nothing.
[Commit message added, summarizing reviewers' comments -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=74698
Reviewed-by: Simon McVittie
Reviewed-by: Thiago Macieira
|
|
|
|
Enhances usability under systemd by making the documentation available
with systemctl status or systemctl help.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=77447
Reviewed-by: Simon McVittie
|
|
It's least confusing if the two files have the same contents. systemd
already knows how to pick up our /var/lib/dbus/machine-id if it exists
and /etc/machine-id doesn't, but the converse is not currently true.
We should make it true, so that it doesn't matter what order
systemd-machine-id-setup and "dbus-uuidgen --ensure" were
invoked in.
In Debian, systemd currently Recommends dbus, so "dbus-uuidgen --ensure"
will *usually* - but not always! - run first, and the two files will
match. However, if you install systemd without dbus, and then install
dbus later, there will be a mismatch. With this change, it doesn't
matter which one is installed first: whichever one happens to come
first, it will generate the machine ID, and then the other one will
copy it.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=77941
Reviewed-by: Lennart Poettering
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=77941
Reviewed-by: Lennart Poettering
|
|
- use a shell wildcard instead of dpkg-architecture, to avoid stderr spam
failing the test if gcc is missing
- wrap each test-case in an arbitrary (5 minute) timeout so that one
test-case failing won't halt the whole build
|
|
I no longer have the email address davidz@redhat.com so update it to
my current address.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75288
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75833
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
|
|
|
|
|
|
|
|
|
|
|
|
* Hook up the installed tests to DEP-8 metadata
* Add a simple compile/link/run test
|
|
|
|
/etc/dbus-1/system.d that calls ReloadConfig on the system dbus-daemon, in case our inotify monitoring isn't completely reliable (see #740139)
|
|
|
|
installed unless libsystemd*-dev are found)
|
|
|
|
[Slightly modified by -rh]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71297
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
|
|
Linux.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41252
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
|
|
|