dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2024-02-23T20:15:34Zhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/201Containers message filtering/policy (#101902): basic, strict policy2024-02-23T20:15:34ZBugzilla Migration UserContainers message filtering/policy (#101902): basic, strict policy## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#105656)](https://bugs.freedesktop.org/show_bug.cgi?id=105656)**
## Description
+++ This bug was initially created as a clone of Bug #101902 ++...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#105656)](https://bugs.freedesktop.org/show_bug.cgi?id=105656)**
## Description
+++ This bug was initially created as a clone of Bug #101902 +++
As a starting point for T7327, implement the most basic form of the Allow named argument: an empty list of things to allow.
This is planned to have the following semantics:
* Things that are unconditionally allowed are allowed
* Anything that is conditional is forbidden
Version: git master
### Blocking
* [Bug 101902](https://bugs.freedesktop.org/show_bug.cgi?id=101902)
* [Bug 105657](https://bugs.freedesktop.org/show_bug.cgi?id=105657)
* [Bug 105658](https://bugs.freedesktop.org/show_bug.cgi?id=105658)https://gitlab.freedesktop.org/dbus/dbus/-/issues/202Containers message filtering/policy (#101902): control over receiving Unix fds2023-09-06T17:04:39ZBugzilla Migration UserContainers message filtering/policy (#101902): control over receiving Unix fds## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105657)](https://bugs.freedesktop.org/show_bug.cgi?id=105657)**
## Description
+++ This bug was initially created as a clone of Bug #101902...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105657)](https://bugs.freedesktop.org/show_bug.cgi?id=105657)**
## Description
+++ This bug was initially created as a clone of Bug #101902 +++
Allow rules (see Bug #101902) need to be able to opt-in to a container instance receiving Unix fds.
To be designed
==============
One of:
* The rule's object path, bus name, interface must match the message
* The bus name must match but the object path and interface must be non-specific
* The object path, bus name, interface must be non-specific
One of:
* The flag works for both method calls and unicast signals and does not differentiate (this is a bit odd if filtering by path or interface is allowed, because they have different meanings in each direction)
* The flag is split into RECEIVE_UNIX_FD_METHOD_CALLS and RECEIVE_UNIX_FD_SIGNALS
* RECEIVE_UNIX_FDS is assumed to mean method calls because putting fds in signals is silly
Out of scope
============
* Sending Unix fds
* Receiving Unix fds in broadcast signals (which is ridiculous)
Version: git master
### Depends on
* [Bug 105656](https://bugs.freedesktop.org/show_bug.cgi?id=105656)
### Blocking
* [Bug 101902](https://bugs.freedesktop.org/show_bug.cgi?id=101902)https://gitlab.freedesktop.org/dbus/dbus/-/issues/203Containers message filtering/policy (#101902): SEE access control2023-09-06T17:04:39ZBugzilla Migration UserContainers message filtering/policy (#101902): SEE access control## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#105658)](https://bugs.freedesktop.org/show_bug.cgi?id=105658)**
## Description
+++ This bug was initially created as a clone of Bug #101902 ++...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#105658)](https://bugs.freedesktop.org/show_bug.cgi?id=105658)**
## Description
+++ This bug was initially created as a clone of Bug #101902 +++
Implement the SEE access-control model as a step towards Bug #101902.
* Allow list can contain tuples with SEE flag and bus name
* If a contained peer calls ListActivatableNames, ListNames,
NameHasOwner or GetNameOwner, names that it can SEE are not
treated as if they didn't exist
* A contained peer can see NameOwnerChanged signals where the
name in question is one that it can SEE
* If a contained peer can SEE a well-known name, then it can SEE the unique
name that owns that well-known name too (the primary owner)
* If a contained peer receives a method call or unicast signal from
outside the container, then it receives SEE access to the sender's unique name
* Add a named parameter or a special allow rule that lets the contained peer SEE every unique name
* Bus name can be "" to match anything
* Bus name can be combined with BUS_NAME_IS_SUBTREE flag to match like arg0namespace
* Object path is ignored for SEE checks
* Interface is ignored for SEE checks
To be designed
==============
One of these:
* If a contained peer can SEE a well-known name, then it can SEE every
unique name in the queue for that well-known name
* If a contained peer can SEE a well-known name, this does not affect
whether it can SEE unique names that are in the queue for the
well-known name but are not the primary owner
Version: git master
### Depends on
* [Bug 105656](https://bugs.freedesktop.org/show_bug.cgi?id=105656)
### Blocking
* [Bug 101902](https://bugs.freedesktop.org/show_bug.cgi?id=101902)
* [Bug 105659](https://bugs.freedesktop.org/show_bug.cgi?id=105659)
* [Bug 105660](https://bugs.freedesktop.org/show_bug.cgi?id=105660)https://gitlab.freedesktop.org/dbus/dbus/-/issues/204Containers message filtering/policy (#101902): control over messages leaving ...2023-09-06T17:04:39ZBugzilla Migration UserContainers message filtering/policy (#101902): control over messages leaving container## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105659)](https://bugs.freedesktop.org/show_bug.cgi?id=105659)**
## Description
+++ This bug was initially created as a clone of Bug #101902...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105659)](https://bugs.freedesktop.org/show_bug.cgi?id=105659)**
## Description
+++ This bug was initially created as a clone of Bug #101902 +++
[ ] Can add rules to give a contained app permission to send method calls
[ ] ... to any bus name
[ ] ... to specified bus names
[ ] ... only if they are to a specified object path
[ ] ... only if they are to a specified object path hierarchy (OBJECT_PATH_IS_SUBTREE flag)
[ ] ... only if they are on a specified interface
[ ] ... only if they are a specified member of a specified interface
[ ] Sending Unix fds is only allowed if a rule with the SEND_UNIX_FDS flag allows it
[ ] Can add rules to give a contained app permission to send unicast signals
[ ] ... to any bus name
[ ] ... to specified bus names
[ ] ... only if they are from a specified object path
[ ] ... only if they are from a specified object path hierarchy
[ ] ... only if they are from a specified interface
[ ] ... only if they are a specified member of a specified interface (INTERFACE_IS_REALLY_MEMBER flag, or some better name)
[ ] Can add rules to give a contained app permission to send broadcast signals outside its own container instance
[ ] ... only if they are from a specified object path
[ ] ... only if they are from a specified object path hierarchy
[ ] ... only if they are from a specified interface
[ ] ... only if they are a specified member of a specified interface
[ ] Failing to send a broadcast does not return an error to the caller at all
[ ] Failing to send a broadcast to an interested connection does notify monitors
[ ] Each method call sent can have exactly 1 reply, unless it has NO_REPLY_EXPECTED
[ ] If the sender cannot even SEE the proposed destination, the error returned does not allow discovery of whether the destination was even present (ideally check this before even finding out whether the destination exists)
[ ] Unit tests
To be designed
==============
One of these:
* ACTIVATE flag controls StartServiceByName()
* You can StartServiceByName(foo) if there is any method call that
you would be allowed to send to foo
Out of scope
============
* Receiving non-reply messages
Version: git master
### Depends on
* [Bug 105658](https://bugs.freedesktop.org/show_bug.cgi?id=105658)
### Blocking
* [Bug 101902](https://bugs.freedesktop.org/show_bug.cgi?id=101902)https://gitlab.freedesktop.org/dbus/dbus/-/issues/205Containers message filtering/policy (#101902): control over receiving broadcasts2023-09-06T17:04:39ZBugzilla Migration UserContainers message filtering/policy (#101902): control over receiving broadcasts## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105660)](https://bugs.freedesktop.org/show_bug.cgi?id=105660)**
## Description
+++ This bug was initially created as a clone of Bug #101902...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105660)](https://bugs.freedesktop.org/show_bug.cgi?id=105660)**
## Description
+++ This bug was initially created as a clone of Bug #101902 +++
[ ] Rules can allow connections in the container instance to receive broadcasts
[ ] from any bus name
[ ] from a subtree of bus names
[ ] from a specific bus name
[ ] from any object path
[ ] from a subtree of object paths
[ ] from a specific object path
[ ] from any interface
[ ] from a specific interface
[ ] a specific signal in a specific interface
[ ] Broadcasts can't normally contain Unix fds
Version: git master
### Depends on
* [Bug 105658](https://bugs.freedesktop.org/show_bug.cgi?id=105658)
### Blocking
* [Bug 101902](https://bugs.freedesktop.org/show_bug.cgi?id=101902)https://gitlab.freedesktop.org/dbus/dbus/-/issues/206Containers message filtering/policy (#185) followup: allow dconf etc. to gran...2023-09-06T17:15:21ZBugzilla Migration UserContainers message filtering/policy (#185) followup: allow dconf etc. to grant extra accesses## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105661)](https://bugs.freedesktop.org/show_bug.cgi?id=105661)**
## Description
+++ This bug was initially created as a clone of Bug #101902...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105661)](https://bugs.freedesktop.org/show_bug.cgi?id=105661)**
## Description
+++ This bug was initially created as a clone of Bug #101902 +++
Allison Lortie wants dconf to be able to give contained apps access to specific subtrees of the dconf object path tree, without giving them general access to dconf.
Currently, a contained app either has full read/write access to dconf, or no access. It should have read/write access to its own subtree(s) of dconf configuration space, and no access to the rest.
Allison suggested an API in which the dconf service creates a new *cursor* object, and asks dbus-daemon to open up access to that object for a particular container instance.
(If it was just about method calls, we could require dconf to implement this itself. However, dconf sends broadcasts, and we want to lock those down too.)
Snap developers suggested that the Containers1 API should be usable for MAC as well as for DAC. To support that, we might want to have this be an opt-in feature, where rules added by dconf or similar only take effect if the container manager has opted-in to "can grant access". (Or we might want to decide that Containers1 is DAC, and tell Snap developers that if they want MAC they need to stick to AppArmor.)
[ ] New message filtering rules can be added by unconfined peers at runtime
[ ] Contained peers cannot alter message filtering rules
[ ] Peers can revoke exact access rules that they added (by making a method call with identically-matching parameters, or with a cookie that was returned when the rule was added, or something)
Out of scope
============
* Peers are not required to be able to revoke access rules by any more complex match rule than an exact one
* Peers are not required to be able to revoke access rules that were added at creation (the Allow parameter from Bug #101902), although it might also be acceptable if they can
Version: git master
### Depends on
#185https://gitlab.freedesktop.org/dbus/dbus/-/issues/207Integrate coverity scans in dbus travis-ci2018-10-15T13:25:08ZBugzilla Migration UserIntegrate coverity scans in dbus travis-ci## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105689)](https://bugs.freedesktop.org/show_bug.cgi?id=105689)**
## Description
dbus is registered at coverity (https://scan.cov...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105689)](https://bugs.freedesktop.org/show_bug.cgi?id=105689)**
## Description
dbus is registered at coverity (https://scan.coverity.com/projects/dbus), at travis-ci (https://travis-ci.org/d-bus/dbus) and github (https://github.com/d-bus/dbus), which makes it possible to run coverity scans on a regular interval very easily. The related howto is located at https://scan.coverity.com/travis_ci
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/208[PATCH] Fix is_valid_section_name always returning true2019-04-17T12:38:26ZBugzilla Migration User[PATCH] Fix is_valid_section_name always returning true## Submitted by Albert Astals Cid
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106183)](https://bugs.freedesktop.org/show_bug.cgi?id=106183)**
## Description
Created attachment 138992
The said patch
The if conditio...## Submitted by Albert Astals Cid
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106183)](https://bugs.freedesktop.org/show_bug.cgi?id=106183)**
## Description
Created attachment 138992
The said patch
The if condition was
if (!((*name >= 'A' && *name <= 'Z') || (*name >= 'a' || *name <= 'z') ||
*name == '\n' || *name == '\t'))
which translates to
if ((!(*name >= 'A' && *name <= 'Z') && !(*name >= 'a' || *name <= 'z') &&
*name != '\n' && *name != '\t'))
which translates to
if (((*name < 'A' || *name > 'Z') && (*name < 'a' && *name > 'z') &&
*name != '\n' && *name != '\t'))
which will always be false since name can't be both smaller than a and bigger than z
Found by gcc
**Patch 138992**, "The said patch":
[0001-Fix-is_valid_section_name-always-returning-true.patch](/uploads/89d1fee6d582ab258d87d9281cfb561c/0001-Fix-is_valid_section_name-always-returning-true.patch)
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/209[PATCH] bus: Mark service as requiring nss-user-lookup.target2018-10-15T13:24:08ZBugzilla Migration User[PATCH] bus: Mark service as requiring nss-user-lookup.target## Submitted by Jonathan Lebon
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106339)](https://bugs.freedesktop.org/show_bug.cgi?id=106339)**
## Description
Created attachment 139253
[PATCH] bus: Mark service as requi...## Submitted by Jonathan Lebon
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106339)](https://bugs.freedesktop.org/show_bug.cgi?id=106339)**
## Description
Created attachment 139253
[PATCH] bus: Mark service as requiring nss-user-lookup.target
My motivation for this patch is that I'm trying to use sssd on Fedora as a replacement for nss-altfiles (briefly: on Fedora Atomic Host, system users are stored in /usr/lib/passwd to be compatible with ostree's 3-way merge of /etc -- for more info, see [1]). The issue is that there is no clear ordering between the sssd and dbus units at boot time. So if during boot, dbus is started *before* sssd, then it will fail to resolve usernames and block convergence towards multi-user.target.
This patch ensures that dbus is started strictly after we reach the nss-user-lookup.target, which sssd symmetrically marks in its `Before=`. (Obviously, this patch is also useful for other services like sssd which provide name resolution).
[1] https://github.com/pbrezina/authselect/issues/48
~~**Patch 139253**~~, "[PATCH] bus: Mark service as requiring nss-user-lookup.target":
[0001-bus-Mark-service-as-requiring-nss-user-lookup.target.patch](/uploads/fbb47f9180548a99eb0aacf1a50e4867/0001-bus-Mark-service-as-requiring-nss-user-lookup.target.patch)
Version: 1.12https://gitlab.freedesktop.org/dbus/dbus/-/issues/210Containers (#171): Last chance to change instance ID from 'o' to 'x'2023-10-20T12:35:46ZBugzilla Migration UserContainers (#171): Last chance to change instance ID from 'o' to 'x'One of the review comments on implementations of #171 that led to that issue stalling indefinitely was that some reviewers would prefer the container instance ID to be an opaque integer, probably `dbus_uint64_t` (`x`), rather than an obj...One of the review comments on implementations of #171 that led to that issue stalling indefinitely was that some reviewers would prefer the container instance ID to be an opaque integer, probably `dbus_uint64_t` (`x`), rather than an object path.
See https://bugs.freedesktop.org/show_bug.cgi?id=106712 for the original discussion of this in a somewhat readable form (comments that were copied into this automatically-imported issue are not very readable).
We are constrained by some of the original implementation of Containers having been released in dbus 1.14.x. That version includes:
* `DBUS_HEADER_FIELD_CONTAINER_INSTANCE`, with value 10
* `dbus_bool_t dbus_message_set_container_instance(DBusMessage *, const char *)`
* `const char *dbus_message_get_container_instance (DBusMessage *)`
* The `const char *` in those C functions is documented as being an object path
So if we are going to convert the object path into an integer, we need to figure out a way to deprecate those and introduce an integer replacement.
We also should not make this change unless we have serious plans to introduce the ability to match signals against integers (#478).
@smcv is not particularly interested in this change, and so will not be working on it. If someone else wants this change, this is their chance to step forward to implement it.
## Deadline
If there is no substantial movement on this by the end of September 2023, then @smcv intends to reject this change and keep the container instance ID being an object path.
## Dependencies
@smcv will not accept this change unless someone (presumably someone who wanted this) steps forward to implement #478. It does not necessarily need to be finished before making this change.
/cc @dvdhrm @desrthttps://gitlab.freedesktop.org/dbus/dbus/-/issues/211Warn about reaching max received_size2018-10-15T15:10:55ZBugzilla Migration UserWarn about reaching max received_size## Submitted by Alexander Larsson `@alexl`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106826)](https://bugs.freedesktop.org/show_bug.cgi?id=106826)**
## Description
I just debugged an issue where we were leaking r...## Submitted by Alexander Larsson `@alexl`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106826)](https://bugs.freedesktop.org/show_bug.cgi?id=106826)**
## Description
I just debugged an issue where we were leaking replies returned from dbus_connection_send_with_reply_and_block(). These replies are small, but still count against the the max-received-size live_messages counter, even on the client side.
This would have been much easier to debug if the logs had any kind of warning about reaching this limit, especially for the client (rather than bus) side where we're not really expecting this to *ever* happen, because we're unlikely to be overloaded by replies from the bus.https://gitlab.freedesktop.org/dbus/dbus/-/issues/212API design guidelines give ambiguous advice about coping with old versions2018-10-15T13:22:58ZBugzilla Migration UserAPI design guidelines give ambiguous advice about coping with old versions## Submitted by Simon McVittie
Assigned to **Philip Withnall**
**[Link to original bug (#106862)](https://bugs.freedesktop.org/show_bug.cgi?id=106862)**
## Description
https://dbus.freedesktop.org/doc/dbus-api-design.html#api-vers...## Submitted by Simon McVittie
Assigned to **Philip Withnall**
**[Link to original bug (#106862)](https://bugs.freedesktop.org/show_bug.cgi?id=106862)**
## Description
https://dbus.freedesktop.org/doc/dbus-api-design.html#api-versioning says:
> New API can be added to a D-Bus interface without incrementing the version
> number, as such additions are still backwards-compatible. However, clients
> should gracefully handle the org.freedesktop.DBus.Error.UnknownMethod error
> reply from all D-Bus method calls if they want to run against older versions
> of the service which don’t implement new methods. (This also prevents use of
> generated bindings; any method which a client wants to gracefully fall back
> from should be called using a generic D-Bus method invocation rather than a
> specific generated binding.)
I'm not sure why it says that? Code generated by, for example, gdbus-codegen or (ugh) dbus-binding-tool from a local copy of some API v1.23 should interoperate fine with a service implementing some API v1.0 (assume semantic versioning here). The generated methods will raise UnknownMethod as usual.
The uses of generated bindings that *would* be a problem are those where the generated binding is external to the client, or where the binding is generated from interface definitions that are external to the client. Philip, are those situations the ones you had in mind? I think we should clarify this.
Let's say a client calls methods on a service that implements an API, and ideally it wants to call DoThingsWithOptions() (introduced in com.example.Something1 v1.23), falling back to DoThings() if DoThingsWithOptions() isn't implemented. Assume that service v1.x implements com.example.Something1 v1.x, and assume GDBus (the same considerations would apply to dbus-glib or QtDBus, with appropriate relabelling). There are several ways the client could call the method:
(A) Service ships a library containing gdbus-codegen-generated bindings for
its version of com.example.Something1. Client calls methods from that
library.
- Client needs to be compiled against library v1.23 or later
- Client has a strong dependency on library v1.23 or later at
runtime, unless statically linked (if the library is not present,
the client won't even start)
- Client has a weak dependency on service v1.0 or later at runtime
(if the service is not present, the relevant feature won't work
but the client will still run)
(B) Service ships com.example.Something1.xml in /usr/share/dbus-1/interfaces.
Client runs gdbus-codegen to generate private bindings which are
built into the client.
- Client needs to be compiled against library v1.23 or later
- Client only needs service v1.0 or later at runtime
(C) Client ships a private copy of com.example.Something1.xml and uses
it to generate private bindings which are built into the client.
- No build-time dependency
- Client has a weak dependency on service v1.0 or later at runtime
(D) Client uses g_dbus_connection_call() or equivalent to call at least
DoThingsWithOptions(), and perhaps both methods.
- No build-time dependency
- Client has a weak dependency on service v1.0 or later at runtime
For tightly-coupled components where it's OK for a new client to get a hard dependency on a new service, like xdg-desktop-portal-gtk depending on xdg-desktop-portal, cases (A) or (B) are fine.
For loosely-coupled components where graceful fallbacks and backwards compatibility are needed, I would personally recommend (C) if the interface is of a significant size, or (D) if the interface is small and simple.
Note that it is not OK to expose the generated bindings in case (B) as part of a library, because their API would change unpredictably, depending on the precise version of the service that the client is compiled against. It would be OK to expose the generated bindings in case (C) as part of a library.
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/213Failed to connect to bus: Connection refused2018-10-12T21:34:59ZBugzilla Migration UserFailed to connect to bus: Connection refused## Submitted by ali
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106874)](https://bugs.freedesktop.org/show_bug.cgi?id=106874)**
## Description
I don't know where is the root cause of problem. So I decided to report...## Submitted by ali
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106874)](https://bugs.freedesktop.org/show_bug.cgi?id=106874)**
## Description
I don't know where is the root cause of problem. So I decided to report this bug in two places (systemD[github.com] + dbus[bugs.freedesktop.org]).
https://github.com/systemd/systemd/issues/9248
Thanks in advancehttps://gitlab.freedesktop.org/dbus/dbus/-/issues/214Drop chdir("/") in dbus-launch2018-11-19T15:42:21ZBugzilla Migration UserDrop chdir("/") in dbus-launch## Submitted by David King
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106987)](https://bugs.freedesktop.org/show_bug.cgi?id=106987)**
## Description
In RHEL 7, Paul Gozart came across some unexpected behaviour in...## Submitted by David King
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106987)](https://bugs.freedesktop.org/show_bug.cgi?id=106987)**
## Description
In RHEL 7, Paul Gozart came across some unexpected behaviour in gedit when run as a regular user, where the save dialog used the root path ("/") as the default location. This was traced down by Ray Strode to gedit in newer RHEL 7 versions being launched by dbus activation (as most GNOME applications are, if they use GApplication), and the dbus-daemon used for the session bus in RHEL being launched with dbus-launch (by gnome-session, as systemd is not used as a user session manager in RHEL 7).
There is a chdir("/") call in dbus-launch with the following justification:
/* We chdir ("/") since we are persistent and daemon-like, and fork
* again so dbus-launch can reap the parent. However, we don't
* setsid() or close fd 0 because the idea is to remain attached
* to the tty and the X server in order to kill the message bus
* when the session ends.
*/
Arguably, this is not the best behaviour for a tool that is only used to run session buses, which are scoped to the lifetime of the user's session (with some exceptions, of course), and given the pervasive use of dbus-launch by session managers to start dbus-daemon as a session bus, I think that it is best to drop the chdir() call entirely.
Version: git master
### See also
* https://bugzilla.redhat.com/show_bug.cgi?id=1470310https://gitlab.freedesktop.org/dbus/dbus/-/issues/215Why does ListActivatableNames say o.fd.DBus is activatable?2018-10-15T13:21:11ZBugzilla Migration UserWhy does ListActivatableNames say o.fd.DBus is activatable?## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107024)](https://bugs.freedesktop.org/show_bug.cgi?id=107024)**
## Description
Ever since ListActivatableNames() was added, it has included...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107024)](https://bugs.freedesktop.org/show_bug.cgi?id=107024)**
## Description
Ever since ListActivatableNames() was added, it has included "org.freedesktop.DBus" as an activatable name:
commit 7628b541258d906e27e2000a402ed2d02383479c
Author: John (J5) Palmieri <johnp@redhat.com>
Date: 2006-07-14 01:17:59 +0000
* bus/activation.[ch] (bus_activation_list_services): new function to
get the list of services that can be activated
...
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,16 @@
+2006-07-13 Carlos Garcia Campos <carlosgc@gnome.org>
+
+ * bus/activation.[ch] (bus_activation_list_services): new function to
+ get the list of services that can be activated
...
--- a/bus/driver.c
+++ b/bus/driver.c
...
+ /* Include the bus driver in the list */
+ const char *v_STRING = DBUS_SERVICE_DBUS;
+ if (!dbus_message_iter_append_basic (&sub, DBUS_TYPE_STRING,
+ &v_STRING))
+ {
+ dbus_free_string_array (services);
+ dbus_message_unref (reply);
+ BUS_SET_OOM (error);
+ return FALSE;
+ }
This doesn't make a whole lot of sense to me: by calling ListActivatableNames() successfully, you've proved that o.fd.DBus exists, which means it's irrelevant whether it is activatable or not.
Does anyone know why it gets returned here? I think it would make sense in ListNames(), but not in ListActivatableNames().
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/216building tests fails on Windows (msys2)2019-04-18T15:38:43ZBugzilla Migration Userbuilding tests fails on Windows (msys2)## Submitted by Vincent Torri
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107051)](https://bugs.freedesktop.org/show_bug.cgi?id=107051)**
## Description
when i compile d-bus on Windows (MSYS2 + mingw-w64), using th...## Submitted by Vincent Torri
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107051)](https://bugs.freedesktop.org/show_bug.cgi?id=107051)**
## Description
when i compile d-bus on Windows (MSYS2 + mingw-w64), using the autotools, i get that error:
/usr/bin/mkdir -p -m 700 XDG_RUNTIME_DIR
/usr/bin/mkdir: impossible de modifier les droits de « XDG_RUNTIME_DIR »: Permission denied
(translation : impossible to modify access rights)
trying this command directly in MSYS2 gives the same error. So passing -m 700 seems wrong when using MSYS2
Vincent Torri
Version: 1.12https://gitlab.freedesktop.org/dbus/dbus/-/issues/217Set default system bus socket address on ./configure to /run/dbus/system_bus_...2018-10-15T13:18:28ZBugzilla Migration UserSet default system bus socket address on ./configure to /run/dbus/system_bus_socket## Submitted by Dilian
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107192)](https://bugs.freedesktop.org/show_bug.cgi?id=107192)**
## Description
Doing systemd-239/meson && ninja install uses as bus socket address ...## Submitted by Dilian
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107192)](https://bugs.freedesktop.org/show_bug.cgi?id=107192)**
## Description
Doing systemd-239/meson && ninja install uses as bus socket address /run/dbus/system_bus_socket .
Doing dbus-1.12.8/configure prints:
System bus socket: /usr/local/var/run/dbus/system_bus_socket
System bus address: unix:path=/usr/local/var/run/dbus/system_bus_socket
Please adjust the defaults to match the systemd defaults on this parameter, see https://github.com/systemd/systemd/issues/9547 for discussion on systemd's side.
Note, there it is suggested to make the system bus address unconfigurable.
If you don't agree on any of this write in the documentation explictly that systemd and dbus have to be tweaked explicitly on the session bus address in order to work together.
Version: 1.12https://gitlab.freedesktop.org/dbus/dbus/-/issues/218Run tests under valgrind2018-11-16T15:16:49ZBugzilla Migration UserRun tests under valgrind## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#107194)](https://bugs.freedesktop.org/show_bug.cgi?id=107194)**
## Description
On Bug #105656, Philip suggested running the tests under valgri...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#107194)](https://bugs.freedesktop.org/show_bug.cgi?id=107194)**
## Description
On Bug #105656, Philip suggested running the tests under valgrind. This is a larger task than one might think, because many of the tests are not fully valgrind-clean (and because valgrind doesn't currently work on Debian unstable due to binutils behaviour changes, so I'm having to test all this in a Debian 9 chroot).
I've mostly found false positives, but a couple of actual bugs.
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/219[RFC] specification extension: ConnectClient()2018-10-15T13:17:34ZBugzilla Migration User[RFC] specification extension: ConnectClient()## Submitted by Tom Gundersen `@tomegun`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107245)](https://bugs.freedesktop.org/show_bug.cgi?id=107245)**
## Description
This is a follow-up on the discussion in <https://...## Submitted by Tom Gundersen `@tomegun`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107245)](https://bugs.freedesktop.org/show_bug.cgi?id=107245)**
## Description
This is a follow-up on the discussion in <https://github.com/systemd/systemd/issues/9503>.
I want to suggest adding a new call, ConnectClient() to the org.freedesktop.DBus interface. The intention behind this is to allow a (privileged) client to connect and claim names on behalf of another (unprivileged) one.
The discussion that precipitated this was the desire to allow PID1 to spawn dbus-clients running as a dynamic user, without having to update the DBus policy dynamically to allow these new users to connect and claim names on the bus.
The proposed API extension would allow PID1 to tell dbus daemon to connect the new client, acquire for it a set of given names, and pin in it its dynamic (unprivileged) credentials, but to use PID1's (privileged) credentials for the policy checks when deciding if the client is allowed to be connected and to acquire the names.
This would solve the immediate problem at hand of dynamic users, but it would also allow other features:
1) Scheduling of well-known names
Currently, if a name is activatable, it is always activatable. There is no way of delaying the availability of a name, or making a name no longer activatable. Short of delaynig the start-up of the whole bus, or shutting the bus down.
2) Socket activation of DBus clients
Allowing DBus clients to be socket-activated is both a simpler scheme than the current name activation, but it would also allow for proper exit-on-idle, which name activation does not allow (without potentially dropping messages).
3) Simplification of XML policy
This is obviously up to the implementers, but this scheme would long-term allow systems without own/user/group directives. And as send_* recv_* directives are already not strictly speaking necessary (one could use polkit instead), this could in the future allow for greatly simplified policies in the common case.
Suggested API (based on suggestion by David Herrmann):
`org.freedesktop.DBus.ConnectClient(h socket, a{sv} args) -> (s unique_name);
This pre-connects, pre-authenticates, and prepares an AF_UNIX socket for use as a D-Bus connection. The socket is taken as input rather than output, to guarantee that the owning-uid/creds are correct. If the socket is not AF_UNIX+SOCK_STREAM+unconnected, the call simply fails.
The args parameter can be extended in the future to modify this call. Examples:
`RequestNames`: Takes a string array as argument; specifies which names are pre-acquired by the client.
`AllowUnixFds`: Set the ALLOW_UNIX_FDS flag for the new connection.
The message daemon makes this call available to everyone, but verifies the caller (not the passed in client socket) is allowed to connect and claim the names specified in `RequestNames`.
Note that it isn't expected that existing clients connecting in the traditional way can necessarily be ported over to this new API without further notification. As pointed out by smcv in the above bug, care must be taken with the fact that names are claimed before the client has been initialized. In the common case this shouldn't make a difference, and in the case a client needs to make calls on the bus before processing incomming method calls on its names, it would either have to buffer messages, or use a separate connection to the bus for the initialization before starting to process the main connection (much could be said on that topic, I'm just mentioning it briefly here to note that it is on the radar).
If we agree that we want something like this and on a basic design, I'm happy to write it up as a patch to the spec.https://gitlab.freedesktop.org/dbus/dbus/-/issues/220--enable-relocation support breaks assumptions made by mingw32-install-post.sh2018-11-15T13:29:45ZBugzilla Migration User--enable-relocation support breaks assumptions made by mingw32-install-post.sh## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107662)](https://bugs.freedesktop.org/show_bug.cgi?id=107662)**
## Description
Created attachment 141245
fix-order-of-dbus-1.pc...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107662)](https://bugs.freedesktop.org/show_bug.cgi?id=107662)**
## Description
Created attachment 141245
fix-order-of-dbus-1.pc.patch
Cross building dbus from git master with autotools for windows fails because of two issues
1.cross pkg-config 0.28 is confused to not have prefix= in the first line of dbus-1.pc
2. relocation support in configure.ac does not recognize --exec_prefix expanded to ${prefix} and --libdir to ${prefix}/lib
For both issues a related patch has been appended.
~~**Patch 141245**~~, "fix-order-of-dbus-1.pc.patch":
[fix-order-of-dbus-1.pc.patch](/uploads/711e79dd42873d93b2ef29685083b6b4/fix-order-of-dbus-1.pc.patch)
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/221invalid example in specification2018-12-03T15:29:41ZBugzilla Migration Userinvalid example in specification## Submitted by Peter A. Bigot
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107685)](https://bugs.freedesktop.org/show_bug.cgi?id=107685)**
## Description
The section on ObjectManager suggests the following match ru...## Submitted by Peter A. Bigot
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107685)](https://bugs.freedesktop.org/show_bug.cgi?id=107685)**
## Description
The section on ObjectManager suggests the following match rule for a trivial client:
"type='signal',name='org.example.App2',path_namespace='/org/example/App2'"
The section on Match Rules does not admit "name" as a valid key.
Maybe "sender" was meant?
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/222Extra whitespace in comm= field2018-11-01T12:07:23ZBugzilla Migration UserExtra whitespace in comm= field## Submitted by Laurent Bigonville
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107887)](https://bugs.freedesktop.org/show_bug.cgi?id=107887)**
## Description
Hi,
It seems that in the log the comm= field contain an...## Submitted by Laurent Bigonville
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107887)](https://bugs.freedesktop.org/show_bug.cgi?id=107887)**
## Description
Hi,
It seems that in the log the comm= field contain an extra whitespace at the end:
"dbus-daemon[23494]: [session uid=1000 pid=23494] Connection :1.0 (uid=1000 pid=23495 comm="dbus-monitor " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023") became a monitor."
Looking at the code, it seems that _dbus_command_for_pid() is at fault here. /proc/`<pid>`/cmdline also contain a final \0 which is translated to a whitespace, this one should probably be stripped?
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/223Move more test code to test/2019-01-21T15:48:13ZBugzilla Migration UserMove more test code to test/## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#108178)](https://bugs.freedesktop.org/show_bug.cgi?id=108178)**
## Description
dbus currently has too much test code in bus/ and dbus/. This i...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#108178)](https://bugs.freedesktop.org/show_bug.cgi?id=108178)**
## Description
dbus currently has too much test code in bus/ and dbus/. This is awkward for several reasons:
* we need to compile the test binaries alongside the rest of bus/ and dbus/, but then run them from test/
* the test code gets counted as part of bus/ and dbus/ when computing coverage statistics, distorting our ideas about the coverage of the actual production code
* the "embedded tests" should not be compiled into libdbus and dbus-daemon when building secure, efficient production dbus binaries, but then we lose test coverage by disabling them
* the test framework used for the "embedded tests" makes it hard to skip tests that take forever and might not even be relevant to the bug/feature you're actually working on
This branch attempts to clean that up, removing something like half of the test code from dbus/, along with all the test executables.
Because I'm experimenting with freedesktop.org Gitlab ahead of dbus' migration, here's a merge request to review: https://gitlab.freedesktop.org/smcv/dbus-temp/merge_requests/2
(That's in a temporary clone of dbus, which I'll archive when we have the real dbus/dbus.git in Gitlab, and replace with a proper fork in smcv/dbus.)
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/224Missing D-Bus C++ wrapper on wiki page2018-10-12T21:36:24ZBugzilla Migration UserMissing D-Bus C++ wrapper on wiki page## Submitted by Waqar Hameed
Assigned to **D-Bus Maintainers**
**[Link to original bug (#108271)](https://bugs.freedesktop.org/show_bug.cgi?id=108271)**
## Description
Lennart Poettering advised me to file a bug here for the wiki...## Submitted by Waqar Hameed
Assigned to **D-Bus Maintainers**
**[Link to original bug (#108271)](https://bugs.freedesktop.org/show_bug.cgi?id=108271)**
## Description
Lennart Poettering advised me to file a bug here for the wiki page regarding a missing sd-bus C++ wrapper library. Please see the attached mail conversation below:
>> Hi!
>>
>>
>> You have a nice collection of sd-bus wrappers for different
>> languages at
>> https://www.freedesktop.org/wiki/Software/DBusBindings/. I was just
>> wondering if there is any reasons for why you have not included
>> sdbusplus (https://github.com/openbmc/sdbusplus)??
> Consider filing a bug against the dbus project, as that wiki page is
> maintained as part of that.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
Thank you!https://gitlab.freedesktop.org/dbus/dbus/-/issues/225_dbus_get_is_errno_eagain_or_ewouldblock: avoid -Wlogical-op warning2019-04-17T12:38:26ZBugzilla Migration User_dbus_get_is_errno_eagain_or_ewouldblock: avoid -Wlogical-op warning## Submitted by David King
Assigned to **D-Bus Maintainers**
**[Link to original bug (#108345)](https://bugs.freedesktop.org/show_bug.cgi?id=108345)**
## Description
I tried to build dbus from git master on Fedora 29 (with GCC 8.2...## Submitted by David King
Assigned to **D-Bus Maintainers**
**[Link to original bug (#108345)](https://bugs.freedesktop.org/show_bug.cgi?id=108345)**
## Description
I tried to build dbus from git master on Fedora 29 (with GCC 8.2.1), and from running autogen.sh and calling make (not injecting any extra CFLAGS, as far as I know), I get the following warning:
dbus-sysdeps-unix.c: In function ‘_dbus_get_is_errno_eagain_or_ewouldblock’:
dbus-sysdeps-unix.c:4607:22: error: logical ‘or’ of equal expressions [-Werror=logical-op]
return e == EAGAIN || e == EWOULDBLOCK;
errno(3) mentions that EAGAIN and EWOULDBLOCK can be identical, and in this case, they are and the warning is triggered. Working around the warning is quite easy, but complicates the expression.
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/227Unit tests generate core dumps when built with CMake2021-06-21T07:40:54ZSimon McVittieUnit tests generate core dumps when built with CMake## Steps to reproduce
* Configure dbus with cmake (e.g. `mkdir build; cd build; cmake ../cmake`) on a Linux system with core dumps or `systemd-coredump` enabled
* `make`
* `make check`
## Expected result
* Tests pass
* No core dumps f...## Steps to reproduce
* Configure dbus with cmake (e.g. `mkdir build; cd build; cmake ../cmake`) on a Linux system with core dumps or `systemd-coredump` enabled
* `make`
* `make check`
## Expected result
* Tests pass
* No core dumps found
## Actual result
* Tests pass, slowly
* Many core dumps from `test-segfault`Simon McVittieSimon McVittiehttps://gitlab.freedesktop.org/dbus/dbus/-/issues/228-Werror=unused-variable when libX11 is not installed2018-10-18T17:24:56ZSimon McVittie-Werror=unused-variable when libX11 is not installed## Steps to reproduce
* Don't have libX11 development headers (for example `apt remove libx11-dev` on Debian)
* Build dbus with `--enable-developer`
## Expected result
* Successful dbus-launch build (without X11 autolaunch support)
#...## Steps to reproduce
* Don't have libX11 development headers (for example `apt remove libx11-dev` on Debian)
* Build dbus with `--enable-developer`
## Expected result
* Successful dbus-launch build (without X11 autolaunch support)
## Actual result
```
/home/smcv/src/dbus/tools/dbus-launch.c: In function ‘main’:
/home/smcv/src/dbus/tools/dbus-launch.c:849:13: error: unused variable ‘error’ [-Werror=unused-variable]
DBusError error = DBUS_ERROR_INIT;
^~~~~
```Simon McVittieSimon McVittiehttps://gitlab.freedesktop.org/dbus/dbus/-/issues/229Follow-up from "Add windows implementation of dbus-run-session helper tool"2018-10-17T08:00:05ZRalf HabackerFollow-up from "Add windows implementation of dbus-run-session helper tool"The following discussions from !7 should be addressed:
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50506): (+1 comment)
> Why does a change to dbus-run-session require changing...The following discussions from !7 should be addressed:
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50506): (+1 comment)
> Why does a change to dbus-run-session require changing the libraries that are linked into a manual test?
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50507):
> Same
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50508):
> Same
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50509):
> Don't expose this directly. dbus-run-session should call `_dbus_hash_table_unref()` instead - that's already `DBUS_PRIVATE_EXPORT`.
>
> In general, a particular data structure should either be refcounted (has `_ref` and `_unref`, like `DBusHashTable`) or not refcounted (has `_free`, like `DBusString`). A mixture of the two means we got it wrong somewhere.
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50510):
> If this is only used in dbus-run-session, I'd prefer to put it in dbus-sysdeps-win-util.c, which means it doesn't need to be `DBUS_PRIVATE_EXPORT` and isn't part of the shared library.
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50511):
> Coding style: align pointer stars with the name, not the type, because that's how C precedence works (`char *a, b;` is the same as `char *a; char b;`, but if you write it as `char* a, b` then you might be misled into thinking it's the same as `char *a; char *b;`).
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50512): (+1 comment)
> Can we continue to link with `libdbus-1.la` on Unix, and only use `libdbus-internal.la` on Windows?
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50513): (+1 comment)
> Coding style: space before open parenthesis
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50515): (+3 comments)
> This is a bit of a weird setup; I'll have to look at the old Bugzilla bug to refresh my memory of how we got here.
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50516):
> Coding style nitpick: `if (!result)`
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50517):
> `server_handle` and `app_handle` could be uninitialized at this point. If I'm remembering correctly that a `HANDLE` is a pointer, use:
>
> ```
> HANDLE server_handle = NULL;
>
> ...
>
> out:
> ...
> if (server_handle != NULL)
> CloseHandle (server_handle);
> ...
> ```
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50519):
> `dbus_free` should already be a `DBusFreeFunction`, so you shouldn't need this cast.
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50520):
> If you `goto out` after this point, you'll double-free `env`.
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50521):
> If you `goto out` early, `env_table` will be uninitialized. Initialize it to `NULL` and only free it if it's non-`NULL`.
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50523): (+1 comment)
> Is this relevant to the rest of the commit?
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50529): (+1 comment)
> `config_file` defaults to `NULL`, which means "use the standard session bus config file", so this needs to be something like
>
> ```
> if (config_file != NULL)
> _dbus_string_append_printf (&argv_strings[1], "--config-file=%s", config_file);
> else
> _dbus_string_append_printf (&argv_strings[1], "--session");
> ```
>
> to match the Unix implementation.https://gitlab.freedesktop.org/dbus/dbus/-/issues/230bus/desktop-file.c: Incorrect logic for excluding invalid group names in is_v...2018-10-18T11:29:31ZRalf Habackerbus/desktop-file.c: Incorrect logic for excluding invalid group names in is_valid_section_name()With recent dbus code from git master branch I get the following compile error with autotools:
```
../../dbus/bus/desktop-file.c: In function ?is_valid_section_name?:
../../dbus/bus/desktop-file.c:385:7: error: logical or of collectivel...With recent dbus code from git master branch I get the following compile error with autotools:
```
../../dbus/bus/desktop-file.c: In function ?is_valid_section_name?:
../../dbus/bus/desktop-file.c:385:7: error: logical or of collectively exhaustive tests is always true [-Werror=logical-op]
if (!((*name >= 'A' && *name <= 'Z') || (*name >= 'a' || *name <= 'z') ||
^
```
As already mentioned in the merge request !15, it turned out that besides the compilation error also the logic is defective and has to be repaired.
https://gitlab.freedesktop.org/dbus/dbus/-/issues/231Decide whether we want merge commits when a MR is merged2020-04-27T15:26:22ZSimon McVittieDecide whether we want merge commits when a MR is mergedGitlab has three configurable strategies for merging MRs:
* Fast-forward with linear history. The commits are required to have been rebased on current master before merging (for outdated commits there is a Rebase button in the web UI wh...Gitlab has three configurable strategies for merging MRs:
* Fast-forward with linear history. The commits are required to have been rebased on current master before merging (for outdated commits there is a Rebase button in the web UI which will do this for you, in simple cases where there are no conflicts), and are pushed as-is, without adding any details of the merge request. For example, this is how I merged !8: there is no indication in the commits that it was MR !8, or that David King reviewed it.
* Merge commit with semi-linear history. The commits are required to have been rebased on current master, but then are merged with a non-trivial merge commit. For example, I enabled this before merging dbus/dbus-glib!1: you can see from the commit history that Alan Coopersmith contributed two commits https://gitlab.freedesktop.org/dbus/dbus-glib/commit/c22bbbe9d60bf9404719d3fc5e4be549faef814f and https://gitlab.freedesktop.org/dbus/dbus-glib/commit/a1241eab2e319f09a586a88a928dfa8163780cd2, and when I clicked the Merge button, Gitlab created https://gitlab.freedesktop.org/dbus/dbus-glib/commit/73e32f5aff01bb2915ffbd137d8f0c5ca326367c for me.
* Merge commit with non-linear history. I don't have a concrete example of this in dbus, but you can see it in https://gitlab.gnome.org/GNOME/glib if you examine the history of https://gitlab.gnome.org/GNOME/glib/merge_requests/389: you'll see that https://gitlab.gnome.org/GNOME/glib/commit/6c8b9f31b15bba38c7eb82b17437c1f462fb6ab8 merges a commit that is based on older-than-current code.
Unfortunately, these are chosen globally for a project (e.g. dbus/dbus), and maintainers can't choose which one is the most appropriate at the time they land a merge request.
The advantage of the linear history is that it's simple (one single line of ancestry in gitk/gitg), and very easy to use with `git bisect`. The disadvantage is that we lose details of which merge request resulted in merging a particular change, which means it's harder to find the discussion that led to it being accepted.
The advantages of semi-linear history are that `git bisect` still works well, and we still have details of the merge request.
The advantage of non-linear history is that the commit that gets merged is exactly what the patch submitter tested (although note that if we are concerned about this, we can always ask the patch submitter to rebase and re-test). The disadvantage is that bisecting won't necessarily work at all.
I think semi-linear history is a good compromise position, and I've enabled it in dbus and dbus-glib. Do any of the other maintainers agree or object?
Note that if we want to use a different strategy on a case-by-case basis, maintainers can bypass Gitlab and push directly to master. For stable branches, I'll probably stick to using `git cherry-pick` from master and pushing directly to the stable branch.
/cc @rhabacker @thiago @waltershttps://gitlab.freedesktop.org/dbus/dbus/-/issues/232Consider removing BROKEN_POLL check2018-11-16T15:09:51ZSimon McVittieConsider removing BROKEN_POLL check[From !18](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/18#note_51881):
> > Add cmake check for BROKEN_POLL
>
> I'm not really sure why dbus even has this check - as far as I can see, we're careful to only poll things we can ...[From !18](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/18#note_51881):
> > Add cmake check for BROKEN_POLL
>
> I'm not really sure why dbus even has this check - as far as I can see, we're careful to only poll things we can rely on being able to poll, notably not including devices:
>
> * sockets
> * pipes (Unix only)
> * inotify (Linux and QNX only)
> * kqueue (*BSD only)
>
> I would suggest dropping this commit, and making the CMake build just assume that poll() works. We can consider whether to drop the Autotools check as a separate issue.
This is that separate issue.https://gitlab.freedesktop.org/dbus/dbus/-/issues/233make doc fails to build manpages2018-11-20T17:13:32ZRalf Habackermake doc fails to build manpagesGenerating xml doc is the default with cmake build system. On running make doc with cmake on linux I get:
```
[ 14%] Built target dbus-update-activation-environment.1
doc/CMakeFiles/dbus-monitor.1.html.dir/build.make:60: *** target patt...Generating xml doc is the default with cmake build system. On running make doc with cmake on linux I get:
```
[ 14%] Built target dbus-update-activation-environment.1
doc/CMakeFiles/dbus-monitor.1.html.dir/build.make:60: *** target pattern contains no '%'. Schluss.
CMakeFiles/Makefile2:2404: recipe for target 'doc/CMakeFiles/dbus-monitor.1.html.dir/all' failed
make[1]: *** [doc/CMakeFiles/dbus-monitor.1.html.dir/all] Error 2
Makefile:162: recipe for target 'all' failed
make: *** [all] Error 2
```https://gitlab.freedesktop.org/dbus/dbus/-/issues/234user-triggerable dbus-daemon memory leak caused by CVE-2014-3477 fix2019-01-16T12:14:08ZSimon McVittieuser-triggerable dbus-daemon memory leak caused by CVE-2014-3477 fixWhile trying to set up dbus to be able to run tests in AddressSanitizer, I found a memory leak introduced in 2014 when fixing CVE-2014-3477 ([fdo#78979](https://bugs.freedesktop.org/show_bug.cgi?id=78979)). If a caller sends a message to...While trying to set up dbus to be able to run tests in AddressSanitizer, I found a memory leak introduced in 2014 when fixing CVE-2014-3477 ([fdo#78979](https://bugs.freedesktop.org/show_bug.cgi?id=78979)). If a caller sends a message to an activatable service, and the
service gets auto-started, then the dbus-daemon discovers that the caller is not actually allowed to send the message to the service, it will leak one "permission denied" error.
This is technically a system bus denial of service via resource exhaustion, because someone could spam messages that each activate a service, and let the dbus-daemon leak all those errors. However, it's a weak attack with multiple mitigations, so I'm not sure whether we should treat it as a security vulnerability or just an ordinary bug. @thiago, @walters, @rhabacker: opinions?
Mitigations:
- Each denied message is logged to the system log, making it a very noisy attack (and it's obvious which uid and even which process to blame)
- To leak unbounded amounts of memory quickly, an attacker would need an unbounded number of activatable services that they aren't allowed to contact (but in practice there is a finite number of services)
- To leak unbounded amounts of memory slowly, an attacker would need an activatable service, that they aren't allowed to contact, that either: has exit-on-idle behaviour, is remotely crashable, or can otherwise be induced to exit so that it can be reactivated
- If you want to trigger swappy performance death or the OOM killer on a general-purpose Linux system, there are almost certainly easier ways!
No pull request because I don't think we can embargo those, but I'll quote the patch in a comment.https://gitlab.freedesktop.org/dbus/dbus/-/issues/235Test for windows autolaunching missing2022-06-27T18:18:54ZRalf HabackerTest for windows autolaunching missingFor more thorough coverage, it would be great if you there is a separate test or tests for Windows autolaunching that demonstrates how it should behave (including the corner cases like different scopes, and including assertions about whe...For more thorough coverage, it would be great if you there is a separate test or tests for Windows autolaunching that demonstrates how it should behave (including the corner cases like different scopes, and including assertions about whether it started a new bus or reused an existing bus).
Followup of https://gitlab.freedesktop.org/dbus/dbus/merge_requests/23#note_80310Ralf HabackerRalf Habackerhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/236CMake build should fail if documentation source files are missing2018-11-20T17:12:21ZSimon McVittieCMake build should fail if documentation source files are missingThe following discussion from !48 should be addressed:
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/48#note_80417):
> [A source file not existing] should probably be a build error (the...The following discussion from !48 should be addressed:
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/48#note_80417):
> [A source file not existing] should probably be a build error (the build would fail if any other source file was missing)https://gitlab.freedesktop.org/dbus/dbus/-/issues/237FindDocBookXSL.cmake missing2018-11-20T18:30:31ZSimon McVittieFindDocBookXSL.cmake missingAn earlier version of !48 added a third-party FindDocBookXSL.cmake module, but the final version seems to have lost it.
I'm surprised the CI succeeded without it. `tools/ci-install.sh` should maybe assert that `./usr/local/share/doc/dbu...An earlier version of !48 added a third-party FindDocBookXSL.cmake module, but the final version seems to have lost it.
I'm surprised the CI succeeded without it. `tools/ci-install.sh` should maybe assert that `./usr/local/share/doc/dbus/dbus-daemon.1.html` and `.../doc/dbus/dbus-specification.html` get created.Simon McVittieSimon McVittiehttps://gitlab.freedesktop.org/dbus/dbus/-/issues/238test-sysdeps fails (freezes) when built for Windows with CMake2019-01-16T12:14:08ZSimon McVittietest-sysdeps fails (freezes) when built for Windows with CMakeOn !23, @rhabacker wrote:
```
18/20 Test #18: test-sysdeps ..................... Freeze
```
This is apparently reproducible on Windows 7, on Windows 10, and when cross-compiling under Linux and running the tests with Wine.On !23, @rhabacker wrote:
```
18/20 Test #18: test-sysdeps ..................... Freeze
```
This is apparently reproducible on Windows 7, on Windows 10, and when cross-compiling under Linux and running the tests with Wine.https://gitlab.freedesktop.org/dbus/dbus/-/issues/239test-bus fails when built for Windows with CMake2020-11-13T07:41:38ZSimon McVittietest-bus fails when built for Windows with CMakeOn !23, @rhabacker wrote:
```
2/20 Test #2: test-bus .........................***Failed 5.70 sec
```
This is apparently reproducible on Windows 7, on Windows 10, and when cross-compiling under Linux and running the tests with Wine...On !23, @rhabacker wrote:
```
2/20 Test #2: test-bus .........................***Failed 5.70 sec
```
This is apparently reproducible on Windows 7, on Windows 10, and when cross-compiling under Linux and running the tests with Wine.
test-bus is large and complicated so I'm not really surprised. !1 breaks it into smaller pieces: it would be interesting to see which of them fail.https://gitlab.freedesktop.org/dbus/dbus/-/issues/240test-bus (intermittently?) fails on Wine if all tests are run2019-01-16T12:14:08ZSimon McVittietest-bus (intermittently?) fails on Wine if all tests are run@rhabacker wrote:
> test-bus running with wine fails with one test
> ```
> ~/src/dbus-cmake-cross-wine-build> DBUS_TEST_HOMEDIR=z:$PWD DBUS_TEST_DATA=z:$PWD/test/data /usr/bin/wine "z:/home/ralf.habacker/src/dbus-cmake-cross-wine-build...@rhabacker wrote:
> test-bus running with wine fails with one test
> ```
> ~/src/dbus-cmake-cross-wine-build> DBUS_TEST_HOMEDIR=z:$PWD DBUS_TEST_DATA=z:$PWD/test/data /usr/bin/wine "z:/home/ralf.habacker/src/dbus-cmake-cross-wine-build/bin/test-bus.exe"
> ...
> ok 18 - bus_dispatch_test_conf:valid-config-files/debug-allow-all.conf - check_shell_service_success_auto_start
> ok 19 - bus_dispatch_test_conf:valid-config-files/debug-allow-all.conf
> ok 20 - dispatch
> ok 21 - dispatch did not leak memory
> # Running test: activation-service-reload
> ##temp dir 'C:\users\ralf.habacker\Temp'
> ##bus_context_new ''
> ##bus_config_load ''
> ##_dbus_file_get_contents ''
> dbus-daemon[8]: warning: Failed to create debug bus context from configuration file valid-config-files/debug-allow-all.conf: Failed to open "": Pfad nicht gefunden.
> ##bus_context_new ''
> ##bus_config_load ''
> ##_dbus_file_get_contents ''
> dbus-daemon[8]: warning: Failed to create debug bus context from configuration file valid-config-files/debug-allow-all.conf: Failed to open "": Pfad nicht gefunden.
> ok 22 - activation-service-reload
> not ok 23 - activation-service-reload leaked 2 blocks
> ok 24 # SKIP fd-passing not supported on this platform
> # 1/24 tests failed
> 1..24
> ```
>
> Before running the test I added some debug output to the code, which are identifiable by a prefix '##'.
>
> It happens only when running all test, but not if running a single test e.g. using
>
> ```
> DBUS_TEST_ONLY=dispatch ...
> ```
> or
> ```
> DBUS_TEST_ONLY=activation-service-reload ...
> ```
>
> In the error case the character string from the config_file parameter given to bus_context_new() is empty or has cryptic content, which let me assume that config_file seems to be free'd or points to invalid memory.
>
> It should also be noted that in the 'run all tests' case memory leaks are reported in test 23
>
> ```
> not ok 23 - activation-service-reload leaked 2 blocks
> ```https://gitlab.freedesktop.org/dbus/dbus/-/issues/241tests for OOM behaviour are skipped on Windows with CMake but not Autotools2020-04-25T08:23:29ZSimon McVittietests for OOM behaviour are skipped on Windows with CMake but not Autotools```
% git grep DBUS_WIN_FIXME
README.win:- the code wrapped with DBUS_WIN_FIXME should be inspected if it required for windows
bus/dispatch.c:#ifdef DBUS_WIN_FIXME
cmake/config.h.cmake:# define DBUS_WIN_FIXME 1
dbus/dbus-memory.c:#ifdef ...```
% git grep DBUS_WIN_FIXME
README.win:- the code wrapped with DBUS_WIN_FIXME should be inspected if it required for windows
bus/dispatch.c:#ifdef DBUS_WIN_FIXME
cmake/config.h.cmake:# define DBUS_WIN_FIXME 1
dbus/dbus-memory.c:#ifdef DBUS_WIN_FIXME
```
cmake/config.h.cmake is only used under CMake, not Autotools.
The practical result is that:
* The test for GetConnectionUnixProcessID is skipped when built for Windows with CMake, but not when built for Windows with Autotools. This is certainly wrong: GetConnectionUnixProcessID() is a cross-platform feature now, so we should fix that test so that it can pass on Windows (which I think !55 does) and enable it everywhere.
* The tests for what happens when malloc() returns NULL are skipped when built for Windows with CMake, but not when built for Windows with Autotools. We should decide whether libdbus on Windows aims to be robust against out-of-memory conditions.
* If it does, we should run these tests, even though they're slow (you can temporarily skip them for quicker testing with the `DBUS_TEST_MALLOC_FAILURES` environment variable).
* If it doesn't, we should probably make `dbus_malloc()` and friends abort on out-of-memory, like GLib's equivalents do, when running on Windows.https://gitlab.freedesktop.org/dbus/dbus/-/issues/242CI: No space left on device2018-12-11T12:21:01ZRalf HabackerCI: No space left on deviceOn a local CI pipeline https://gitlab.freedesktop.org/rhabacker/dbus/pipelines/11126 most dbus builds are broken because of not enough space on device.
Not sure if that would solve the dedicated issue, but a disk usage check I did some ...On a local CI pipeline https://gitlab.freedesktop.org/rhabacker/dbus/pipelines/11126 most dbus builds are broken because of not enough space on device.
Not sure if that would solve the dedicated issue, but a disk usage check I did some weeks ago for dbus related packages showed me, that xmlto package needs about 1 GB device space. Multiplied with the number of builds (12) it occupies about 12GB, where xsltproc including docbook stylesheets requires only a few MB.https://gitlab.freedesktop.org/dbus/dbus/-/issues/243test-syslog fails on Windows2019-01-16T12:14:08ZRalf Habackertest-syslog fails on Windowstest-syslog is currently non functional on Windows
```
cd Z:/home/ralf.habacker/src/dbus-cmake-cross-build
ctest -VV -R ^test-syslog$
UpdateCTestConfiguration from :Z:/home/xxx/src/dbus-cmake-cross-build/DartConfiguration.tcl
UpdateCTes...test-syslog is currently non functional on Windows
```
cd Z:/home/ralf.habacker/src/dbus-cmake-cross-build
ctest -VV -R ^test-syslog$
UpdateCTestConfiguration from :Z:/home/xxx/src/dbus-cmake-cross-build/DartConfiguration.tcl
UpdateCTestConfiguration from :Z:/home/xxx/src/dbus-cmake-cross-build/DartConfiguration.tcl
Test project Z:/home/xxx/src/dbus-cmake-cross-build
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 18
Start 18: test-syslog
18: Test command: Z:\home\xxx\src\dbus-cmake-cross-build\bin\test-syslog.exe "--tap"
18: Environment variables:
18: DBUS_TEST_DAEMON=z:/home/xxx/src/dbus-cmake-cross-build/bin/dbus-daemon.exe
18: DBUS_SESSION_BUS_ADDRESS=
18: DBUS_FATAL_WARNINGS=1
18: DBUS_TEST_DATA=z:/home/xxx/src/dbus-cmake-cross-build/test/data
18: DBUS_TEST_DBUS_LAUNCH=z:/home/xxx/src/dbus-cmake-cross-build/bin/dbus-launch.exe
18: DBUS_TEST_EXEC=z:/home/xxx/src/dbus-cmake-cross-build/bin
18: DBUS_TEST_HOMEDIR=z:/home/xxx/src/dbus-cmake-cross-build/dbus
18: DBUS_TEST_UNINSTALLED=1
18: Test timeout computed to be: 10000000
18: # random seed: R02S528e6a45d105517b5156d9c56f7dbd0f
18: 1..1
18: # Start of syslog tests
18: # child process (/syslog/normal) exit status: 0 (success)
18: # child process (/syslog/normal) stdout: ""
18: # child process (/syslog/normal) stderr: "test-syslog[1372]: info: regression test for _dbus_log(): 42\r\ntest-syslog[1372]: warning: regression test for _dbus_log(): 45\r\ntest-syslog[1372]: security: regression test for _dbus_log(): 666\r\ntest-syslog[1372]: error: regression test for _dbus_log(): 23\r\ntest-syslog-stderr[1372]: info: regression test for _dbus_log(): this should not appear in the syslog\r\ntest-syslog-both[1372]: info: regression test for _dbus_log(): this should appear in the syslog and on stderr\r\n"
18: **
18: ERROR:/home/xxx/src/dbus/test/internals/syslog.c:89:test_syslog_normal: stderr of child process (/syslog/normal) failed to match: *regression test for _dbus_log(): 42
18: *regression test for _dbus_log(): 45
18: *regression test for _dbus_log(): 666
18: *regression test for _dbus_log(): 23
18: *test-syslog-stderr*regression test for _dbus_log(): this should not appear in the syslog
18: *test-syslog-both*regression test for _dbus_log(): this should appear in the syslog and on stderr
18:
18: Bail out! ERROR:/home/xxx/src/dbus/test/internals/syslog.c:89:test_syslog_normal: stderr of child process (/syslog/normal) failed to match: *regression test for _dbus_log(): 42
18: *regression test for _dbus_log(): 45
18: *regression test for _dbus_log(): 666
18: *regression test for _dbus_log(): 23
18: *test-syslog-stderr*regression test for _dbus_log(): this should not appear in the syslog
18: *test-syslog-both*regression test for _dbus_log(): this should appear in the syslog and on stderr
18:
1/1 Test #18: test-syslog ......................***Failed 0.12 sec
0% tests passed, 1 tests failed out of 1
Total Test time (real) = 0.22 sec
The following tests FAILED:
18 - test-syslog (Failed)
Errors while running CTest
```https://gitlab.freedesktop.org/dbus/dbus/-/issues/244Huge variations for test-refs running time2018-12-14T13:08:02ZRalf HabackerHuge variations for test-refs running timeRunning test-refs on different environments shows huge differences for the time required to perform the test.
Windows 7 (virtualbox guest on linux host - 4 cores)
```
Start 14: test-refs
14/25 Test #14: test-refs ....................Running test-refs on different environments shows huge differences for the time required to perform the test.
Windows 7 (virtualbox guest on linux host - 4 cores)
```
Start 14: test-refs
14/25 Test #14: test-refs ........................ Passed 220.80 sec
```
Windows 10 (virtualbox guest on linux host - 1 core)
```
Start 14: test-refs
14/25 Test #14: test-refs ........................ Passed 10.00 sec
```
Wine (16 core linux system, host for above mentioned guest systems)
```
Start 14: test-refs
14/25 Test #14: test-refs ........................ Passed 86.65 sec
```
The huge time for running with wine is a known issue. I was fixed with bug https://bugs.freedesktop.org/show_bug.cgi?id=92538 and worked 3 years ago, but unfortunally not with current wine versions (3.x)https://gitlab.freedesktop.org/dbus/dbus/-/issues/245Outdated wiki section "Reporting Bugs & Sending Patches"2018-12-17T15:50:53ZRalf HabackerOutdated wiki section "Reporting Bugs & Sending Patches"The mentioned section located at https://www.freedesktop.org/wiki/Software/dbus/#index3h1 still points to bugzilla.The mentioned section located at https://www.freedesktop.org/wiki/Software/dbus/#index3h1 still points to bugzilla.https://gitlab.freedesktop.org/dbus/dbus/-/issues/246autolaunch:scope=*install-path for Mac2021-05-06T08:40:49ZHannah von Rethautolaunch:scope=*install-path for MacOn Windows we have the feature and it enables us to provide standalone installers for KDE applications.
To improve our KDE Mac support it would be awesome to have something similar there, to allow a autolaunched dbus per .app dir.
Thanks.On Windows we have the feature and it enables us to provide standalone installers for KDE applications.
To improve our KDE Mac support it would be awesome to have something similar there, to allow a autolaunched dbus per .app dir.
Thanks.https://gitlab.freedesktop.org/dbus/dbus/-/issues/247Add --version command line option to dbus-montior, dbus-send, dbus-test-tool ...2018-12-27T10:31:43ZДилян ПалаузовAdd --version command line option to dbus-montior, dbus-send, dbus-test-tool and dbus-update-activation-environmenthttps://gitlab.freedesktop.org/dbus/dbus/-/issues/248P2P External auth on MacOS fails to getpeereid() credentials: Invalid argument2019-01-04T20:19:12ZRoland RoßgottererP2P External auth on MacOS fails to getpeereid() credentials: Invalid argumentI was investigating a bug in my application using DBus on MacOS. Everything runs fine when using the session bus, but as soon as I'm using a DBusServer setup to listen on TCP localhost:45001, the connection fails at the authentication le...I was investigating a bug in my application using DBus on MacOS. Everything runs fine when using the session bus, but as soon as I'm using a DBusServer setup to listen on TCP localhost:45001, the connection fails at the authentication level.
Attached is the verbose log of that connection attempt. What could be the cause is
`[dbus-sysdeps-unix.c(2188):_dbus_read_credentials_socket] Failed to getpeereid() credentials: Invalid argument`
[external_auth.rtf](/uploads/5b6da27bcb3262d80d1432b56ab563ea/external_auth.rtf)
If you need any further information, just let me know.https://gitlab.freedesktop.org/dbus/dbus/-/issues/249autoconf fails with autoconf-archive v2019.01.062022-05-27T03:01:41ZMichael Gilbertautoconf fails with autoconf-archive v2019.01.06Running autoreconf in the dbus source tree with autoconf-archive v2019.01.06 installed produces the following error:
```
***** autoconf *****
***** PWD: /var/tmp/portage/sys-apps/dbus-1.12.12/work/dbus-1.12.12
***** autoconf --force
co...Running autoreconf in the dbus source tree with autoconf-archive v2019.01.06 installed produces the following error:
```
***** autoconf *****
***** PWD: /var/tmp/portage/sys-apps/dbus-1.12.12/work/dbus-1.12.12
***** autoconf --force
configure:18977: error: Unexpanded AX_ macro found. Please install GNU autoconf-archive
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
```
It looks like it is catching a shell variable named AX_CHECK_GNU_MAKE_HEADLINE from ax_check_gnu_make.m4.
http://git.savannah.nongnu.org/cgit/autoconf-archive.git/tree/m4/ax_check_gnu_make.m4?h=v2019.01.06#n83
Downstream bug report: https://bugs.gentoo.org/674830https://gitlab.freedesktop.org/dbus/dbus/-/issues/250hash table implementation seems to be broken when using string key2019-01-08T11:01:08ZRalf Habackerhash table implementation seems to be broken when using string keyWhile working on !78 a bug in the hash table implementation raised up https://gitlab.freedesktop.org/dbus/dbus/merge_requests/78#note_99978. Simply changing the key type from int to string for pollables (https://gitlab.freedesktop.org/r...While working on !78 a bug in the hash table implementation raised up https://gitlab.freedesktop.org/dbus/dbus/merge_requests/78#note_99978. Simply changing the key type from int to string for pollables (https://gitlab.freedesktop.org/rhabacker/dbus/commits/hash-table-string-key-issue) breaks watch management in mainloop.
see https://gitlab.freedesktop.org/rhabacker/dbus/pipelines/14269 for the failing jobshttps://gitlab.freedesktop.org/dbus/dbus/-/issues/251test-bus freezes with WSACreateEvent/WSAEventSelect based implementation of d...2019-01-09T11:57:35ZRalf Habackertest-bus freezes with WSACreateEvent/WSAEventSelect based implementation of dbus_poll in WindowsWith !78 one task is to provide a poll implementation based on WSACreateEvent/WSAEventSelect to be able to wait on handles and sockets in one system call. Fortunally dbus windows source code already provides a related implementation http...With !78 one task is to provide a poll implementation based on WSACreateEvent/WSAEventSelect to be able to wait on handles and sockets in one system call. Fortunally dbus windows source code already provides a related implementation https://gitlab.freedesktop.org/dbus/dbus/blob/master/dbus/dbus-sysdeps-win.c#L1170.
A quick test showed that this implementation is in a state that for example dbus-send/dbus-monitor can connect to dbus-daemon and can call dbus methods.
In the opposite the dispatch tests from test-bus are not working and freezes and need to be fixed.https://gitlab.freedesktop.org/dbus/dbus/-/issues/252Inconsistent use of spaces in cmake build system files2019-01-23T20:52:38ZRalf HabackerInconsistent use of spaces in cmake build system filesFor historical reasons, the files of the cmake build system sometimes use tabs instead of spaces to indent commands. This should be cleaned up.For historical reasons, the files of the cmake build system sometimes use tabs instead of spaces to indent commands. This should be cleaned up.https://gitlab.freedesktop.org/dbus/dbus/-/issues/253Locally installed services can't add dbus configuration2019-03-25T20:18:43ZMario LimoncielloLocally installed services can't add dbus configurationA report was received in upstream fwupd about how the daemon wasn't able to start after the following commands:
```
# meson build
# ninja -C build
# ninja -C build install
```
This placed everything in `/usr/local by default`.
It also cr...A report was received in upstream fwupd about how the daemon wasn't able to start after the following commands:
```
# meson build
# ninja -C build
# ninja -C build install
```
This placed everything in `/usr/local by default`.
It also created an `/usr/local/etc/dbus-1/system.d/org.freedesktop.conf`
The daemon can (attempt to) be started by:
`/usr/local/libexec/fwupd/fwupd -v`
It fails to acquire org.freedesktop.fwupd on dbus system bus however.
This is because by default dbus does not examine files in `/usr/local/etc/dbus-1/system.d` because it only looks at
```
<includedir>@SYSCONFDIR_FROM_PKGDATADIR@/dbus-1/system.d</includedir>
```
This issue can be fixed if the following is added to `/usr/share/dbus-1/system.conf`:
```
<includedir>/usr/local/etc/dbus-1/system.d</includedir>
```
So can dbus's default configuration be set to look in `/usr/local/etc/dbus-1/system.d` "explicitly" in addition to the `SYSCONFDIR_FROM_PKGDATADIR` directory?https://gitlab.freedesktop.org/dbus/dbus/-/issues/254Several files do not have a copyright definition2019-01-21T14:51:08ZRalf HabackerSeveral files do not have a copyright definitionWhile reviewing !1 it turned out that several files do not have a copyright definition in the file.
I used the following script to find out these cases:
```
!/bin/sh
for i in $(git ls-files | grep ".[hc]$"); do
a=$(grep -i "copyri...While reviewing !1 it turned out that several files do not have a copyright definition in the file.
I used the following script to find out these cases:
```
!/bin/sh
for i in $(git ls-files | grep ".[hc]$"); do
a=$(grep -i "copyright" $i)
if test -z "$a"; then
echo "$i has no copyright"
fi
done
```
which returns
```
autogen.sh has no copyright
bus/apparmor.h has no copyright
bus/audit.h has no copyright
bus/selinux.c has no copyright
bus/selinux.h has no copyright
bus/stats.h has no copyright
cleanup-man-pages.sh has no copyright
configure.ac has no copyright
test/glib-tap-test.sh has no copyright
test/manual-dir-iter.c has no copyright
test/manual-paths.c has no copyright
test/manual-tcp.c has no copyright
test/name-test/run-test-systemserver.sh has no copyright
test/name-test/run-test.sh has no copyright
test/name-test/test-autolaunch.c has no copyright
test/name-test/test-ids.c has no copyright
test/name-test/test-pending-call-timeout.c has no copyright
test/name-test/test-privserver-client.c has no copyright
test/name-test/test-shutdown.c has no copyright
test/name-test/test-threads-init.c has no copyright
test/shell-test.c has no copyright
test/spawn-test.c has no copyright
test/test-exit.c has no copyright
test/test-names.c has no copyright
test/test-segfault.c has no copyright
test/test-service.c has no copyright
test/test-shell-service.c has no copyright
test/test-sleep-forever.c has no copyright
test/test-utils.c has no copyright
test/test-utils.h has no copyright
tools/run-with-tmp-session-bus.sh has no copyright
```https://gitlab.freedesktop.org/dbus/dbus/-/issues/255CMake builds from tarball releases are not tested2019-01-21T16:23:53ZSimon McVittieCMake builds from tarball releases are not testedIf our aim is for it to be possible to build official dbus tarball releases (which come from Autotools `make dist`) with CMake, then we should probably change at least one of the CMake CI jobs in `tools/ci-build.sh` so that instead of bu...If our aim is for it to be possible to build official dbus tarball releases (which come from Autotools `make dist`) with CMake, then we should probably change at least one of the CMake CI jobs in `tools/ci-build.sh` so that instead of building with CMake directly from git, it does a `./configure` and `make dist` with Autotools, unpacks the resulting tarball, and uses CMake to build *that*.
(Doing an Autotools build from a tarball release is already exercised in CI, because `make distcheck` does that for us.)https://gitlab.freedesktop.org/dbus/dbus/-/issues/256File descriptor leaked in .dbus/dbus-message-util.c on running test-bus[-disp...2019-01-28T11:18:17ZRalf HabackerFile descriptor leaked in .dbus/dbus-message-util.c on running test-bus[-dispatch][-sha1] with installed sssd version 1.13.4On an opensuse leap 42.3 installation test-bus, test-bus-dispatch and test-bus-dispatch-sha1 build from git master branch fails with a leaked file descriptor regardless from the used build system.
The following test runs shows the issue...On an opensuse leap 42.3 installation test-bus, test-bus-dispatch and test-bus-dispatch-sha1 build from git master branch fails with a leaked file descriptor regardless from the used build system.
The following test runs shows the issue from a cmake build:
```
DBUS_TEST_DATA=/home/xxx/src/dbus-cmake-build/test/data bin/test-bus
...
8: ok 3 - config-parser
8: # config-parser test took 0 seconds
8: ok 4 - config-parser did not leak memory
8: Bail out! file descriptor 4 leaked in /home/xxx/src/dbus/dbus/dbus-message-util.c.
```
```
DBUS_TEST_DATA=/home/xxx/src/dbus-cmake-build/test/data bin/test-bus-dispatch
...
9: # dispatch test took 58 seconds
9: ok 26 - dispatch did not leak memory
9: Bail out! file descriptor 9 leaked in /home/xxx/src/dbus/dbus/dbus-message-util.c.
```
```
DBUS_TEST_DATA=/home/xxx/src/dbus-cmake-build/test/data bin/test-bus-dispatch-sha1
...
ok 1 - dispatch-sha1
# dispatch-sha1 test took 15 seconds
ok 2 - dispatch-sha1 did not leak memory
Bail out! file descriptor 9 leaked in /home/ralf/src/dbus/dbus/dbus-message-util.c.
```
In the test-bus case (and the two other) the leaked file descriptor is:
```
lr-x------ 1 xxx users 64 22. Jan 21:52 4 -> /var/lib/sss/mcpath/initgroups
```
As Simon mentioned in https://gitlab.freedesktop.org/dbus/dbus/merge_requests/84#note_106999 was this file opened
```
DBUS_TEST_DATA=/home/xxx/src/dbus-cmake-build/test/data strace bin/test-bus 2>&1 | grep /var/lib/sss
open("/var/lib/sss/mcpath/initgroups", O_RDONLY|O_CLOEXEC) = 4
```
but not closed. Fortunally this file descriptor has already set 'close-on-exec', which would make it possible to follow Simons hint:
> make sure the fd is marked close-on-exec, and make `_dbus_check_fdleaks_leave()` ignore fds that are close-on-exec;
because all other open fd's does not have this flags set.https://gitlab.freedesktop.org/dbus/dbus/-/issues/257Consider using LDADD to simplify executables' linked libraries2019-01-23T20:31:04ZSimon McVittieConsider using LDADD to simplify executables' linked libraries@pwithnall writes:
> If you want to apply `$(CODE_COVERAGE_LIBS)` to all the build targets in this file, you could potentially set `LDADD = $(CODE_COVERAGE_LIBS)`. Note it’s not `AM_LDADD`, because that doesn’t exist (apparently; I haven...@pwithnall writes:
> If you want to apply `$(CODE_COVERAGE_LIBS)` to all the build targets in this file, you could potentially set `LDADD = $(CODE_COVERAGE_LIBS)`. Note it’s not `AM_LDADD`, because that doesn’t exist (apparently; I haven’t verified in the autotools source).https://gitlab.freedesktop.org/dbus/dbus/-/issues/258Gather coverage stats from GitLab CI2019-01-24T10:20:39ZSimon McVittieGather coverage stats from GitLab CI@pwithnall writes:
> Have you considered hooking [coverage stats] up to GitLab CI? There are two things to do there:
>
> - Run `lcov` as part of a CI step after all the tests succeed, and export the HTML pages as artifacts. GLib does tha...@pwithnall writes:
> Have you considered hooking [coverage stats] up to GitLab CI? There are two things to do there:
>
> - Run `lcov` as part of a CI step after all the tests succeed, and export the HTML pages as artifacts. GLib does that [here](https://gitlab.gnome.org/GNOME/glib/blob/85b5a72e699a20a65d116805670db14a1db45cad/.gitlab-ci.yml#L156).
>
> - Note the `coverage: (regex)` line there. You can add a badge to GitLab [here](https://gitlab.freedesktop.org/dbus/dbus/edit) which shows the `master` coverage at a glance. GLib uses these settings:
> - Link: https://gnome.pages.gitlab.gnome.org/glib/coverage/
> - Badge image URL: [https://gitlab.gnome.org/%{project_path}/badges/%{default_branch}/coverage.svg](https://gitlab.gnome.org/%%7Bproject_path%7D/badges/%%7Bdefault_branch%7D/coverage.svg)https://gitlab.freedesktop.org/dbus/dbus/-/issues/259_dbus_daemon_is_session_bus_address_published() does more in name specified2019-02-06T10:38:13ZRalf Habacker_dbus_daemon_is_session_bus_address_published() does more in name specifiedWhile working on #235, the _dbus_daemon_is_session_bus_address_published() function was used in an Autolaunch test program for an internal check as to whether autostart is enabled or not.
It was found that this function is not suitable ...While working on #235, the _dbus_daemon_is_session_bus_address_published() function was used in an Autolaunch test program for an internal check as to whether autostart is enabled or not.
It was found that this function is not suitable for the intended purpose as it blocks autolaunch support at the same time.https://gitlab.freedesktop.org/dbus/dbus/-/issues/260dbus crash in link_before2019-03-15T17:38:56ZHarvey Cdbus crash in link_beforeHi I am working on an open-source project, and recently we ran into this dbus crash, woondering if this is a known issue ? any suggestion on what the cause could be ?
<pre>
#0 link_before libdbus-1.so.3.7.6 dbus/1.6.18-r0/dbus-1.6....Hi I am working on an open-source project, and recently we ran into this dbus crash, woondering if this is a known issue ? any suggestion on what the cause could be ?
<pre>
#0 link_before libdbus-1.so.3.7.6 dbus/1.6.18-r0/dbus-1.6.18/dbus/dbus-list.c:113 (0x0)
#1 _dbus_list_prepend_link libdbus-1.so.3.7.6 dbus/1.6.18-r0/dbus-1.6.18/dbus/dbus-list.c:325 (0x6)
#2 _dbus_list_append_link libdbus-1.so.3.7.6 dbus/1.6.18-r0/dbus-1.6.18/dbus/dbus-list.c:307 (0x2)
#3 _dbus_connection_queue_synthesized_message_link libdbus-1.so.3.7.6 dbus-1.6.18/dbus/dbus-connection.c:557 (0x6)
#4 _dbus_connection_get_dispatch_status_unlocked libdbus-1.so.3.7.6 dbus/1.6.18-r0/dbus-1.6.18/dbus/dbus-connection.c:4194 (0xa)
#5 _dbus_connection_flush_unlocked libdbus-1.so.3.7.6 dbus/1.6.18-r0/dbus-1.6.18/dbus/dbus-connection.c:3584 (0x6)
#6 _dbus_connection_block_pending_call libdbus-1.so.3.7.6 dbus/1.6.18-r0/dbus-1.6.18/dbus/dbus-connection.c:2382 (0x2)
#7 dbus_pending_call_block libdbus-1.so.3.7.6 dbus/1.6.18-r0/dbus-1.6.18/dbus/dbus-pending-call.c:748 (0x2)
#8 dbus_connection_send_with_reply_and_block libdbus-1.so.3.7.6 dbus/1.6.18-r0/dbus-1.6.18/dbus/dbus-connection.c:3530 (0x6)
#9 dbus_bus_register libdbus-1.so.3.7.6 dbus/1.6.18-r0/dbus-1.6.18/dbus/dbus-bus.c:692 (0x12)
thanks,https://gitlab.freedesktop.org/dbus/dbus/-/issues/261Cross compiling dbus 1.12.10 fails with "Unexpanded AX_ macro found"2019-03-16T08:48:52ZRalf HabackerCross compiling dbus 1.12.10 fails with "Unexpanded AX_ macro found"While trying to update cross compiled dbus to 1.12.10 at https://build.opensuse.org/package/show/home:rhabacker:branches:windows:mingw:win32/mingw32-dbus-1 the following error occurs.
```
[ 131s] configure:18929: error: Unexpanded AX_ m...While trying to update cross compiled dbus to 1.12.10 at https://build.opensuse.org/package/show/home:rhabacker:branches:windows:mingw:win32/mingw32-dbus-1 the following error occurs.
```
[ 131s] configure:18929: error: Unexpanded AX_ macro found. Please install GNU autoconf-archive
[ 131s] If this token and others are legitimate, please use m4_pattern_allow.
[ 131s] See the Autoconf documentation.
[ 131s] autoconf failed - version 2.5x is probably required
```
Installed versions are
autoconf-archive-2019.01.06
autoconf-2.69
[_log.txt](/uploads/d001b76acc5830480c1478cae82f7741/_log.txt)https://gitlab.freedesktop.org/dbus/dbus/-/issues/262dbus git : compilation failure (windows MSYS2 + mingw-w64, cmake)2019-03-15T17:03:35Zvtorridbus git : compilation failure (windows MSYS2 + mingw-w64, cmake)Hello
for a autotooled project, unit tests need dbus-run-session on Windows. It seems that git dbus has an implementation. So i tried to compile it with cmake (autotools have errors with the AX_* macros...).
First, i don't know much ab...Hello
for a autotooled project, unit tests need dbus-run-session on Windows. It seems that git dbus has an implementation. So i tried to compile it with cmake (autotools have errors with the AX_* macros...).
First, i don't know much about cmake.
Second, to have a coherent set of dependencies, i've compiled all the dependencies of the project mysel, including iconv (win-iconv) and expat, which are dependencies of git dbus. The are all installed in /opt/ewpi_32/
Third, iconv and expat have already been installed by previously installed packages (certainly the i686 mingw-w64 toolchain) in /mingw32/
my cmake command (after creating a subdir and entering it) :
cmake -DCMAKE_INSTALL_PREFIX=/opt/dbus -DCMAKE_VERBOSE_MAKEFILE=TRUE -DCMAKE_C_COMPILER=i686-w64-mingw32-gcc -DCMAKE_CXX_COMPILER=i686-w64-mingw32-g++ -DCMAKE_BUILD_TYPE=Release -DCMAKE_SYSTEM_NAME=Windows -G "Unix Makefiles" -DEXPAT_INCLUDE_DIR=/opt/ewpi_32/include -DLIBICONV_INCLUDE_DIR=/opt/ewpi_32/include -DLIBICONV_LIBRARIES=iconv -DCMAKE_C_FLAGS="-I.. -I../.. -I../builddir" -DCMAKE_CXX_FLAGS="-I.. -I../.." ..
output for iconv and expat :
a) there is no iconv output since i have added -DLIBICONV_INCLUDE_DIR=/opt/ewpi_32/include -DLIBICONV_LIBRARIES=iconv
but... iconv appears nowhere in code ('git grep iconv' shows at least nothing in source code)
b) -- Found EXPAT: D:/Documents/msys2/opt/ewpi_32/lib/libexpat.dll.a (found version "2.2.5")
My questions / remarks :
1) I have to add myself -DCMAKE_C_FLAGS="-I.. -I../.. -I../builddir" -DCMAKE_CXX_FLAGS="-I.. -I../.." otherwise some header files are not found
I think that the current configuration done by cmake is not complete. As a user, i shouldn't have to set CMAKE_C_FLAGS and CMAKE_CXX_FLAGS. This is the job of the build system (cmake, here), not mine.
2) Should the check of iconv be dropped in CMakeList.txt ?
3) i then run 'make'. When creating gbus-daemon.exe, I have a link error :
/mingw32/bin/i686-w64-mingw32-gcc.exe -I.. -I../.. -I../builddir -Wsign-compare -O3 -DNDEBUG -Wl,--whole-archive CMakeFiles/dbus-daemon.dir/objects.a -Wl,--no-whole-archive -o ../bin/dbus-daemon.exe -Wl,--out-implib,../lib/libdbus-daemon.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles/dbus-daemon.dir/linklibs.rsp
D:/Documents/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.4.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lD:/Documents/msys2/opt/ewpi_32/lib/libexpat.dll.a
What is passed to -l is wrong, instead of passing -LD:/Documents/msys2/opt/ewpi_32/lib -lexpat
does someone know why there is this error ? are my expat flags passed to cmake wrong ?
thank you
Vincent Torrihttps://gitlab.freedesktop.org/dbus/dbus/-/issues/263install fails with --program-suffix=-mp2019-05-13T09:56:13ZRené Bertininstall fails with --program-suffix=-mpExtract from install (to DESTDIR) log:
```
libtool: install: /usr/bin/install -c .libs/dbus-daemon-launch-helper /path/to/destroot/opt/local/libexec/./dbus-daemon-launch-helper-mp
/usr/bin/make install-exec-hook
make[3]: Entering direc...Extract from install (to DESTDIR) log:
```
libtool: install: /usr/bin/install -c .libs/dbus-daemon-launch-helper /path/to/destroot/opt/local/libexec/./dbus-daemon-launch-helper-mp
/usr/bin/make install-exec-hook
make[3]: Entering directory `/path/to/dbus-1.12.12/bus'
if test `id -u` -eq 0; then \
chown root:messagebus /path/to/destroot/opt/local/libexec/dbus-daemon-launch-helper; \
chmod 4750 /path/to/destroot/opt/local/libexec/dbus-daemon-launch-helper; \
else \
echo "Not installing /path/to/destroot/opt/local/libexec/dbus-daemon-launch-helper binary setuid!"; \
echo "You'll need to manually set permissions to root:messagebus and permissions 4750"; \
fi
chown: cannot access ‘/path/to/destroot/opt/local/libexec/dbus-daemon-launch-helper’: No such file or directory
chmod: cannot access ‘/path/to/destroot/opt/local/libexec/dbus-daemon-launch-helper’: No such file or directory
make[3]: *** [install-exec-hook] Error 1
make[3]: Leaving directory `/path/to/dbus-1.12.12/bus'
make[2]: *** [install-exec-am] Error 2
make[2]: Leaving directory `/path/to/dbus-1.12.12/bus'
make[1]: *** [install-am] Error 2
make[1]: Leaving directory `/path/to/dbus-1.12.12/bus'
make: *** [install-recursive] Error 1
make: Leaving directory `/path/to/dbus-1.12.12'
Command failed: cd "/path/to/dbus-1.12.12" && /usr/bin/make -w install DESTDIR=/path/to/destroot
Exit code: 2
Failed to destroot dbus: command execution failed
```https://gitlab.freedesktop.org/dbus/dbus/-/issues/264g_dbus_interface_get_info assertion 'G_IS_DBUS_INTERFACE (interface_)' failed2019-03-11T16:54:09Zwestsuhanicg_dbus_interface_get_info assertion 'G_IS_DBUS_INTERFACE (interface_)' failedHello:
I am running 4.19.27-gentoo-r1.
My application which has been running for 2 years without issue is now getting the
following message:
GLib-GIO-CRITICAL **: 12:14:25.453: g_dbus_interface_get_info: assertion 'G_IS_DBUS_INTERFACE...Hello:
I am running 4.19.27-gentoo-r1.
My application which has been running for 2 years without issue is now getting the
following message:
GLib-GIO-CRITICAL **: 12:14:25.453: g_dbus_interface_get_info: assertion 'G_IS_DBUS_INTERFACE (interface_)' failed
How would I go about addressing this?
thabnk you,
west suhanichttps://gitlab.freedesktop.org/dbus/dbus/-/issues/265Autotools build fails with Makefile:1083: *** missing separator. Stop2020-02-20T13:15:57ZRalf HabackerAutotools build fails with Makefile:1083: *** missing separator. StopAfter applying the patch mentioned at #261 the build fails with
```
Makefile:1083: *** missing separator. Stop
```
The reason is an unexpanded variable:
```
Makefile
1082: # Add rules for code-coverage testing, as defined by AX_CODE...After applying the patch mentioned at #261 the build fails with
```
Makefile:1083: *** missing separator. Stop
```
The reason is an unexpanded variable:
```
Makefile
1082: # Add rules for code-coverage testing, as defined by AX_CODE_COVERAGE
1083: @CODE_COVERAGE_RULES@
```
[_log.txt](/uploads/488bdc63e81384c59afd283bd9a02377/_log.txt)https://gitlab.freedesktop.org/dbus/dbus/-/issues/266CMake build failure: error: Could not create output directory /builds/dbus/db...2020-04-21T12:23:28ZSimon McVittieCMake build failure: error: Could not create output directory /builds/dbus/dbus/dbus-1.13.9/ci-build-production-native/doc/api/xmlhttps://gitlab.freedesktop.org/dbus/dbus/-/jobs/244138
```
make[2]: Leaving directory '/builds/dbus/dbus/dbus-1.13.9/ci-build-production-native'
make -f doc/CMakeFiles/devhelp2.dir/build.make doc/CMakeFiles/devhelp2.dir/build
make[2]: E...https://gitlab.freedesktop.org/dbus/dbus/-/jobs/244138
```
make[2]: Leaving directory '/builds/dbus/dbus/dbus-1.13.9/ci-build-production-native'
make -f doc/CMakeFiles/devhelp2.dir/build.make doc/CMakeFiles/devhelp2.dir/build
make[2]: Entering directory '/builds/dbus/dbus/dbus-1.13.9/ci-build-production-native'
cd /builds/dbus/dbus/dbus-1.13.9/ci-build-production-native/doc && /usr/bin/doxygen /builds/dbus/dbus/dbus-1.13.9/ci-build-production-native/Doxyfile
[ 35%] Generating API documentation with Doxygen
cd /builds/dbus/dbus/dbus-1.13.9/ci-build-production-native/doc && /usr/bin/cmake -E make_directory /builds/dbus/dbus/dbus-1.13.9/ci-build-production-native/doc/api/html
cd /builds/dbus/dbus/dbus-1.13.9/ci-build-production-native/doc && /usr/bin/doxygen /builds/dbus/dbus/dbus-1.13.9/ci-build-production-native/Doxyfile
warning: Tag `HTML_ALIGN_MEMBERS' at line 96 of file `/builds/dbus/dbus/dbus-1.13.9/ci-build-production-native/Doxyfile' has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
warning: Tag `HTML_ALIGN_MEMBERS' at line 96 of file `/builds/dbus/dbus/dbus-1.13.9/ci-build-production-native/Doxyfile' has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
warning: Tag `MAX_DOT_GRAPH_WIDTH' at line 174 of file `/builds/dbus/dbus/dbus-1.13.9/ci-build-production-native/Doxyfile' has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
warning: Tag `MAX_DOT_GRAPH_WIDTH' at line 174 of file `/builds/dbus/dbus/dbus-1.13.9/ci-build-production-native/Doxyfile' has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
warning: Tag `MAX_DOT_GRAPH_HEIGHT' at line 175 of file `/builds/dbus/dbus/dbus-1.13.9/ci-build-production-native/Doxyfile' has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
warning: Tag `MAX_DOT_GRAPH_HEIGHT' at line 175 of file `/builds/dbus/dbus/dbus-1.13.9/ci-build-production-native/Doxyfile' has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
error: Could not create output directory /builds/dbus/dbus/dbus-1.13.9/ci-build-production-native/doc/api/xml
doc/CMakeFiles/devhelp2.dir/build.make:209: recipe for target 'doc/doxygen.stamp' failed
make[2]: Leaving directory '/builds/dbus/dbus/dbus-1.13.9/ci-build-production-native'
make[2]: *** [doc/doxygen.stamp] Error 1
CMakeFiles/Makefile2:3460: recipe for target 'doc/CMakeFiles/devhelp2.dir/all' failed
make[1]: *** [doc/CMakeFiles/devhelp2.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
```
I'm going to retry that build to see whether this is an intermittent bug.
I would guess that maybe we need to create `${CMAKE_BINARY_DIR}/doc` or `${CMAKE_BINARY_DIR}/doc/api` before writing things into it, like a CMake equivalent of the addition of `$(MKDIR_P)` in 6b17dd68?https://gitlab.freedesktop.org/dbus/dbus/-/issues/267Can we get a 1.12 release with the cmake/pkgconfig clobbering fix?2019-05-13T09:37:28ZAlbert Astals CidCan we get a 1.12 release with the cmake/pkgconfig clobbering fix?It would be cool if we could get a dbus release with https://gitlab.freedesktop.org/dbus/dbus/commit/3525cc045d4c683dfc6048f5be795cc372c323a3 in it, otherwise we need to have similar workarounds in our codebaseIt would be cool if we could get a dbus release with https://gitlab.freedesktop.org/dbus/dbus/commit/3525cc045d4c683dfc6048f5be795cc372c323a3 in it, otherwise we need to have similar workarounds in our codebasehttps://gitlab.freedesktop.org/dbus/dbus/-/issues/268dbus_message_iter_init returns false sometimes, and can then return true when...2019-05-18T11:50:16Zwoodhead99dbus_message_iter_init returns false sometimes, and can then return true when re-call it with the same dbus message?I am sorry if it is not a right place to post such issues.
dbus_message_iter_init returns false sometimes, and can return true when re-call it with the same dbus message.
The DBus message passed to the function is unmarshalled from a b...I am sorry if it is not a right place to post such issues.
dbus_message_iter_init returns false sometimes, and can return true when re-call it with the same dbus message.
The DBus message passed to the function is unmarshalled from a byte block over the TCP connection. It could return false one out of 5000 times. If I re-execute the function by jumping back with Gdb, it will return **true**. Is there something to notice when using DBus message related functions?
the DBus package is dbus-1.12.12-7.fc30.x86_64
The code is [here](https://github.com/zhiming99/rpc-frmwrk/blob/1b4bc4a5e1cf3b4f6a4888e42cf5d88b5e37dfde/combase/dmsgptr.cpp#L274).https://gitlab.freedesktop.org/dbus/dbus/-/issues/269CVE-2019-12749: DBUS_COOKIE_SHA1 mechanism allows auth bypass when enabled2020-04-21T12:23:28ZJoe VennixCVE-2019-12749: DBUS_COOKIE_SHA1 mechanism allows auth bypass when enabledtl;dr summary:
* https://www.openwall.com/lists/oss-security/2019/06/11/2
* upgrade to 1.12.16+ (1.12.x branch), 1.13.12+ (development branch) or 1.10.28+ (1.10.x branch)
* or apply the version of commit "auth: Reject DBUS_COOKIE_SHA1 fo...tl;dr summary:
* https://www.openwall.com/lists/oss-security/2019/06/11/2
* upgrade to 1.12.16+ (1.12.x branch), 1.13.12+ (development branch) or 1.10.28+ (1.10.x branch)
* or apply the version of commit "auth: Reject DBUS_COOKIE_SHA1 for users other than the server owner" from the closest available branch, which is hopefully [1.12.x](https://gitlab.freedesktop.org/dbus/dbus/commit/47b1a4c41004bf494b87370987b222c934b19016)
-----
### Overview
`dbus`, when used as a library or run as root on a POSIX system with a configuration that allows the authentication type "DBUS_COOKIE_SHA1", suffers from a symlink traversal vulnerability that allows for a limited file-write-as-root primitive, which an attacker can abuse for a complete D-Bus authentication bypass.
The issue arises within the [DBUS_COOKIE_SHA1](https://dbus.freedesktop.org/doc/dbus-specification.html#auth-mechanisms-sha) authentication mechanism implemented by libdbus. This auth type seems to be intended for compatibility with non-POSIX systems that do not support passing credentials over sockets, or for D-Bus transport mechanisms that do not rely on Unix sockets like TCP. While `dbus` clearly recommends that this authentication type be disallowed outside of these usecases, it is up to the library or daemon configuration to explicitly disallow it:
> Recommend using SASL EXTERNAL where possible, or DBUS_COOKIE_SHA1 otherwise
**In general, this only affects consumers of libdbus that have not explicitly disallowed DBUS_COOKIE_SHA1**. As such, users of the well-known dbus-daemon system bus with its default `system.conf` that only allows `EXTERNAL` auth are not affected.
### Vulnerability
When a user requests the `DBUS_COOKIE_SHA1` authentication flow from a libdbus server, the server will proceed to check the `.dbus-keyrings/` directory in the desired user's homedir, and ensures that the directory is private to the owner:
if (!_dbus_check_dir_is_private_to_user (&keyring->directory, error))
return FALSE;
However, no symlink check is ever done, so a user that symlinks their local `~/.dbus-keyrings` directory to another user's `.dbus-keyrings` directory can trick the server into using the keyring of another user while trying to auth as themself.
### Recommended Fix
Fixing this issue is tricky and must be done carefully to avoid further TOUTTOC issues from occurring.
Similar privileged daemons like sshd that need to operate on user-specific files at the request of a user typically use fork() and setuid() to the requesting user, so that they temporarily run with the privileges of the user. This approach prevents these sorts of issues from ever occurring, as the unprivileged UID does not have necessary permissions to write to root's keyring.
If that approach is not an option, another approach for this issue could involve using `fd`-related syscalls to detect whether the fd - after it is opened - maps to the expected file path, before operating on the fd.
One way to do this is to have `_dbus_keyring_reload` (in `dbus-keyring.c`) open an fd to the expected keyrings directory. You can then use `fstat()` to check whether the fd itself is a symlink, and bail out if this is the case. After that, you would need to perform all reads and writes to the cookie files in this directory by passing the directory fd around and using `openat() ` or similar. That way in the case that the directory is swapped out for a symlink after the check, it will not be followed by the subsequent file operations. However this fix does not prevent the cookie files within the directory from being symlinks; this should be done in a similar fashion, with an `fstat()` call after the `openat` and before the file read or write.
### Proof of Concept
To demonstrate the vulnerability, run any package that uses libdbus to listen for D-Bus messages on a world-writable unix socket.
1. As any low-privileged user with a homedir, set up a symlink to root's homedir.
$ ln -s ~root/.dbus-keyrings ~/.dbus-keyrings
2. Now attempt to authenticate to the socket using the `DBUS_COOKIE_SHA1` mechanism as root, to make sure the `~root/.dbus-keyrings` dir is created:
#!/usr/bin/env python
import socket
import binascii
import getpass
ADDR="/path/to/socket"
client = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
client.connect(ADDR)
client.sendall(b"\0")
client.sendall(b"AUTH DBUS_COOKIE_SHA1 "+binascii.hexlify("root")+"\r\n")
print(client.recv(4096))
3. Wait about 3 minutes for the root user's cookie to expire (or just wipe out their cookie file as root, for purposes of demonstration).
3. Now attempt to authenticate to the socket using the `DBUS_COOKIE_SHA1` mechanism as your user:
#!/usr/bin/env python
import socket
import binascii
import getpass
ADDR="/path/to/socket"
client2 = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
client2.connect(ADDR)
client2.sendall(b"\0")
client2.sendall(b"AUTH DBUS_COOKIE_SHA1 "+binascii.hexlify(getpass.getuser())+"\r\n")
print(client2.recv(4096))
4. You will see a cookie ID printed. If you look in the root user's cookie file (`~root/.dbus-keyrings/org_freedesktop_general`), it becomes clear that the auth flow for the local user has been tricked into using the root user's cookie file:
$ sudo ls -al ~/.dbus-keyring/*
### Exploitation
On Linux systems this issue can be exploited in a way that allows arbitrary users to authenticate to the dbus server as root.
Exploiting this issue relies on moving files around at precise points while the dbus process operates on the local user's `~/.dbus-keyrings` directory. During the DBUS_COOKIE_SHA1 authentication flow, the dbus process will do the following things:
1. It will check that the `~user/.dbus-keyrings` exists and is private to the owner; if it does not exist, it will attempt to create this directory
2. If no valid cookies are in memory, it will open the `~user/.dbus-keyrings/org_freedesktop_general` keyring file and look for valid, non-expired cookies
3. If it finds no valid cookies, it will re-open the `org_freedesktop_general` file, load in any valid cookies, and create a new cookie
4. It will then re-write the `org_freedesktop_general` with all the cookies that are now in memory
To exploit this, the following filesystem conditions are set up by the unprivileged user at each point within their homedir:
1. A `~user/.dbus-keyrings` directory is created with 0700 permissions
2. A `org_freedesktop_general` file is created in this directory that contains several thousand expired keys
3. A new `org_freedesktop_general` file is created to contain one valid cookie and several thousand expired keys
4. The `~user/.dbus-keyrings` is replaced with a symlink to `~root/.dbus-keyrings`, which causes the write to happen on root's keyring file
At the end of the exploit chain, the attacker is able to place a controlled cookie into the root user's dbus keyring file, which allows them to legitimately authenticate to dbus as root.
The expired keys are used to lengthen the race condition window enough so that we can exploit it reliably by using file system metadata events from a subsystem like inotify.
### PoC
A [PoC python script](/uploads/306446083465cd083dd73cf66f0e8bb5/dbus_poc.py) is attached that demonstrates the vulnerability. The PoC results in a attacker-controlled cookie being reliably written to root's dbus keyring, which allows the attacker to authenticate as root as any user:
$ id
uid=1000(vagrant) gid=1000(vagrant) groups=1000(vagrant)
$ python dbus_poc.py
Sending auth as root to bootstrap root's keyring.
Installing our local keyring.
Sending Dbus auth request as our user.
Listening for inotify events below.
0: org_freedesktop_general
Replacing expired keyring with valid keyring.
1: org_freedesktop_general2
2: org_freedesktop_general.lock
3: org_freedesktop_general.lock
4: org_freedesktop_general.lock
5: org_freedesktop_general
Replacing keyring directory with a symlink to root's keyring directory.
You should have written a cookie ID=11, secret=10 to root's keyring.
# Validate with sudo:
$ sudo cat ~root/.dbus-keyrings/org_freedesktop_general
11 1559075632 10
### Disclosure
We can work with you to help reproduce the problems and have provided our assessment of the risk. We, of course, are keen to protect both Apple and your other customers and will coordinate with you on the announcement of the fixes. If you would like us to reach out to Mitre for CVE-IDs for these issues we're more than happy to do so. Please let us know your preference. Attribution for discovering this issue can be assigned to "Apple Information Security".
We have identified Ubuntu as a primary affected downstream consumer of this vulnerability, and have found several affected Ubuntu software packages that are vulnerable to this. We will be following up shortly with the Ubuntu Security Team around these packages, and will CC Dbus's private mailing list and reference this issue's ID to aid in coordination of disclosures between all parties.
If you have any issues or the provided PoC's are not working for some reason, please let us know and we'll investigate.https://gitlab.freedesktop.org/dbus/dbus/-/issues/270Follow-up from "Send destination prefix"2020-04-21T12:23:28ZSimon McVittieFollow-up from "Send destination prefix"The following discussion from !85 should be addressed:
- [x] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/85#note_169070):
> I'm tempted to rename this to `bus_connection_is_queued_owner_by_...The following discussion from !85 should be addressed:
- [x] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/85#note_169070):
> I'm tempted to rename this to `bus_connection_is_queued_owner_by_prefix()`, but that can be a follow-up after merging.Simon McVittieSimon McVittiehttps://gitlab.freedesktop.org/dbus/dbus/-/issues/2711.13.12: test suite test-autolaunch test is failing2019-07-03T14:13:00ZTomasz Kłoczko1.13.12: test suite test-autolaunch test is failing<pre><span style="background-color:#1C1C1C"><font color="#BCBCBC">=================================================</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC"> dbus 1.13.12: test/name-test/test-suite.log...<pre><span style="background-color:#1C1C1C"><font color="#BCBCBC">=================================================</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC"> dbus 1.13.12: test/name-test/test-suite.log</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC">=================================================</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC"># TOTAL: 217</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC"># PASS: 216</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC"># SKIP: 0</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC"># XFAIL: 0</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC"># FAIL: 1</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC"># XPASS: 0</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC"># ERROR: 0</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC">.. contents:: :depth: 2</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC">FAIL: run-test</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC">==============</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC">1..1</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC">*** Failed to autolaunch session bus: /home/tkloczko/rpmbuild/BUILD/dbus-dbus-1.13.12/tools/dbus-launch terminated abnormally with the following error: Autolaunch error:</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC"> X11 initialization failed.</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC"># running test test-autolaunch</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC"># exit status 1</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC">not ok 1 test-autolaunch</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC">FAIL: run-test.sh 1 test-autolaunch</font></span>
</pre>
Just i case ..
I'm starting test suite by:
<pre><span style="background-color:#1C1C1C"><font color="#BCBCBC">export DISPLAY=42</font></span>
<span style="background-color:#1C1C1C"><font color="#34E2E2">{</font></span><span style="background-color:#1C1C1C"><font color="#BCBCBC"> Xvfb :</font></span><span style="background-color:#1C1C1C"><font color="#8AE234">$</font></span><span style="background-color:#1C1C1C"><font color="#34E2E2">{</font></span><span style="background-color:#1C1C1C"><font color="#BCBCBC">DISPLAY</font></span><span style="background-color:#1C1C1C"><font color="#34E2E2">}</font></span><span style="background-color:#1C1C1C"><font color="#BCBCBC"> -nolisten tcp -auth /dev/null >/dev/null 2>&1 &</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC"> trap "kill -15 </font></span><span style="background-color:#1C1C1C"><font color="#8AE234">$</font></span><span style="background-color:#1C1C1C"><font color="#BCBCBC">! || true" 0 HUP INT QUIT TRAP TERM; </font></span><span style="background-color:#1C1C1C"><font color="#34E2E2">}</font></span><span style="background-color:#1C1C1C"><font color="#BCBCBC">;</font></span>
<span style="background-color:#1C1C1C"><font color="#BCBCBC">DBUS_TEST_SLOW=1 </font></span><span style="background-color:#1C1C1C"><font color="#FCE94F">\</font></span>
<span style="background-color:#1C1C1C"><font color="#EF2929">make -j4</font></span><span style="background-color:#1C1C1C"><font color="#BCBCBC"> check</font></span>
</pre>https://gitlab.freedesktop.org/dbus/dbus/-/issues/272Request addition of new Perl implementation to website2019-07-03T21:35:19ZFelipe GasperRequest addition of new Perl implementation to websiteI’d like to request addition of:
https://metacpan.org/pod/Protocol::DBus
… to https://www.freedesktop.org/wiki/Software/DBusBindings/. It’s an original client implementation (not a binding) in Perl.
Thank you!I’d like to request addition of:
https://metacpan.org/pod/Protocol::DBus
… to https://www.freedesktop.org/wiki/Software/DBusBindings/. It’s an original client implementation (not a binding) in Perl.
Thank you!https://gitlab.freedesktop.org/dbus/dbus/-/issues/273unable to filter messages2019-09-07T21:18:45Zduhovasurunable to filter messagesThe following command worked for me in Fedora 28, but since upgrading to Fedora 30, it doesn't show applicable dbus messages:
dbus-monitor --session "type='method_call',interface='org.freedesktop.Notifications',member='Notify'"
```
dbus...The following command worked for me in Fedora 28, but since upgrading to Fedora 30, it doesn't show applicable dbus messages:
dbus-monitor --session "type='method_call',interface='org.freedesktop.Notifications',member='Notify'"
```
dbus-monitor: unable to enable new-style monitoring: org.freedesktop.DBus.Error.MatchRuleInvalid: "Invalid match rule". Falling back to eavesdropping.
signal time=1563470082.399756 sender=org.freedesktop.DBus -> destination=:1.166595 serial=4294967295 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
string ":1.166595"
```
However, running without the filter does catch the message I'm looking for (along with a zillion others):
dbus-monitor --session
```
[...]
method call time=1563468713.173238 sender=:1.164239 -> destination=:1.164091 serial=14 path=/org/freedesktop/Notifications; interface=org.freedesktop.Notifications; member=Notify
string "mate-screensaver-dialog"
uint32 0
string ""
string "12:51:53 P.M."
string "testtest"
array [
]
array [
]
int32 0
[...]
```
What's going wrong? The format of my filter matches the example in the man page...?https://gitlab.freedesktop.org/dbus/dbus/-/issues/274Add GetConnectionUnixProcessIDHandle method2023-11-22T17:34:57ZPhilip WithnallAdd GetConnectionUnixProcessIDHandle methodSince the [kernel has gained more support for pidfds](https://lwn.net/Articles/794707/), Will Thompson suggested that it would be useful if D-Bus gained support for a `GetConnectionUnixProcessIDHandle` method to return one. This would be...Since the [kernel has gained more support for pidfds](https://lwn.net/Articles/794707/), Will Thompson suggested that it would be useful if D-Bus gained support for a `GetConnectionUnixProcessIDHandle` method to return one. This would be analogous to [`GetConnectionUnixProcessID`](https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-get-connection-unix-process-id), but would return a pidfd (type `h`) rather than a PID.
This would only work on Unix, and only on kernels which support pidfds. It would return an error if pidfds aren’t supported by the kernel, and callers would presumably have to fall back to calling `GetConnectionCredentials` or whatever they used to do.
On success, the returned pidfd would remain open until the caller explicitly closed it, and could be used to track the remote peer without the usual race conditions relating to PID reuse.
The use of pidfds might potentially provide a way to reliably(ish) identify peer processes without needing an LSM, which is a typical roadblock to implementing that feature on many Linux systems (since many Linux systems don’t have LSMs). While it won’t make any of the information you can look up about a process more reliable, it will mean that a peer can at least be sure it’s looking up the right process.https://gitlab.freedesktop.org/dbus/dbus/-/issues/275Typo in the Documentation?2020-02-20T13:15:58ZMubinTypo in the Documentation?Hi,
I am reading decumentation about dbus and I think there is a typo.
In the documentation (https://dbus.freedesktop.org/doc/dbus-daemon.1.html) in the section CONFIGURATION FILE, it reads:
*If the well-known type of the message...Hi,
I am reading decumentation about dbus and I think there is a typo.
In the documentation (https://dbus.freedesktop.org/doc/dbus-daemon.1.html) in the section CONFIGURATION FILE, it reads:
*If the well-known type of the message bus is "session", then the DBUS_STARTER_BUS_TYPE environment variable will be set to "session" and the DBUS_SESSION_BUS_ADDRESS environment variable will be set to the address of the session bus. Likewise, if the type of the message bus is "system", then the DBUS_STARTER_BUS_TYPE environment variable will be set to "system" and the DBUS_SESSION_BUS_ADDRESS environment variable will be set to the address of the system bus (which is normally well known anyway).*
Shouldn't the last DBUS\_**SESSION**\_BUS_ADDRESS be DBUS\_**SYSTEM**\_BUS_ADDRESS ?https://gitlab.freedesktop.org/dbus/dbus/-/issues/276Dbus crash at shutdown2019-08-19T08:09:35Zdev-uhuruDbus crash at shutdownHello, this is my first time reporting here, so I hope that I will not cross any lines!
So it seems, in short, that dbus (version 1.12.12-1ubuntu1.1) keeps on crashing at shutdown. I have not check if this is really at every single one...Hello, this is my first time reporting here, so I hope that I will not cross any lines!
So it seems, in short, that dbus (version 1.12.12-1ubuntu1.1) keeps on crashing at shutdown. I have not check if this is really at every single one (perhaps something to verify) but it certainly does seem that way since I'm greeted at every log in by a crash report (though it sometimes does not report). I have reported this at the following bug report: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1807709 although this is initially for crash at startup. Please see latest crash report attached
Thanks in advance.[crash-report-1](/uploads/f3c404f9c4b2a707ca890749b0dd6b27/crash-report-1)https://gitlab.freedesktop.org/dbus/dbus/-/issues/277.service is not found in XDG_DATA_DIRS location2019-08-22T14:16:13ZNicolas Fella.service is not found in XDG_DATA_DIRS locationI want to install a program that provides a .service file in a non-standard prefix and use the XDG_DATA_DIRS variable to add the path to the DBus service file search path.
The file is located in /home/nico/kde/usr/share/dbus-1/services/...I want to install a program that provides a .service file in a non-standard prefix and use the XDG_DATA_DIRS variable to add the path to the DBus service file search path.
The file is located in /home/nico/kde/usr/share/dbus-1/services/org.kde.kdeconnect.service and contains:
[D-BUS Service]
Name=org.kde.kdeconnect
Exec=/home/nico/kde/usr/lib64/libexec/kdeconnectd
XDG_DATA_DIRS is set to /home/nico/kde/usr/share:/home/nico/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share:/var/lib/snapd/desktop
When trying to activate the service I get an error "The name org.kde.kdeconnect was not provided by any .service files"
The service works fine when I install it to /usr/share/dbus-1/services
DBus Version is 1.12.16 on Manjarohttps://gitlab.freedesktop.org/dbus/dbus/-/issues/278Loops over all possible file descriptors (Use closefrom(2))2023-01-13T12:30:05ZrimLoops over all possible file descriptors (Use closefrom(2))Use closefrom() to avoid call close() for all possible descriptors.
[patch-dbus_dbus-sysdeps-unix.c](/uploads/e8aec21b68e4563ebb0a7715191806cd/patch-dbus_dbus-sysdeps-unix.c)
[FreeBSD BUG 240549](https://bugs.freebsd.org/bugzilla/show_b...Use closefrom() to avoid call close() for all possible descriptors.
[patch-dbus_dbus-sysdeps-unix.c](/uploads/e8aec21b68e4563ebb0a7715191806cd/patch-dbus_dbus-sysdeps-unix.c)
[FreeBSD BUG 240549](https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240549)
PS: probably better is build system should detect closefrom() and define HAVE_CLOSEFROM.https://gitlab.freedesktop.org/dbus/dbus/-/issues/279Some OOM checks are failing on Windows2021-12-06T13:02:32ZRalf HabackerSome OOM checks are failing on WindowsAfter enabling OOM memory checks on Windows (see https://gitlab.freedesktop.org/dbus/dbus/blob/master/dbus/dbus-memory.c#L257) I get some failing tests:
```
...
9% tests passed, 3 tests failed out of 28
Total Test time (real) = 182.80 ...After enabling OOM memory checks on Windows (see https://gitlab.freedesktop.org/dbus/dbus/blob/master/dbus/dbus-memory.c#L257) I get some failing tests:
```
...
9% tests passed, 3 tests failed out of 28
Total Test time (real) = 182.80 sec
The following tests FAILED:
3 - test-spawn-oom (Failed)
8 - test-bus (Failed)
10 - test-bus-dispatch-sha1 (Failed)
Errors while running CTest
make: *** [Makefile:141: test] Fehler 8
```
```
3: not ok 11 - spawn_nonexistant oom leaked 3 blocks
...
3: not ok 13 - spawn_segfault oom leaked 6 blocks
...
3: not ok 15 - spawn_exit oom leaked 9 blocks
...
: not ok 17 - spawn_and_kill oom leaked 12 blocks
...
3: # 4/17 tests failed
1/1 Test #3: test-spawn-oom ...................***Failed 0.94 sec
```
```
...
8: not ok 9 - activation-service-reload leaked 18 blocks
...
8: not ok 12 - unix-fds-passing leaked 18 blocks
...
8: # 2/12 tests failed
1/1 Test #8: test-bus .........................***Failed 2.56 sec
```
```
'10: dbus-daemon[383]: error: assertion failed "(real)->valid" file "/home/xxx/src/dbus/dbus/dbus-string.c" line 1104 function _dbus_string_append_printf_valist
10: Backtrace:
10: 0 __kernel_vsyscall+0x7 in [vdso].so
10: 1 __read+0x5b in libpthread.so.0
10: 2 0x7bc7f3a7 in ntdll
10: 3 0x7bc80b13 in ntdll
10: 4 0x7bc87d45 in ntdll
10: 5 NtWaitForMultipleObjects+0x2a in ntdll
10: 6 InterlockedDecrement+0x35c in kernel32
10: 7 WaitForMultipleObjectsEx+0x33 in kernel32
10: 8 WaitForSingleObject+0x2c in kernel32
10: 9 dump_backtrace+0xa6 [/home/xxx/src/dbus/dbus/dbus-sysdeps-win.c:2686] in libdbus-1-3
10: 10 _dbus_print_backtrace+0xb [/home/xxx/src/dbus/dbus/dbus-sysdeps-win.c:2697] in libdbus-1-3
10: 11 _dbus_abort+0xc [/home/xxx/src/dbus/dbus/dbus-sysdeps.c:93] in libdbus-1-3
10: 12 _dbus_warn+0x6e [/home/xxx/src/dbus/dbus/dbus-internals.c:252] in libdbus-1-3
10: 13 _dbus_real_assert+0x34 [/home/xxx/src/dbus/dbus/dbus-internals.c:968] in libdbus-1-3
10: 14 _dbus_string_append_printf_valist+0x7f [/home/xxx/src/dbus/dbus/dbus-string.c:1104] in libdbus-1-3
10: 15 _dbus_string_append_printf+0x25 [/home/xxx/src/dbus/dbus/dbus-string.c:1146] in libdbus-1-3
10: 16 _dbus_poll+0x59 [/home/xxx/src/dbus/dbus/dbus-sysdeps-win.c:1326] in libdbus-1-3
10: 17 socket_set_poll_poll+0x96 [/home/xxx/src/dbus/dbus/dbus-pollable-set-poll.c:284] in test-bus-dispatch-sha1
10: 18 _dbus_pollable_set_poll+0x2b [/home/xxx/src/dbus/./dbus/dbus-pollable-set.h:112] in test-bus-dispatch-sha1
10: 19 _dbus_loop_iterate+0x1ee [/home/xxx/src/dbus/dbus/dbus-mainloop.c:663] in test-bus-dispatch-sha1
10: 20 bus_test_run_everything+0x44 [/home/xxx/src/dbus/bus/test.c:262] in test-bus-dispatch-sha1
10: 21 kill_client_connection+0xb9 [/home/xxx/src/dbus/bus/dispatch.c:834] in test-bus-dispatch-sha1
10: 22 check_hello_connection+0x122 [/home/xxx/src/dbus/bus/dispatch.c:1865] in test-bus-dispatch-sha1
10: 23 check_oom_check2_func+0x41 [/home/xxx/src/dbus/bus/dispatch.c:4732] in test-bus-dispatch-sha1
10: 24 run_failing_each_malloc+0x50 [/home/xxx/src/dbus/dbus/dbus-internals.c:1010] in libdbus-1-3
10: 25 _dbus_test_oom_handling+0x17d [/home/xxx/src/dbus/dbus/dbus-internals.c:1099] in libdbus-1-3
10: 26 check2_try_iterations+0x34 [/home/xxx/src/dbus/bus/dispatch.c:4759] in test-bus-dispatch-sha1
10: 27 bus_dispatch_sha1_test+0x15e [/home/xxx/src/dbus/bus/dispatch.c:5110] in test-bus-dispatch-sha1
10: 28 _dbus_test_main+0x217 [/home/xxx/src/dbus/test/test-utils.c:762] in test-bus-dispatch-sha1
10: 29 main+0x48 [/home/xxx/src/dbus/test/bus/dispatch-sha1.c:62] in test-bus-dispatch-sha1
10: 30 0x401386 in test-bus-dispatch-sha1
10: 31 call_process_entry+0xc in kernel32
10: 32 0x7b46637e in kernel32
10: 33 call_process_entry+0x1a in kernel32
1/1 Test #10: test-bus-dispatch-sha1 ...........***Failed 62.00 sec
```
I get the last error after applying the patch from https://gitlab.freedesktop.org/dbus/dbus/merge_requests/125
see also #149https://gitlab.freedesktop.org/dbus/dbus/-/issues/280Request to add new Java binding jnidbus to bindings list2019-10-02T14:56:13ZAdrien DestuguesRequest to add new Java binding jnidbus to bindings listHi,
Please add jnidbus(https://github.com/viveris/jnidbus) to the list of bindings for the Java language at https://www.freedesktop.org/wiki/Software/DBusBindings/ .
This is a binding of libdbus (unlike dbus-java), the main advantages a...Hi,
Please add jnidbus(https://github.com/viveris/jnidbus) to the list of bindings for the Java language at https://www.freedesktop.org/wiki/Software/DBusBindings/ .
This is a binding of libdbus (unlike dbus-java), the main advantages are explained in the README: different approach for threading and much easier mapping of Java objects to DBus thanks to modern Java features (annotations allowing to describe how to serialize and deserialize objects).
This implementation also provide bindings for Kotlin, where it is usable in coroutines.
I would do it myself but getting an account on the wiki seems quite complex, so I hope it's possible to proxy this through the bugtracker.https://gitlab.freedesktop.org/dbus/dbus/-/issues/281file monitoring might not notice symlinks appearing2019-10-03T18:44:59ZSimon McVittiefile monitoring might not notice symlinks appearinghttps://github.com/flatpak/flatpak/issues/3145https://github.com/flatpak/flatpak/issues/3145https://gitlab.freedesktop.org/dbus/dbus/-/issues/282Define system_bus_socket in /run/dbus instead of /var/run/dbus2021-12-07T13:18:18ZH2O2Define system_bus_socket in /run/dbus instead of /var/run/dbusI am running into this warning while starting up OpenEmbedded with qemu:
```
/lib/systemd/system/dbus.socket:5: ListenStream= references a path below legacy directory /var/run/, updating /var/run/dbus/system_bus_socket → /run/dbus/syste...I am running into this warning while starting up OpenEmbedded with qemu:
```
/lib/systemd/system/dbus.socket:5: ListenStream= references a path below legacy directory /var/run/, updating /var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket; please upd...
```
changing the line `DBUS_SYSTEM_SOCKET=${EXPANDED_RUNSTATEDIR}/run/dbus/system_bus_socket` to `DBUS_SYSTEM_SOCKET=/run/dbus/system_bus_socket` in `configure.ac` solves this warning ([0001-Fix-reference-to-legacy-directory-var-run.patch](/uploads/bde9da2d820bc6ecaad903fc689469af/0001-Fix-reference-to-legacy-directory-var-run.patch)). I noticed the [bug report](https://bugs.freedesktop.org/show_bug.cgi?id=101628) mentioned in the comment above this line had discussed a similar issue. Since it's been 2 years, I am wondering if there is any plan to make this change now. Thanks!https://gitlab.freedesktop.org/dbus/dbus/-/issues/2831.12.16: test failure: file descriptor 4 leaked in dbus-message-util.c2024-01-24T16:17:13ZTomasz Kłoczko1.12.16: test failure: file descriptor 4 leaked in dbus-message-util.cFrom test/test-suite.log:
<details>
<pre><span style="background-color:#2E3436"><font color="#D3D7CF">======================================</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF"> dbus 1.12.16: te...From test/test-suite.log:
<details>
<pre><span style="background-color:#2E3436"><font color="#D3D7CF">======================================</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF"> dbus 1.12.16: test/test-suite.log</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF">=======================================</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF"># TOTAL: 157</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF"># PASS: 150</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF"># SKIP: 6</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF"># XFAIL: 0</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF"># FAIL: 1</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF"># XPASS: 0</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF"># ERROR: 0</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF">.. contents:: :depth: 2</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF">FAIL: test-bus</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF">==============</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF">dbus[3478896]: file descriptor 4 leaked in dbus-message-util.c.</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF"> D-Bus not built with -rdynamic so unable to print a backtrace</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF">./test-bus.sh: line 20: 3478896 Aborted (core dumped) ../bus/test-bus 1>&2</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF">1..1</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF">not ok 1 ../bus/test-bus (exit status 134)</font></span>
<span style="background-color:#2E3436"><font color="#D3D7CF">FAIL: test-bus.sh 1 ../bus/test-bus (exit status 134)</font></span>
</pre>
<pre>[tkloczko@barrel SPECS]$ coredumpctl gdb /home/tkloczko/rpmbuild/BUILD/dbus-dbus-1.12.16/bus/.libs/lt-test-bus
PID: <b>3478896</b> (lt-test-bus)
UID: 1000 (tkloczko)
GID: 1000 (tkloczko)
Signal: 6 (ABRT)
Timestamp: Sat 2019-11-02 20:27:58 GMT (31s ago)
Command Line: /home/tkloczko/rpmbuild/BUILD/dbus-dbus-1.12.16/bus/.libs/lt-test-bus
Executable: <b>/home/tkloczko/rpmbuild/BUILD/dbus-dbus-1.12.16/bus/.libs/lt-test-bus</b>
Control Group: /user.slice/user-1000.slice/session-30.scope
Unit: session-30.scope
Slice: user-1000.slice
Session: 30
Owner UID: 1000 (tkloczko)
Boot ID: e3193598c75f49348c021547f744cc39
Machine ID: 2a07404e0c70431ba36bfb0ac8e023c2
Hostname: barrel
Storage: /var/lib/systemd/coredump/core.lt-test-bus.1000.e3193598c75f49348c021547f744cc39.3478896.1572726478000000000000.lz4
Message: Process 3478896 (lt-test-bus) of user 1000 dumped core.
Stack trace of thread 3478896:
#0 0x00007f92313c85f5 raise (libc.so.6)
#1 0x00007f92313b18d9 abort (libc.so.6)
#2 0x00007f9231342ee5 n/a (/home/tkloczko/rpmbuild/BUILD/dbus-dbus-1.12.16/dbus/.libs/libdbus-1.so.3.19.11)
\<font color="#75507B"><b>GNU gdb (GDB) Fedora 9.0.50.20191018-1.fc32</b></font>
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from <font color="#4E9A06">/home/tkloczko/rpmbuild/BUILD/dbus-dbus-1.12.16/bus/.libs/lt-test-bus</font>...
[New LWP 3478896]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "<font color="#4E9A06">/lib64/libthread_db.so.1</font>".
Core was generated by `/home/tkloczko/rpmbuild/BUILD/dbus-dbus-1.12.16/bus/.libs/lt-test-bus'.
Program terminated with signal SIGABRT, Aborted.
#0 <font color="#3465A4">0x00007f92313c85f5</font> in <font color="#C4A000">raise</font> () from <font color="#4E9A06">/lib64/libc.so.6</font>
audit-libs-3.0-0.14.20190507gitf58ec40.fc32.x86_64 expat-2.2.9-2.fc32.x86_64 glibc-2.30.9000-16.fc32.x86_64 libcap-ng-0.7.10-2.fc32.x86_64 libgcc-9.2.1-1.fc32.3.x86_64 libgcrypt-1.8.5-2.fc32.x86_64 libgpg-error-1.36-3.fc32.x86_64 libselinux-2.9-7.fc32.x86_64 lz4-libs-1.9.2-2.1.fc32.x86_64 pcre2-10.33-14.fc32.x86_64 sssd-client-2.2.2-3.fc32.x86_64 xz-libs-5.2.4-8.fc32.x86_64
(gdb) bt full
Missing separate debuginfos, use: dnf debuginfo-install#0 <font color="#3465A4">0x00007f92313c85f5</font> in <font color="#C4A000">raise</font> () from <font color="#4E9A06">/lib64/libc.so.6</font>
No symbol table info available.
#1 <font color="#3465A4">0x00007f92313b18d9</font> in <font color="#C4A000">abort</font> () from <font color="#4E9A06">/lib64/libc.so.6</font>
No symbol table info available.
#2 <font color="#3465A4">0x00007f9231342ee5</font> in <font color="#C4A000">_dbus_abort</font> () at <font color="#4E9A06">dbus-sysdeps.c</font>:93
<font color="#06989A">s</font> = <optimized out>
#3 <font color="#3465A4">0x00007f92313458f0</font> in <font color="#C4A000">_dbus_warn</font> (<font color="#06989A">format</font>=0x56087cf2a2b0 "file descriptor %i leaked in %s.") at <font color="#4E9A06">dbus-internals.c</font>:249
<font color="#06989A">severity</font> = <optimized out>
<font color="#06989A">args</font> = {{gp_offset = 8, fp_offset = 48, overflow_arg_area = <font color="#3465A4">0x7ffda04030b0</font>, reg_save_area = <font color="#3465A4">0x7ffda0402ff0</font>}}
#4 <font color="#3465A4">0x000056087cf099e4</font> in <font color="#C4A000">_dbus_check_fdleaks_leave</font> (<font color="#06989A">fds</font>=0x56087ef22be0) at <font color="#4E9A06">dbus-message-util.c</font>:263
<font color="#06989A">l</font> = 4
<font color="#06989A">e</font> = <font color="#3465A4">0x56087ef26f74</font> ""
<font color="#06989A">fd</font> = <optimized out>
<font color="#06989A">de</font> = <optimized out>
<font color="#06989A">d</font> = <font color="#3465A4">0x56087ef26ea0</font>
<font color="#06989A">d</font> = <optimized out>
<font color="#06989A">de</font> = <optimized out>
<font color="#06989A">l</font> = <optimized out>
<font color="#06989A">e</font> = <optimized out>
<font color="#06989A">fd</font> = <optimized out>
<font color="#06989A">__d</font> = <optimized out>
#5 <font color="#C4A000">test_post_hook</font> () at <font color="#4E9A06">test-main.c</font>:88
No locals.
#6 <font color="#3465A4">0x000056087cf05b9e</font> in <font color="#C4A000">main</font> (<font color="#06989A">argc</font>=<optimized out>, <font color="#06989A">argv</font>=0x7ffda0403408) at <font color="#4E9A06">test-main.c</font>:142
<font color="#06989A">dir</font> = <optimized out>
<font color="#06989A">only</font> = <optimized out>
<font color="#06989A">test_data_dir</font> = {dummy1 = <font color="#3465A4">0x7ffda0404ed0</font>, dummy2 = 57, dummy3 = 65, dummy_bit1 = 1, dummy_bit2 = 1, dummy_bit3 = 0, dummy_bits = 0}
(gdb)
</pre>
</details>https://gitlab.freedesktop.org/dbus/dbus/-/issues/289/var/lib/dbus/machine-id and privacy2020-01-20T19:57:49Zdbuser/var/lib/dbus/machine-id and privacyIn December 2019 I saw [an article](https://linux.slashdot.org/story/19/11/30/0538211/the-file-varlibdbusmachine-id-matters-for-your-privacy-and-devuan-fixed-it) mentioning that Devuan has made so that a new /var/lib/dbus/machine-id is g...In December 2019 I saw [an article](https://linux.slashdot.org/story/19/11/30/0538211/the-file-varlibdbusmachine-id-matters-for-your-privacy-and-devuan-fixed-it) mentioning that Devuan has made so that a new /var/lib/dbus/machine-id is generated for each boot for improving privacy, considering that the file can be read by anyone and there is no restriction to that:
https://devuan.org/os/debian-fork/ascii-point-release-announce-112119
I started a discussion about the issue on [openSUSE's bugzilla](https://bugzilla.suse.com/show_bug.cgi?id=1159309) (the distro I use) where I shared my thoughts of the potential implications of machine-id being accessible by everyone (as it is now) and a suggestion that additionally to what Devuan has done machine-id should also be with limited access, allowing only "whitelisted" programs.
The advise of the dbus experts on openSUSE's bugzilla is that this discussion rather belongs upstream (here) where the possible changes should be made, so I am opening it for consideration.https://gitlab.freedesktop.org/dbus/dbus/-/issues/290Check EGID of the client when deciding whether to send a message2020-01-24T15:56:50ZIgor ZhbanovCheck EGID of the client when deciding whether to send a messageCurrently D-Bus daemon checks only primary GID and supplementary groups of a client process when deciding whether to allow to send some message.
So if some privileged process made setegid() (and not setgid()) to launch some privileged c...Currently D-Bus daemon checks only primary GID and supplementary groups of a client process when deciding whether to allow to send some message.
So if some privileged process made setegid() (and not setgid()) to launch some privileged child. Then this child would be unable to use restricted D-Bus API because it would still have unprivileged real GID. But since all GIDS (real, effective and supplementary) should be treated equally I suggest to check EGID too.
There was a previous discussion of the topic here:
https://bugs.freedesktop.org/show_bug.cgi?format=multiple&id=97821
Which resulted in adding of the support of supplementary groups handling:
https://bugs.freedesktop.org/show_bug.cgi?id=103737
But the EGID is still ignored.https://gitlab.freedesktop.org/dbus/dbus/-/issues/291dbus-daemon crashes at shutdown when there are monitoring connections to clear2020-04-21T12:23:28ZMark Bannisterdbus-daemon crashes at shutdown when there are monitoring connections to clearWe're getting a core dump from dbus-daemon on shutdown whenever there are monitoring connections to clear:
```
Core was generated by `/usr/bin/dbus-daemon --fork --print-pid 6 --print-address 8 --session'.
Program terminated with signal...We're getting a core dump from dbus-daemon on shutdown whenever there are monitoring connections to clear:
```
Core was generated by `/usr/bin/dbus-daemon --fork --print-pid 6 --print-address 8 --session'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007fbaf3f009c7 in _dbus_list_unlink (list=0x55ee351e7800, link=link@entry=0x55ee351f62a0) at ../../dbus/dbus-list.c:510
510 link->next->prev = link->prev;
(gdb) bt
#0 0x00007fbaf3f009c7 in _dbus_list_unlink (list=0x55ee351e7800, link=link@entry=0x55ee351f62a0) at ../../dbus/dbus-list.c:510
#1 0x00007fbaf3f00a29 in _dbus_list_remove_link (list=<optimized out>, link=0x55ee351f62a0) at ../../dbus/dbus-list.c:530
#2 0x000055ee34f1eb35 in bus_connection_disconnected (connection=connection@entry=0x55ee351f31f0) at ../../bus/connection.c:305
#3 0x000055ee34f1ec8c in bus_connections_unref (connections=0x55ee351e77b0) at ../../bus/connection.c:555
#4 0x000055ee34f17303 in bus_context_unref (context=0x55ee351e73f0) at ../../bus/bus.c:1131
#5 0x000055ee34f13be4 in main (argc=<optimized out>, argv=<optimized out>) at ../../bus/main.c:687
(gdb) p link
$1 = (DBusList *) 0x55ee351f62a0
(gdb) p *link
$2 = {prev = 0x55ee351eb210, next = 0x0, data = 0x55ee3528c1e0}
(gdb) p *list
$16 = (DBusList *) 0x0
(gdb) fr 2
#2 0x000055ee34f1eb35 in bus_connection_disconnected (connection=connection@entry=0x55ee351f31f0) at ../../bus/connection.c:305
305 _dbus_list_remove_link (&d->connections->monitors, d->link_in_monitors);
(gdb) p *d->connections
$17 = {refcount = 0, completed = 0x55ee351f6198, n_completed = 35, incomplete = 0x0, n_incomplete = 0, context = 0x55ee351e73f0, completed_by_user = 0x55ee351eec80, expire_timeout = 0x55ee351f92d0, stamp = 5243451,
pending_replies = 0x55ee351f90b0, monitors = 0x0, monitor_matchmaker = 0x55ee351fd210, total_match_rules = 298, peak_match_rules = 625, peak_match_rules_per_conn = 172, total_bus_names = 79, peak_bus_names = 137,
peak_bus_names_per_conn = 16}
(gdb) p *d
$18 = {connections = 0x55ee351e77b0, link_in_connection_list = 0x55ee351f6198, connection = 0x55ee351f31f0, services_owned = 0x0, n_services_owned = 0, match_rules = 0x0, n_match_rules = 0, name = 0x55ee351f3e10 ":1.23",
transaction_messages = 0x0, oom_message = 0x55ee351f2020, oom_preallocated = 0x55ee351eaea0, policy = 0x55ee351f3b00, cached_loginfo_string = 0x55ee351f07c0 "uid=20709 pid=12507 comm=\"/usr/bin/dbus-monitor --session \"",
selinux_id = 0x0, apparmor_confinement = 0x0, connection_tv_sec = 196347, connection_tv_usec = 546267, stamp = 5243445, peak_match_rules = 1, peak_bus_names = 1, n_pending_unix_fds = 0, pending_unix_fds_timeout = 0x0,
link_in_monitors = 0x55ee351f62a0}
(gdb) p *d->link_in_monitors
$19 = {prev = 0x55ee351eb210, next = 0x0, data = 0x55ee3528c1e0}
```
We're actually using dbus-1.10.24-13.el7_6.x86_64, but I checked here in the master branch and found that the bug still exists. All line numbers below are from the master branch.
This is happening because `bus_connections_unref()` drops all monitors first by calling `_dbus_list_clear()` (line 547 below) before then calling `bus_connection_disconnected()` (line 558) which attempts to remove links from monitors:
```c
bus/connection.c
546: /* drop all monitors */
547- _dbus_list_clear (&connections->monitors);
548-
549- /* drop all real connections */
550- while (connections->completed != NULL)
551- {
552- DBusConnection *connection;
553-
554- connection = connections->completed->data;
555-
556- dbus_connection_ref (connection);
557- dbus_connection_close (connection);
558- bus_connection_disconnected (connection);
559- dbus_connection_unref (connection);
560- }
```
When `bus_connection_disconnected()` is called, `d->connections->monitors` is NULL but `d->links_in_monitors` is still pointing to an item in the list:
```
(gdb) p d->connections->monitors
$22 = (DBusList *) 0x0
(gdb) p d->link_in_monitors
$23 = (DBusList *) 0x55ee351f62a0
```
As a result of `d->link_in_monitors` containing a pointer, `bus_connection_disconnected()` calls `_dbus_list_remove_link()`:
```
301 if (d->link_in_monitors != NULL)
302 {
...
308 _dbus_list_remove_link (&d->connections->monitors, d->link_in_monitors);
```
This invokes `_dbus_list_unlink()` which presumes that `next` can never be NULL:
```c
dbus/dbus-list.c
500:_dbus_list_unlink (DBusList **list,
501- DBusList *link)
502-{
503- if (link->next == link)
504- {
505- /* one-element list */
506- *list = NULL;
507- }
508- else
509- {
510- link->prev->next = link->next;
511- link->next->prev = link->prev;
512-
513- if (*list == link)
514- *list = link->next;
515- }
```
Unfortunately, `_dbus_list_clear()` leaves the linked list in a state where the `next` pointer *can* be NULL:
```c
dbus/dbus-list.c
543:_dbus_list_clear (DBusList **list)
544-{
545- DBusList *link;
546-
547- link = *list;
548- while (link != NULL)
549- {
550- DBusList *next = _dbus_list_get_next_link (list, link);
551-
552- free_link (link);
553-
554- link = next;
555- }
556-
557- *list = NULL;
558-}
```
... because of the use of the `_dbus_list_get_next_link()` macro, defined as:
```c
dbus/dbus-list.h
119:#define _dbus_list_get_next_link(list, link) ((link)->next == *(list) ? NULL : (link)->next)
```
And so we get an attempt to de-reference a NULL pointer:
```
(gdb) fr 0
#0 0x00007fbaf3f009c7 in _dbus_list_unlink (list=0x55ee351e7800, link=link@entry=0x55ee351f62a0) at ../../dbus/dbus-list.c:510
510 link->next->prev = link->prev;
(gdb) p link->next
$20 = (DBusList *) 0x0
(gdb) disassem
Dump of assembler code for function _dbus_list_unlink:
<snip>
=> 0x00007fbaf3f009c7 <+23>: mov %rdx,(%rax)
(gdb) info reg
rax 0x0 0
<snip>
```
... resulting in a core dump.
I suggest `_dbus_list_clear()` should be fixed so that it can't leave the `next` pointer in a NULL state? It's used all over the place, I'm wondering what other issues this code could be seeding. That and/or `bus_connection_disconnected()` shouldn't leave `d->link_in_monitors` dangling when it drops all monitors.https://gitlab.freedesktop.org/dbus/dbus/-/issues/292debug system bus2020-02-14T09:38:03Zericwasd617140123@gmail.comdebug system busHi,
I am new to use dbus, I want to use dbus test in my PC. I use C language.
I want to set up another dbus system bus, how can I set in command line.
because I use "dbus-daemon --system --fork --print-pid --print-address"
And I type "...Hi,
I am new to use dbus, I want to use dbus test in my PC. I use C language.
I want to set up another dbus system bus, how can I set in command line.
because I use "dbus-daemon --system --fork --print-pid --print-address"
And I type "ps aux". I can not see my process id.
by the way my config file all in my host not in the root path
below is my path setting.
original_prefix=/home/eric/Desktop/library_test/dbus_test/dbus_app0210
prefix=${original_prefix}
exec_prefix=/home/eric/Desktop/library_test/dbus_test/dbus_exec
bindir=${exec_prefix}/bin
libdir=${exec_prefix}/lib
includedir=${prefix}/include
system_bus_default_address=unix:path=/home/eric/Desktop/library_test/dbus_test/dbus_app0210/var/run/dbus/system_bus_socket
datarootdir=${prefix}/share
datadir=/home/eric/Desktop/library_test/dbus_test/dbus_data
sysconfdir=${prefix}/etc
session_bus_services_dir=${datadir}/dbus-1/services
system_bus_services_dir=${datadir}/dbus-1/system-services
daemondir=${bindir}https://gitlab.freedesktop.org/dbus/dbus/-/issues/293Can get a response from service when D-Bus timeout value is set to 02021-12-07T01:11:32ZmulkieranCan get a response from service when D-Bus timeout value is set to 0Ideally, setting the timeout value to 0 would ensure that the service could not respond in time and that org.freedesktop.DBus.Method.NoReply error would be returned. But we have had intermittent successes w/ communicating w/ the service ...Ideally, setting the timeout value to 0 would ensure that the service could not respond in time and that org.freedesktop.DBus.Method.NoReply error would be returned. But we have had intermittent successes w/ communicating w/ the service in 0 time.
This is a problem, because we would like to test the behavior of our client when there is no reply, and we had assumed that a timeout of 0 would do the trick. Obviously, we could expend some ingenuity to ensure that our client took too long for the 0 timeout. But in the best case, for other clients that would like to test their behavior on NoReply, the best thing would be for libdbus to consistently return NoReply on a timeout of 0.
The PR which elicited this response is here: https://github.com/stratis-storage/stratis-cli/pull/476.
The test failure is only intermittent, and we don't have much more detail.
Our client makes use of dbus-python, but we can be quite certain that the value of the timeout in dbus-python is 0.0, so we don't believe that the problem is there.
I think it should be possible to, even if the timeout handling is necessarily not precise, include some short-circuiting behavior that ensures correctly returning NoReply on 0 timeout. I have not had any success in figuring out exactly where that should occur, however. Would you be interested in a PR to address this problem?https://gitlab.freedesktop.org/dbus/dbus/-/issues/294CVE-2020-12049: File descriptor leak in _dbus_read_socket_with_unix_fds2020-07-01T15:23:21ZKevin BackhouseCVE-2020-12049: File descriptor leak in _dbus_read_socket_with_unix_fds# GitHub Security Lab (GHSL) Vulnerability Report: `GHSL-2020-057`
The [GitHub Security Lab](https://securitylab.github.com) team has identified a potential security vulnerability in [dbus](https://gitlab.freedesktop.org/dbus/dbus).
We...# GitHub Security Lab (GHSL) Vulnerability Report: `GHSL-2020-057`
The [GitHub Security Lab](https://securitylab.github.com) team has identified a potential security vulnerability in [dbus](https://gitlab.freedesktop.org/dbus/dbus).
We are committed to working with you to help resolve these issues. In this report you will find everything you need to effectively coordinate a resolution of these issues with the GHSL team.
If at any point you have concerns or questions about this process, please do not hesitate to reach out to us at `securitylab@github.com` (please include your `GHSL-2020-057` as a reference).
If you are _NOT_ the correct point of contact for this report, please let us know!
## Summary
D-Bus has a file descriptor leak, which can lead to denial of service when the dbus-daemon runs out of file descriptors. An unprivileged local attacker can use this to attack the system dbus-daemon, leading to denial of service for all users of the machine.
## Product
D-Bus (dbus-daemon)
## Tested Version
1.12.2-1ubuntu1.1 (tested on Ubuntu 18.04.4 LTS)
## Details
### Issue 1: File descriptor leak in `_dbus_read_socket_with_unix_fds`
The function `_dbus_read_socket_with_unix_fds` contains the following code at
[dbus-sysdeps-unix.c, line 438](https://gitlab.freedesktop.org/dbus/dbus/-/blob/1530582863b801839bc57c9ec8bc9ca3d16f2a65/dbus/dbus-sysdeps-unix.c#L438):
```
if (m.msg_flags & MSG_CTRUNC)
{
/* Hmm, apparently the control data was truncated. The bad
thing is that we might have completely lost a couple of fds
without chance to recover them. Hence let's treat this as a
serious error. */
errno = ENOSPC;
_dbus_string_set_length (buffer, start);
return -1;
}
```
The intention of this code is to handle the case where too many file descriptors are sent over the unix socket, causing the control data to get truncated. That could be a deliberate attempt by an attacker to cause a denial of service. The problem with the code is that some file descriptors may still have been received, even though the message has been truncated. So we need to make sure that those file descriptors are closed. Otherwise an attacker can cause us to quickly run out of file descriptors.
In my opinion, the simplest solution is to just delete this block of code entirely. The loop below (starting at line 450) handles the file descriptors correctly, so it is better to ignore the MSG_CTRUNC flag and process the message as normal. File descriptors will be correctly closed if the message is invalid. I have confirmed that my proof-of-concept exploit does not work if this block of code is deleted. An alternative solution is to postpone checking the MSG_CTRUNC flag until after the loop at line 450 has finished, so that the file descriptors can be closed correctly.
#### Impact
This issue can lead to a local denial of service attack: an unprivileged local attacker can make the system unusable for all users. For example, on Ubuntu 18.04.4 LTS, my proof-of-concept exploit prevents all users from logging in, because the login screen needs to send a D-Bus message, but the dbus-daemon is no longer able to send or receive any messages because it cannot create any new file descriptors.
#### Remediation
As I mentioned above, my recommendation is to delete the block of code at [dbus-sysdeps-unix.c, line 438 to 448](https://gitlab.freedesktop.org/dbus/dbus/-/blob/1530582863b801839bc57c9ec8bc9ca3d16f2a65/dbus/dbus-sysdeps-unix.c#L438).
#### Resources
I have attached the source code of my proof-of-concept exploit: [`fd_dos.cpp`](/uploads/63d30c8bbdd8d13fb6e8b6d63c13f478/fd_dos.cpp).
Compile it and run it like this:
```
gcc fd_dos.cpp -o fd_dos
./fd_dos /var/run/dbus/system_bus_socket
```
## Credit
This issue was discovered and reported by GHSL team member [@kevinbackhouse (Kevin Backhouse)](https://github.com/kevinbackhouse).
## Contact
You can contact the GHSL team at `securitylab@github.com`, please include the `GHSL-2020-057` in any communication regarding this issue.
## Disclosure Policy
This report is subject to our [coordinated disclosure policy](https://securitylab.github.com/disclosures#policy).https://gitlab.freedesktop.org/dbus/dbus/-/issues/295cmake: keep configure options naming in sync with autotools2020-04-27T20:54:55ZRalf Habackercmake: keep configure options naming in sync with autotoolsIn the cmake build system most configuration options are defined with a "DBUS_" prefix, e.g. DBUS_ENABLE_VERBOSE_MODE. The reason is probably that these variables are used in the dbus sources. To define these options when calling configu...In the cmake build system most configuration options are defined with a "DBUS_" prefix, e.g. DBUS_ENABLE_VERBOSE_MODE. The reason is probably that these variables are used in the dbus sources. To define these options when calling configure, option names beginning with '--enable_' are used, such as --enable-verbose-mode. This is used internally to create a variable called DBUS_ENABLE_VERBOSE_MODE, which is used in the source code and build system.
It would help to analyze errors in the cmake build system if these definitions were more identical.
See also #117https://gitlab.freedesktop.org/dbus/dbus/-/issues/296Provide support to run cross compiled tests on gitlab CI2020-05-29T14:56:16ZRalf HabackerProvide support to run cross compiled tests on gitlab CIOn gitlab CI there are pipelines designed for cross compiling dbus. Unfortunally they do not run the contained tests, which would help to see hidden issues.
Running cross compiled tests requires the usage of `wine`. A basically working ...On gitlab CI there are pipelines designed for cross compiling dbus. Unfortunally they do not run the contained tests, which would help to see hidden issues.
Running cross compiled tests requires the usage of `wine`. A basically working support could be shown at
https://build.opensuse.org/project/show/home:rhabacker:branches:windows:mingw:win32:wine.
I used some shell commands similar to what is listed below:
```
syspath=/usr/i686-w64-mingw32/sysroot/mingw/bin
buildpath=~/src/dbus-cmake-cross-x86-wine-build/bin
# setup wine prefix
wineboot -fi >/dev/null 2>&1
# start x server
export DISPLAY=:1
(Xvfb $DISPLAY >/dev/null 2>&1 &)
# wait until registry appears
while ! test -f ~/.wine/system.reg; do
sleep 1
done
# get bin dir of mingw installation
syspath=$(winepath -w $syspath)
# get bin dir of build root
buildpath=$(winepath -w $buildpath)
# convert back slashes to double backslash
addpath=$(echo "$syspath;$buildpath" | sed 's,\\,\\\\\\\\,g')
# add local pathes to wine system path
sed -i "/^\"PATH\"/ s,\"\$,;$addpath\",g" ~/.wine/system.reg
```
On gitlab travis CI the pathes for `syspath` and `buildpath` need to be adjusted.
Issues:
1. wineboot is not found, although it looks that wine was installed - see https://gitlab.freedesktop.org/rhabacker/dbus/-/jobs/2441267Ralf HabackerRalf Habackerhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/297CI error: Failed to start message bus: Failed to open "z:/builds/xxx/dbus/ci-...2021-11-23T14:04:23ZRalf HabackerCI error: Failed to start message bus: Failed to open "z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/share\dbus-1\session.conf": Path not found.With !185 on running test cases the following error is visible:
```
28: Test command: /usr/bin/wine "z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/bin/dbus-run-session.exe" "--config-file=z:/builds/xxx/dbus/ci-build-production...With !185 on running test cases the following error is visible:
```
28: Test command: /usr/bin/wine "z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/bin/dbus-run-session.exe" "--config-file=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/test/data/valid-config-files/tmp-session.conf" "--dbus-daemon=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/bin/dbus-daemon.exe" "z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/bin/test-ids.exe" "--tap"
28: Environment variables:
28: DBUS_SESSION_BUS_PID=
28: DBUS_SESSION_BUS_ADDRESS=
28: DBUS_FATAL_WARNINGS=1
28: DBUS_TEST_DAEMON=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/bin/dbus-daemon.exe
28: DBUS_TEST_DATA=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/test/data
28: DBUS_TEST_HOMEDIR=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/dbus
28: Test timeout computed to be: 180
28: dbus[45]: error: Failed to start message bus: Failed to open "z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/share\dbus-1\session.conf": Path not found.
28: Backtrace:
28: 0 0xf7f24067
28: 1 0x7bc8191e in ntdll
28: 2 0x7bc88b45 in ntdll
28: 3 0x7bc8b05f in ntdll
28: 4 0x7b47832a in kernel32
28: 5 0x7b4784b3 in kernel32
28: 6 0x7b47851d in kernel32
28: 7 dump_backtrace+0xa6 [../../dbus/dbus-sysdeps-win.c:2790] in libdbus-1-3
28: 8 _dbus_print_backtrace+0xb [../../dbus/dbus-sysdeps-win.c:2801] in libdbus-1-3
28: 9 _dbus_abort+0xc [../../dbus/dbus-sysdeps.c:93] in libdbus-1-3
28: 10 _dbus_warn+0x6e [../../dbus/dbus-internals.c:259] in libdbus-1-3
28: 11 main+0xa97 [../../bus/main.c:705] in dbus-daemon
28: 12 EntryPoint+0xffffffffffffffff in dbus-daemon
28: 13 0x7b463e32 in kernel32
28: 14 0x7b4661ac in kernel32
28: 15 0x7b463e3e in kernel32
28: ok 1 - connected to session bus
28: ok 2 - session bus server ID is cabccb0f4fd7772af17928e35eb578c0
28: ok 3 - session bus server ID length is 32
28: ok 4 - session bus ID is 8d96dbfeb2abc176b6ce3b595eb578c0
28: ok 5 - session bus ID length is 32
28: 1..5
28/29 Test #28: test-ids ......................... Passed 1.72 sec
```
```
test 29
Start 29: test-shutdown
29: Test command: /usr/bin/wine "z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/bin/dbus-run-session.exe" "--config-file=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/test/data/valid-config-files/tmp-session.conf" "--dbus-daemon=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/bin/dbus-daemon.exe" "z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/bin/test-shutdown.exe" "--tap"
29: Environment variables:
29: DBUS_SESSION_BUS_PID=
29: DBUS_SESSION_BUS_ADDRESS=
29: DBUS_FATAL_WARNINGS=1
29: DBUS_TEST_DAEMON=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/bin/dbus-daemon.exe
29: DBUS_TEST_DATA=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/test/data
29: DBUS_TEST_HOMEDIR=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/dbus
29: Test timeout computed to be: 180
29: dbus[45]: error: Failed to start message bus: Failed to open "z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/share\dbus-1\session.conf": Path not found.
29: Backtrace:
29: 0 0xf7eff067
29: 1 0x7bc8191e in ntdll
29: 2 0x7bc88b45 in ntdll
29: 3 0x7bc8b05f in ntdll
29: 4 0x7b47832a in kernel32
29: 5 0x7b4784b3 in kernel32
29: 6 0x7b47851d in kernel32
29: 7 dump_backtrace+0xa6 [../../dbus/dbus-sysdeps-win.c:2790] in libdbus-1-3
29: 8 _dbus_print_backtrace+0xb [../../dbus/dbus-sysdeps-win.c:2801] in libdbus-1-3
29: 9 _dbus_abort+0xc [../../dbus/dbus-sysdeps.c:93] in libdbus-1-3
29: 10 _dbus_warn+0x6e [../../dbus/dbus-internals.c:259] in libdbus-1-3
29: 11 main+0xa97 [../../bus/main.c:705] in dbus-daemon
29: 12 EntryPoint+0xffffffffffffffff in dbus-daemon
29: 13 0x7b463e32 in kernel32
29: 14 0x7b4661ac in kernel32
29: 15 0x7b463e3e in kernel32
29: ok 1
29: ok 2
29: ok 3
29: 1..3
29/29 Test #29: test-shutdown .................... Passed 0.34 sec
```
From what I see, the test starts a dbus daemon with a preconfigured session bus that does not match the default autolaunch address. So the client automatically starts an additional dbus daemon, with `--session' as argument.
Since it does not find the requested session configuration file in `z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/share\dbus-1\session.conf`, it is terminated. The test case passes because it connects to the previously started dbus daemon.Ralf HabackerRalf Habackerhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/298The documentation is missing for bus_transaction_xxx functions2020-05-17T10:12:38ZRalf HabackerThe documentation is missing for bus_transaction_xxx functionsWhile working on !95 it turned out that some of the used functions are not documented, which makes it difficult to understand these functions.While working on !95 it turned out that some of the used functions are not documented, which makes it difficult to understand these functions.https://gitlab.freedesktop.org/dbus/dbus/-/issues/299Failed to set fd limit [OSX]2020-05-10T03:50:33ZKrisFailed to set fd limit [OSX]When I run `dbus-daemon --session --nofork --address unix:path=$MY_SESSION_BUS_SOCKET` following error appears
```
dbus-daemon[13247]: [session uid=502 pid=13247] org.freedesktop.DBus.Error.Failed: Failed to set fd limit to 922337203685...When I run `dbus-daemon --session --nofork --address unix:path=$MY_SESSION_BUS_SOCKET` following error appears
```
dbus-daemon[13247]: [session uid=502 pid=13247] org.freedesktop.DBus.Error.Failed: Failed to set fd limit to 9223372036854775807: Invalid argument
```
Have no idea what happened, I installed `dbus` from homebrewhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/328Can you add my library to the DBusBindings page?2021-12-06T23:54:42Zigo95862Can you add my library to the DBusBindings page?https://www.freedesktop.org/wiki/Software/DBusBindings/
This is a page with all different dbus libraries.
I developed a new library called python-sdbus: https://github.com/igo95862/python-sdbus
Not sure if this is correct channel.https://www.freedesktop.org/wiki/Software/DBusBindings/
This is a page with all different dbus libraries.
I developed a new library called python-sdbus: https://github.com/igo95862/python-sdbus
Not sure if this is correct channel.https://gitlab.freedesktop.org/dbus/dbus/-/issues/300For development work on dbus, the output generated by doxygen should contain ...2020-05-17T10:10:56ZRalf HabackerFor development work on dbus, the output generated by doxygen should contain more informationFor development work on dbus, the output generated by doxygen should contain more information.
This includes the inclusion of all sources and global elements, a search, alphabetical indexes and call/caller graphs.
This was detected on t...For development work on dbus, the output generated by doxygen should contain more information.
This includes the inclusion of all sources and global elements, a search, alphabetical indexes and call/caller graphs.
This was detected on ticket #298.https://gitlab.freedesktop.org/dbus/dbus/-/issues/329Move of zbus under dbus space2021-02-04T16:37:31ZZeeshan Ali Khanzeeshanak@gnome.orgMove of zbus under dbus space[zbus](https://gitlab.freedesktop.org/zeenix/zbus) is a pure Rust D-Bus library that's been gaining a lot of traction lately. Since it's in a good shape now, I'd really like for it to be moved from my personal space to `dbus` space.
Whi...[zbus](https://gitlab.freedesktop.org/zeenix/zbus) is a pure Rust D-Bus library that's been gaining a lot of traction lately. Since it's in a good shape now, I'd really like for it to be moved from my personal space to `dbus` space.
While, I didn't manage to get any response to this proposal on the [dbus list](https://lists.freedesktop.org/archives/dbus/2021-January/017962.html) (so far), in my chat with @smcv I understood that they'd not be against this.
I think all that's needed from the admins here is for adding me to members of the dbus space. I'm hoping
@walters and @@lennart can vouch for me. :)https://gitlab.freedesktop.org/dbus/dbus/-/issues/301dbus-monitor gets disconnected by dbus-broker for trying to send a message2022-10-11T11:45:12ZWill Thompsondbus-monitor gets disconnected by dbus-broker for trying to send a messageWhile smoke-testing Bustle on a Fedora 32 computer I noticed that `dbus-monitor` sometimes gets abruptly disconnected from the bus. I found the following in the journal:
```
May 20 23:26:09 gelf dbus-broker[2628]: Monitor :1.311 is bein...While smoke-testing Bustle on a Fedora 32 computer I noticed that `dbus-monitor` sometimes gets abruptly disconnected from the bus. I found the following in the journal:
```
May 20 23:26:09 gelf dbus-broker[2628]: Monitor :1.311 is being disconnected as it attempted to send a message.
```
Sure enough, strace confirms that it's trying to send a message:
```
$ strace -e write=3 dbus-monitor --pcap >ohno.pcap
...
sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\2\1\1\0\0\0\0\3\0\0\0\30\0\0\0\6\1s\0\6\0\0\0:1.322\0\0"..., iov_len=40}, {iov_base="", iov_len=0}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 40
* 40 bytes in buffer 0
| 00000 6c 02 01 01 00 00 00 00 03 00 00 00 18 00 00 00 l............... |
| 00010 06 01 73 00 06 00 00 00 3a 31 2e 33 32 32 00 00 ..s.....:1.322.. |
| 00020 05 01 75 00 12 00 00 00 ..u..... |
```
Deserializing this with `GDBusMessage` gives:
```
Type: method-return
Flags: no-reply-expected
Version: 0
Serial: 3
Headers:
reply-serial -> uint32 18
destination -> ':1.322'
Body: ()
UNIX File Descriptors:
(none)
```
Rather suspiciously, the last few messages in the pcap file are:
1. AddMatch from :1.322 to org.freedesktop.DBus, serial 17
2. org.freedesktop.DBus responding to that method call
3. org.freedesktop.DBus responding to the invisible call with serial 18
4. org.freedesktop.DBus.Local.Disconnected
That's as far as I got. :(https://gitlab.freedesktop.org/dbus/dbus/-/issues/302dbus_connection_send_with_reply_and_block() never returns2020-06-03T14:39:32ZAdam Nielsendbus_connection_send_with_reply_and_block() never returnsI am debugging an issue with the LightDM display manager, which freezes during start up. The backtrace reveals that it calls `gtk_init()` which in turn calls `atspi_get_a11y_bus()` and this function calls `dbus_bus_register()`. Here, `...I am debugging an issue with the LightDM display manager, which freezes during start up. The backtrace reveals that it calls `gtk_init()` which in turn calls `atspi_get_a11y_bus()` and this function calls `dbus_bus_register()`. Here, `dbus_connection_send_with_reply_and_block()` gets called but never returns. It just sits there at `poll()` and no matter how long I leave it, nothing happens.
I am not sure how to debug this issue any further. How can I see what DBus is sending and receiving, or find out why it is not getting a reply in this case?
Also, looking at the code, there appears to be no timeout when `dbus_bus_register()` makes the blocking call. Wouldn't it be better to have a timeout so that there will at least be an error message after a few seconds rather than a permanent freeze?
In this case when I run lightdm as the root user everything works fine, but when I run it via systemd it freezes as described. When I use strace to compare the two invocations I can see that when everything works, one DBus connection is used:
```
connect(7, {sa_family=AF_UNIX, sun_path="/var/run/dbus/system_bus_socket"}, 110) = 0
sendto(7, "AUTH EXTERNAL 363230\r\n", 22, MSG_NOSIGNAL, NULL, 0) = 22
recvfrom(7, "OK 7f94aa8da629128be07028bc5e93e"..., 4096, 0, NULL, NULL) = 37
```
However when launched via systemd and it freezes, I get a different DBus connection:
```
connect(6, {sa_family=AF_UNIX, sun_path="/run/user/620/bus"}, 19) = 0
sendto(6, "AUTH EXTERNAL 363230\r\n", 22, MSG_NOSIGNAL, NULL, 0) = 22
poll([{fd=6, events=POLLIN}], 1, -1
```
I am not sure what this means.
What would cause `dbus_connection_send_with_reply_and_block()` to never return?https://gitlab.freedesktop.org/dbus/dbus/-/issues/303Follow-up from "cmake: Fix installed files"2020-06-02T06:34:24ZRalf HabackerFollow-up from "cmake: Fix installed files"The following discussion from !155 should be addressed:
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/155#note_518092):
> This is a nice idea, and I appreciate the effort to get this ...The following discussion from !155 should be addressed:
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/155#note_518092):
> This is a nice idea, and I appreciate the effort to get this tested, but I don't think it really scales: each build takes a significant time, and adding two extra builds per feature could quickly become extremely time-consuming. If a Gitlab-CI build ends up doing multiple variant builds one after the other in a shell script loop, Gitlab can't parallelize them, so we'd end up waiting for a long time for success/failure feedback from the CMake build.
>
> Also, just checking that they compile without also running their tests doesn't seem great, and this feature seems confusingly similar to the `ci_variant` that we already have for Autotools.
>
> If we want to test additional configurations under CMake, the way to do that is to add more `ci_variant` builds to `.gitlab-ci.yml`, and include those configurations in them (they should probably be off-by-default to avoid using excessive CI resources, and we can trigger them manually when needed). For example, with Autotools, the `production` (default), `debug`, `reduced` and `legacy` variants each use different options. We don't have individual variants for each feature, because it doesn't scale - we bundle a lot of optional features being enabled into `debug`, and we bundle a lot of optional features being disabled into `reduced`.
>
> At the moment the CMake part of `tools/ci-build.sh` doesn't support variants at all. If you want to add something like
>
> ```
> (cmake|cmake-dist)
> case "$ci_variant" in
> (reduced)
> set -- "$@" -D ENABLE_SYSTEMD=OFF
> ... maybe more options here later ...
> ;;
> esac
>
> case "$ci_host" in
> (*-w64-mingw32)
> ... back to the current code ...
> ```
>
> mirroring the way it's done for Autotools, then that would be fine.
>
> The simple way to resolve this would be to drop this commit, and consider adding `ci_variant` as a separate MR.https://gitlab.freedesktop.org/dbus/dbus/-/issues/304test-fdpass fails on Solaris derivatives after fixing CVE-2020-120492020-07-01T15:23:21ZAndy Fiddamantest-fdpass fails on Solaris derivatives after fixing CVE-2020-12049I'm working on a UNIX operating system called OmniOS, an illumos derivative (formerly OpenSolaris).
Upgrading to dbus 1.12.18 causes a new test failure in test-fdpass.
```
% gmake test-fdpass.log
PASS: test-fdpass 1 /unsupported
PASS: ...I'm working on a UNIX operating system called OmniOS, an illumos derivative (formerly OpenSolaris).
Upgrading to dbus 1.12.18 causes a new test failure in test-fdpass.
```
% gmake test-fdpass.log
PASS: test-fdpass 1 /unsupported
PASS: test-fdpass 2 /relay
PASS: test-fdpass 3 /limit
ERROR: test-fdpass - too few tests run (expected 15, got 3)
ERROR: test-fdpass - exited with status 262 (terminated by signal 6?)
```
The failure is in the `test_too_many()` function where it's waiting for the sender to be unceremoniously disconnected
```C
/* The sender is unceremoniously disconnected. */
while (dbus_connection_get_is_connected (f->left_client_conn) ||
dbus_connection_get_is_connected (f->left_server_conn))
{
test_progress ('.');
test_main_context_iterate (f->ctx, TRUE);
}
```
while in this loop, it logs:
```
dbus[29630]: invalid request, socket fd 0 not open
```
and aborts.
If I revert 872b085f12f56da25a2dbd9bd0b2dff31d5aea63 (the recent CVE fix), then the test passes again.