- 03 Dec, 2018 4 commits
-
-
Thomas Zimmermann authored
Signed-off-by:
Thomas Zimmermann <tdz@users.sourceforge.net> Reviewed-by:
Simon McVittie <smcv@debian.org> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357 (cherry picked from commit ddbc44ad)
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is technically a denial of service because the dbus-daemon will run out of memory eventually, but it's a very slow and noisy one, because all the rejected messages are also very likely to have been logged to the system log. Detected by AddressSanitizer. Signed-off-by:
Simon McVittie <smcv@collabora.com> Resolves: #234 Reviewed-by: pwithnall
-
- 05 Oct, 2018 1 commit
-
-
Simon McVittie authored
-
- 04 Oct, 2018 9 commits
-
-
Simon McVittie authored
This should avoid them overwriting each other. Signed-off-by:
Simon McVittie <smcv@collabora.com> (cherry picked from commit e3fb0858)
-
Simon McVittie authored
freedesktop.org Gitlab doesn't currently have enough test runners available to run all of this every time. For higher-risk changes (for example those that change the build system) we can run the complete set through the web UI. Signed-off-by:
Simon McVittie <smcv@collabora.com> (cherry picked from commit a2f416c2)
-
Simon McVittie authored
We test the combinations that we don't test on Travis-CI. Signed-off-by:
Simon McVittie <smcv@collabora.com> (cherry picked from commit a6d926b8)
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com> (cherry picked from commit d0728fd0)
-
Simon McVittie authored
This uses the same shell scripts as Travis-CI, with slightly different settings. We use Docker containers for all our Gitlab-CI runs, so take the opportunity to use Debian 9 'stretch' as our baseline, and relegate Ubuntu 14.04 'trusty' to to a secondary build. Signed-off-by:
Simon McVittie <smcv@collabora.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=108177Acked-by:
Philip Withnall <withnall@endlessm.com> (cherry picked from commit 60933c09)
-
Simon McVittie authored
Travis-CI workers have cmake preinstalled, but Gitlab-CI Docker images typically don't. Signed-off-by:
Simon McVittie <smcv@collabora.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=108177Acked-by:
Philip Withnall <withnall@endlessm.com> (cherry picked from commit 907832e0)
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=108177Acked-by:
Philip Withnall <withnall@endlessm.com> (cherry picked from commit 408b222a)
-
Ralf Habacker authored
Signed-off-by:
Ralf Habacker <ralf.habacker@freenet.de> Reviewed-by:
Simon McVittie <smcv@collabora.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105662 (cherry picked from commit d22e7901)
-
Simon McVittie authored
In the debug build, enable features that are off by default. In the reduced build, explicitly disable features, some of which are on by default. In the legacy build, check that we can compile the default feature-set without inotify, dnotify, systemd, etc. Reviewed-by:
Philip Withnall <withnall@endlessm.com> [smcv: Rebase onto 1.13.x branch, fix minor conflicts] Signed-off-by:
Simon McVittie <smcv@collabora.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354 (cherry picked from commit 3c031ef5)
-
- 30 Aug, 2018 2 commits
-
-
Simon McVittie authored
-
Simon McVittie authored
As noted in GLib commit c879f50f, gcc's interpretation of the malloc attribute has become more strict over time, which could result in miscompilation. The new definition is that in addition to assuming that the returned memory block is newly-allocated, gcc now assumes that it does not contain any valid pointers. This is OK for uninitialized or zero-initialized memory returned by dbus_malloc() or dbus_malloc0(), but not valid for dbus_realloc(), which might be used for a dynamically-sized array of (structures containing) valid pointers. See https://gitlab.gnome.org/GNOME/glib/issues/1465Signed-off-by:
Simon McVittie <smcv@collabora.com> Reviewed-by:
Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107741
-
- 03 Aug, 2018 1 commit
-
-
Simon McVittie authored
As usual, the next release from this branch will be 1.10.28.
-
- 02 Aug, 2018 5 commits
-
-
Simon McVittie authored
-
Simon McVittie authored
Running the "embedded tests" through valgrind revealed that before this commit, we would have been willing to read up to 3 bytes off the end of a message if the message is truncated part way through a boolean. Any practical allocator will round up allocations to the next 32-bit (or larger) boundary, so in practice this will not leave the memory buffer (and in particular did not crash during unit testing), but it could read uninitialized contents. On little-endian CPUs, an attacker might be able to use this to learn whether up to 3 bytes of uninitialized memory in the dbus-daemon were all-zero (their crafted message would be relayed) or not (their connection would be disconnected for sending an invalid message). On big-endian CPUs, an attacker might be able to use this to learn whether up to 3 bytes were all-zeroes (relayed to a cooperating peer), 0-2 bytes of all-zeroes followed by 0x01 (relayed to a cooperating peer), or something else (disconnected). This is not believed to be exploitable to leak interesting information. Fixes: 62e46533 "hardcode dbus_bool_t to 32 bits" Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107332Signed-off-by:
Simon McVittie <smcv@collabora.com> Reviewed-by:
Thiago Macieira <thiago@kde.org> Reviewed-by:
Philip Withnall <withnall@endlessm.com> (cherry picked from commit e93a775e)
-
Simon McVittie authored
-
Simon McVittie authored
Using strncpy (buffer, str, strlen (str)) is a "code smell" that might indicate a serious bug (it effectively turns strncpy into strcpy), and gcc 8 now warns about it. In fact we avoided the bug here, but it wasn't at all obvious. We already checked that path_len is less than or equal to _DBUS_MAX_SUN_PATH_LENGTH, which is 99, chosen to be strictly less than the POSIX minimum sizeof(sun_path) >= 100, so we couldn't actually be overflowing the available buffer. The new static assertion in this commit matches a comment above the definition of _DBUS_MAX_SUN_PATH_LENGTH: we define _DBUS_MAX_SUN_PATH_LENGTH to 99, because POSIX says struct sockaddr_un's sun_path member is at least 100 bytes (including space for a \0 terminator). dbus will now fail to compile on platforms that are non-POSIX-compliant in this way, except for Windows. We zeroed the struct sockaddr_un before writing into it, so stopping one byte short of the end of sun_path ensures that we get \0 termination. Signed-off-by:
Simon McVittie <smcv@collabora.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107350Reviewed-by:
Thiago Macieira <thiago@kde.org> Reviewed-by:
Philip Withnall <withnall@endlessm.com> (cherry picked from commit f4296313)
-
Simon McVittie authored
The foreach(list, (DBusForeachFunction) free, NULL) idiom seems too entrenched to remove it from stable branches. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107349Signed-off-by:
Simon McVittie <smcv@collabora.com> Reviewed-by:
Philip Withnall <withnall@endlessm.com>
-
- 01 Mar, 2018 1 commit
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- 23 Feb, 2018 1 commit
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- 21 Feb, 2018 4 commits
-
-
Simon McVittie authored
Reviewed-by:
David King <dking@redhat.com> [smcv: Fix typo in cmake macro name] Signed-off-by:
Simon McVittie <smcv@collabora.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105165 (cherry picked from commit 49ca4219)
-
Simon McVittie authored
This gives us feature parity with the Autotools build system for this particular area, and in particular means a system dbus-daemon built with cmake can expand its fd limit. Signed-off-by:
Simon McVittie <smcv@collabora.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105165 (cherry picked from commit a146724f)
-
David King authored
Startup ordering was changed in #92832 to ensure that SELinux audit messages could be sent. As a side effect, the raising of file descriptor limits was moved to after the dropping of root privileges, resulting in the limit change always failing. Move the raise_file_descriptor_limit() call to ensure that it is called before dropping root privileges. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105165 Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1529044 [smcv: Call raise_file_descriptor_limit() even if !context->user] Reviewed-by:
Simon McVittie <smcv@collabora.com> (cherry picked from commit 6e42964f)
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- 28 Sep, 2017 1 commit
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com> (cherry picked from commit ed38caa7)
-
- 27 Sep, 2017 1 commit
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com> (cherry picked from commit c6e79f91)
-
- 25 Sep, 2017 6 commits
-
-
Simon McVittie authored
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
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>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
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>
-
- 15 Aug, 2017 4 commits
-
-
Simon McVittie authored
-
Alan Coopersmith authored
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>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@debian.org>
-
Lennart Poettering authored
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>
-