dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2023-03-08T19:44:39Zhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/394Migrate license strings to SPDX short identifiers2023-03-08T19:44:39ZRalf HabackerMigrate license strings to SPDX short identifiers## Does your feature request relate to a problem? Please describe it.
Identifying the license for open source software is important for both reporting and license compliance. However, determining the license can sometimes be difficult d...## Does your feature request relate to a problem? Please describe it.
Identifying the license for open source software is important for both reporting and license compliance. However, determining the license can sometimes be difficult due to lack of information or ambiguity. Even when license information is available, the lack of consistent notation can make automating license determination very difficult, requiring a lot of human effort.
## Describe the desired solution
[Short identifiers](https://spdx.github.io/spdx-spec/using-SPDX-short-identifiers-in-source-files/) from the SPDX license list can be used to specify file-level license information.
## Describe the alternatives you considered.
Short identifiers provided by the SPDX license project seem to be the best approach and are already used by larger projects such as KDE and already sporadically in the [dbus sources](https://gitlab.freedesktop.org/search?search=SPDX&group_id=1186&project_id=1187&scope=&search_code=true&snippets=false&repository_ref=master&nav_source=navbar).
# Additional information
There are also already tools that can help migrate the current license information, such as [licensedigger](https://invent.kde.org/sdk/licensedigger/) which is used in the migration of [KDE projects](https://community.kde.org/Guidelines_and_HOWTOs/Licensing).https://gitlab.freedesktop.org/dbus/dbus/-/issues/391introspect.dtd error 4042023-07-10T11:05:34ZRustam Abdullaevintrospect.dtd error 404## To reproduce
Steps to reproduce the behavior:
1. Open D-Bus docs: https://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format
2. Open the DTD from the example XML file:
http://www.freedesktop.org/standards/dbus/1...## To reproduce
Steps to reproduce the behavior:
1. Open D-Bus docs: https://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format
2. Open the DTD from the example XML file:
http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd
## Expected result
A valid DTD XML should be returned.
## Actual result
HTTP Error 404 Not Found.
## Additional context
It seems the DTD is gone from www.freedesktop.org. This causes XML validation errors in XML Tools and VS Code.
Please publish the [DTD](https://raw.githubusercontent.com/freedesktop/dbus/master/doc/introspect.dtd) back at http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd or update the documentation with the correct DTD location.https://gitlab.freedesktop.org/dbus/dbus/-/issues/390avahi client via dbus with dynamic user2022-04-01T13:58:22ZChristian Hesseavahi client via dbus with dynamic user## General information
To distribute package archives (for `pacman` / Arch Linux) in local network I wrote a tool called [`pacredir`](https://github.com/eworm-de/pacredir). It redirects http requests to other hosts, these are found via ...## General information
To distribute package archives (for `pacman` / Arch Linux) in local network I wrote a tool called [`pacredir`](https://github.com/eworm-de/pacredir). It redirects http requests to other hosts, these are found via `avahi` client API.
The described issue started to happen with `dbus` `1.14.0`, everything worked fine with version `1.12.x`.
## To reproduce
Steps to reproduce the behavior:
1. install `pacredir`: `pacman -S pacredir`
2. try to start the service: `systemctl start pacredir.service`
## Expected result
The service starts `pacredir` with a dynamic user (`systemd`'s `DynamicUser=on`). The service should connect to `avahi`, receive information and start redirecting requests.
## Actual result
The service fails to start with:
```
pacredir[355]: Failed to create client: An unexpected D-Bus error occurred
```
The failing call is [avahi_client_new()](https://github.com/eworm-de/pacredir/blob/a94962c502c5ca88b5546b34d0416af40cf8af44/pacredir.c#L774).
Starting the command from terminal (as root) or with `DynamicUser=off` works around the issue and communication with `avahi` daemon works as expected.https://gitlab.freedesktop.org/dbus/dbus/-/issues/389Sending SIGTERM to dbus-run-session only kills itself, and the underlying dbu...2022-03-30T02:46:10ZAnimesh SahuSending SIGTERM to dbus-run-session only kills itself, and the underlying dbus-daemon zombies.## To reproduce
Steps to reproduce the behavior:
1. Run `dbus-run-session sleep 100`
2. Now send SIGTERM to the `dbus-run-session`, from anywhere.
## Expected result
The dbus-run-session exits, but dbus-daemon associated is still aliv...## To reproduce
Steps to reproduce the behavior:
1. Run `dbus-run-session sleep 100`
2. Now send SIGTERM to the `dbus-run-session`, from anywhere.
## Expected result
The dbus-run-session exits, but dbus-daemon associated is still alive and gets detached and stays alive.
## Actual result
SIGTERM should be propagated to dbus-daemon before dbus-run-session exits.
## Additional context
(~~SIGINT~~ Ctrl+C on terminal seems to work fine killing the daemon)https://gitlab.freedesktop.org/dbus/dbus/-/issues/382socketpair() is not in libc on illumos2022-03-08T16:37:17ZAndy Fiddamansocketpair() is not in libc on illumosOn illumos, the `socketpair()` function is in `libsocket` and not `libc`.
https://illumos.org/man/socketpair
Running the testsuite in version 1.14.0 results in:
```
#5 0xfffffc7fef2d7cac in _dbus_warn (
format=0xfffffc7fef2e87b0 ...On illumos, the `socketpair()` function is in `libsocket` and not `libc`.
https://illumos.org/man/socketpair
Running the testsuite in version 1.14.0 results in:
```
#5 0xfffffc7fef2d7cac in _dbus_warn (
format=0xfffffc7fef2e87b0 "_dbus_socketpair() not implemented on this OS")
at dbus-internals.c:257
```
The configure test for `socketpair()` should probably be implemented with
```
AC_SEARCH_LIBS(socketpair,[socket])
```
as is already done for the `socket()` function.https://gitlab.freedesktop.org/dbus/dbus/-/issues/371Superfluous error message in case of DBUS_ERROR_NO_MEMORY2022-03-01T18:52:00ZRalf HabackerSuperfluous error message in case of DBUS_ERROR_NO_MEMORYIn dbus code there are several locations where code like this used:
```
dbus_set_error (error, DBUS_ERROR_NO_MEMORY, "Could not allocate memory for directory filename copy");
```
It was mentioned at https://gitlab.freedesktop.org/dbus/...In dbus code there are several locations where code like this used:
```
dbus_set_error (error, DBUS_ERROR_NO_MEMORY, "Could not allocate memory for directory filename copy");
```
It was mentioned at https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/95#note_1186686 that the current dbus code is such that the message provided cannot be displayed because it would require additional memory, but because this error has been set, it no longer exists.
At these places `BUS_SET_OOM (error);` should therefore be used to indicate that no more specific message is possible here.
The related locations can be extracted with:
```
grep -rn -A1 "dbus_set_error (" bus dbus tools | gawk '$0 ~ /dbus_set_error/ && ($0 !~ /NO_MEMORY/ || $0 ~ /NO_MEMORY, NULL/) { getline; getline; } $0 !~ /^--$/ { print $0} '
bus/activation.c:1419: dbus_set_error (error, DBUS_ERROR_NO_MEMORY,
bus/activation.c-1420- "Launcher could not run (out of memory)");
dbus/dbus-sysdeps-util-win.c:420: dbus_set_error (error, DBUS_ERROR_NO_MEMORY,
dbus/dbus-sysdeps-util-win.c-421- "Could not allocate memory for directory filename copy");
dbus/dbus-sysdeps-util-win.c:430: dbus_set_error (error, DBUS_ERROR_NO_MEMORY,
dbus/dbus-sysdeps-util-win.c-431- "Could not append filename wildcard");
dbus/dbus-sysdeps-util-win.c:440: dbus_set_error (error, DBUS_ERROR_NO_MEMORY,
dbus/dbus-sysdeps-util-win.c-441- "Could not append filename wildcard 2");
dbus/dbus-sysdeps-util-win.c:450: dbus_set_error (error, DBUS_ERROR_NO_MEMORY,
dbus/dbus-sysdeps-util-win.c-451- "Could not allocate memory for directory iterator");
dbus/dbus-sysdeps-util-win.c:536: dbus_set_error (error, DBUS_ERROR_NO_MEMORY,
dbus/dbus-sysdeps-util-win.c-537- "No memory to read directory entry");
dbus/dbus-spawn-unix.c:793: dbus_set_error (error, DBUS_ERROR_NO_MEMORY,
dbus/dbus-spawn-unix.c-794- "Failed to fork a new process %s: %s",
dbus/dbus-sysdeps-win.c:1919: dbus_set_error (error, DBUS_ERROR_NO_MEMORY,
dbus/dbus-sysdeps-win.c-1920- "Failed to allocate file handle array");
dbus/dbus-server-launchd.c:108: dbus_set_error (error, DBUS_ERROR_NO_MEMORY,
dbus/dbus-server-launchd.c-109- "launch_data_new_string(\"%s\") Unable to create string.\n",
dbus/dbus-sysdeps-unix.c:1322: dbus_set_error (error, DBUS_ERROR_NO_MEMORY,
dbus/dbus-sysdeps-unix.c-1323- "Failed to allocate file handle array.");
dbus/dbus-sysdeps-unix.c:1728: dbus_set_error (error, DBUS_ERROR_NO_MEMORY,
dbus/dbus-sysdeps-unix.c-1729- "Failed to allocate file handle array");
dbus/dbus-sysdeps-util-unix.c:714: dbus_set_error (error, DBUS_ERROR_NO_MEMORY,
dbus/dbus-sysdeps-util-unix.c-715- "Could not allocate memory for directory iterator");
dbus/dbus-sysdeps-util-unix.c:771: dbus_set_error (error, DBUS_ERROR_NO_MEMORY,
dbus/dbus-sysdeps-util-unix.c-772- "No memory to read directory entry");
```https://gitlab.freedesktop.org/dbus/dbus/-/issues/367Autolaunch specific functions in _dbus_server_listen_platform_specific() shou...2022-03-04T11:31:48ZRalf HabackerAutolaunch specific functions in _dbus_server_listen_platform_specific() should get a DBusError parameter@smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/239#note_1190045) that _dbus_daemon_is_session_bus_address_published(), _dbus_daemon_publish_session_bus_address(), _dbus_daemon_unpublish_session_bus...@smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/239#note_1190045) that _dbus_daemon_is_session_bus_address_published(), _dbus_daemon_publish_session_bus_address(), _dbus_daemon_unpublish_session_bus_address() and related functions should get a parameter of type DBusError to distinguish errors.https://gitlab.freedesktop.org/dbus/dbus/-/issues/364Large messages need many calls to dbus_connection_read_write2021-12-14T13:57:10Zdiwic1Large messages need many calls to dbus_connection_read_writeHi,
A user of the Rust libdbus bindings have reported that large messages may take several rounds of calls to dbus_connection_read_write to receive a large message. We speculate that every call to dbus_connection_read_write can only rec...Hi,
A user of the Rust libdbus bindings have reported that large messages may take several rounds of calls to dbus_connection_read_write to receive a large message. We speculate that every call to dbus_connection_read_write can only receive 2048 bytes from the socket, regardless of the value of timeout_milliseconds.
This seems like a bug to me, but if it is intended behavior then it should be clearly documented, and also there needs to be an API call to figure out whether or not one should call dbus_connection_read_write again.
Issue reference: https://github.com/diwic/dbus-rs/issues/364https://gitlab.freedesktop.org/dbus/dbus/-/issues/358[HELP] Trying to write a correct busconfig for a third party system bus service2021-12-04T16:50:27ZScott Hamilton[HELP] Trying to write a correct busconfig for a third party system bus service| :zap: I'm using NIXOS |
|-----------------------------------------|
Hello, I’m currently trying to package my own software which runs a system service (as root).
It doesn’t necessarly need to run as root but it’s kin...| :zap: I'm using NIXOS |
|-----------------------------------------|
Hello, I’m currently trying to package my own software which runs a system service (as root).
It doesn’t necessarly need to run as root but it’s kind of the default for all system services. At some point I should consider running it as a special system user with fewer privileges. It only needs to access specific data directory on the system and a single internet port.
I implemented a dbus server that serves an interface with sdbusplus, here are the specifications.
The interface is very simple:
* Only one object: `/org/scotthamilton/rpifanserver`
* Only one interface: `org.scotthamilton.RpiFanServe` with only one property: `CacheLifeExpectancy`
* Only one connection name (bus name): `org.scotthamilton.RpiFanServe`
* Last but not least, every user of the `rpi-fan-serve` group should be able to write to `CacheLifeExpectancy`.
That’s it.
Here is my take on trying to make a system bus config that implements those requirements:
```xml
<?xml version="1.0" encoding="UTF-8"?> <!-- -*- XML -*- -->
<!DOCTYPE busconfig PUBLIC
"-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<policy user="root">
<!-- Only root can own the service -->
<allow own="org.scotthamilton.RpiFanServe"/>
</policy>
<policy group="rpi-fan-serve">
<!-- Dbus defaults -->
<allow send_destination="org.scotthamilton.RpiFanServe"
send_interface="org.scotthamilton.RpiFanServe"/>
<allow send_destination="org.scotthamilton.RpiFanServe"
send_interface="org.freedesktop.DBus.Introspectable"/>
<allow send_destination="org.scotthamilton.RpiFanServe"
send_interface="org.freedesktop.DBus.Peer"/>
<allow send_destination="org.scotthamilton.RpiFanServe"
send_interface="org.freedesktop.DBus.Properties"/>
<allow send_destination="org.scotthamilton.RpiFanServe"
send_interface="org.freedesktop.DBus.ObjectManager"/>
</policy>
</busconfig>
```
I took the assumption from reading the doc that this config would mean that every message coming from senders that belong to the `rpi-fan-serve` group would be allowed to call methods from the `org.freedesktop.DBus.Properties` interface on the `org.scotthamilton.RpiFanServe` destination bus.
And this works fine. My dbus server can acquire the bus name, I can send messages to it and they get received perfectly. But I can only set `CacheLifeExpectancy` with root.
Or in other words,
this works:
```bash
sudo busctl set-property org.scotthamilton.RpiFanServe /org/scotthamilton/rpifanserver org.scotthamilton.RpiFanServe CacheLifeExpectancy x 3600
```
but this doesn’t work (same but without sudo)
```bash
busctl set-property org.scotthamilton.RpiFanServe /org/scotthamilton/rpifanserver org.scotthamilton.RpiFanServe CacheLifeExpectancy x 3600
```
Output: `Failed to set property CacheLifeExpectancy on interface org.scotthamilton.RpiFanServe: Access denied`
I ran a bus monitor to figure out what was going on:
```bash
sudo busctl monitor org.scotthamilton.RpiFanServe
```
Output on error:
```bash
Monitoring bus message stream.
‣ Type=method_call Endian=l Flags=0 Version=1 Cookie=2
Sender=:1.87 Destination=org.scotthamilton.RpiFanServe Path=/org/scotthamilton/rpifanserver Interface=org.freedesktop.DBus.Properties Member=Set
UniqueName=:1.87
MESSAGE "ssv" {
STRING "org.scotthamilton.RpiFanServe";
STRING "CacheLifeExpectancy";
VARIANT "x" {
INT64 8080;
};
};
‣ Type=method_call Endian=l Flags=0 Version=1 Cookie=4
Sender=:1.85 Destination=org.freedesktop.DBus Path=/org/freedesktop/DBus Interface=org.freedesktop.DBus Member=GetConnectionUnixUser
UniqueName=:1.85
MESSAGE "s" {
STRING ":1.87";
};
‣ Type=method_return Endian=l Flags=1 Version=1 Cookie=5 ReplyCookie=4
Sender=org.freedesktop.DBus Destination=:1.85
MESSAGE "u" {
UINT32 1001;
};
‣ Type=error Endian=l Flags=1 Version=1 Cookie=5 ReplyCookie=2
Sender=:1.85 Destination=:1.87
ErrorName=org.freedesktop.DBus.Error.AccessDenied ErrorMessage="Access to org.scotthamilton.RpiFanServe.CacheLifeExpectancy() not permitted."
UniqueName=:1.85
MESSAGE "s" {
STRING "Access to org.scotthamilton.RpiFanServe.CacheLifeExpectancy() not permitted.";
};
```
So it seems like it’s not even the `org.freedesktop.DBus.Properties.Set` method call that was denied but the `org.scotthamilton.RpiFanServe.CacheLifeExpectancy()`. I don’t know what to do because I already allowed the `rpi-fan-serve` group to access to the `org.scotthamilton.RpiFanServe` interface.
For clarity, here is the output of `id` command to show that I’m indeed belonging to the `rpi-fan-serve` group.
```bash
uid=1001(scott) gid=100(users) groupes=100(users),1(wheel),57(networkmanager),131(docker),995(rpi-fan-serve)
```https://gitlab.freedesktop.org/dbus/dbus/-/issues/351RemoveMatch returns success even if the match rule didn't exist2021-11-24T12:54:47ZSimon McVittieRemoveMatch returns success even if the match rule didn't existReported by Robert Middleton on the mailing list.
## Steps to reproduce
* `dbus-monitor &`
* `dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.RemoveMatch string:"type='signal'"`
## Expect...Reported by Robert Middleton on the mailing list.
## Steps to reproduce
* `dbus-monitor &`
* `dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.RemoveMatch string:"type='signal'"`
## Expected result
Error named `org.freedesktop.DBus.Error.MatchRuleNotFound`, with message `The given match rule wasn't found and can't be removed`
## Actual result
The dbus-daemon sends a successful reply *and* an error reply
## Cause
```
/* Send the ack before we remove the rule, since the ack is undone
* on transaction cancel, but rule removal isn't.
*/
if (!bus_driver_send_ack_reply (connection, transaction, message, error))
goto failed;
matchmaker = bus_connection_get_matchmaker (connection);
if (!bus_matchmaker_remove_rule_by_value (matchmaker, rule, error))
goto failed;
```
The "ack" (successful reply with no arguments) is attached to the transaction even if removing the match rule is going to fail, and is not removed from the transaction on failure (and in fact I don't think we have any way to achieve that).https://gitlab.freedesktop.org/dbus/dbus/-/issues/349CMake support files generated by the autotools specify IMPORTED_LOCATION inco...2021-11-25T09:34:48ZRalf HabackerCMake support files generated by the autotools specify IMPORTED_LOCATION incorrectlyThe IMPORTED_LOCATION property is used by newer cmake releases to check required runtime dependencies as you can see below, where the package with the shared library was not installed.
```
[ 126s] CMake Error at /usr/i686-w64-mingw32/sy...The IMPORTED_LOCATION property is used by newer cmake releases to check required runtime dependencies as you can see below, where the package with the shared library was not installed.
```
[ 126s] CMake Error at /usr/i686-w64-mingw32/sys-root/mingw/lib/cmake/DBus1/DBus1Targets.cmake:93 (message):
[ 126s] The imported target "dbus-1" references the file
[ 126s]
[ 126s] "/usr/i686-w64-mingw32/sys-root/mingw/bin/libdbus-1-3.dll"
[ 126s]
[ 126s] but this file does not exist. Possible reasons include:
[ 126s]
[ 126s] * The file was deleted, renamed, or moved to another location.
[ 126s]
[ 126s] * An install or uninstall procedure did not complete successfully.
```
Checking that is useful to avoid problems when running applications that require the DBus library.
How to reproduce
----------------
1. build dbus for windows with cmake
2. build dbus for windows with autotools
3. Inspect and compare the generated cmake support files
What happens
------------
The corresponding part from the file used by autotools to generate cmake support files is:
```
# find import library for dbus
find_library(DBus1_LIBRARY NAMES ${PC_DBUS1_LIBRARIES}
HINTS ${PC_DBUS1_LIBDIR} ${PC_DBUS1_LIBRARY_DIRS})
set_property(TARGET dbus-1 APPEND PROPERTY IMPORTED_LOCATION ${DBus1_LIBRARY})
set_property(TARGET dbus-1 APPEND PROPERTY IMPORTED_IMPLIB ${DBus1_LIBRARY})
```
where the line
```
set_property(TARGET dbus-1 APPEND PROPERTY IMPORTED_LOCATION ${DBus1_LIBRARY})
```
points to the import library where it should point to the shared library.
Since the line `set_property(TARGET dbus-1 APPEND PROPERTY IMPORTED_LOCATION ${DBus1_LIBRARY})` refers to the import library on Windows, cmake does not raise `file not exist` errors (because the import library has been found above), however, it bypasses the mentioned check for the runtime component.
What is expected
----------------
The following code fragment from a generated cmake support file for setting the target properties of target dbus on Windows looks like:
```
# Import target "dbus-1"
set_target_properties(dbus-1 PROPERTIES
IMPORTED_IMPLIB "${_IMPORT_PREFIX}/lib/libdbus-1.dll.a"
IMPORTED_LOCATION "${_IMPORT_PREFIX}/bin/libdbus-1-3.dll"
)
```
and shows that properties for the import and shared library for dbus are correctly set.
Followup from https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/172#note_1162222https://gitlab.freedesktop.org/dbus/dbus/-/issues/348Draft: URI syntax to identify D-Bus resources2021-11-18T13:02:00ZMarc-André LureauDraft: URI syntax to identify D-Bus resources# Motivation
The current specification offers "Server Addresses", to allow description of listenable and connectable addresses. While this description is useful to configure basic connection details, it doesn't offer any way to identify...# Motivation
The current specification offers "Server Addresses", to allow description of listenable and connectable addresses. While this description is useful to configure basic connection details, it doesn't offer any way to identify a particular D-Bus resource, such as a service, an interface or an object. Furthermore, it doesn't conform with the standard RFC3986 URI syntax, which challenges applications with different mechanisms when they need to refer to heterogeneous resources.
# Proposal
Introduce a URI syntax for ``dbus``, with the general form:
dbus[+transport]://[authority][path][?extraparameters]
A D-Bus URI doesn't replace a D-Bus address: it doesn't offer any "listenable" options. Also, a URI doesn't have multiple addresses fallback mechanism. They serve different purposes and are complementary.
Examples:
- dbus:///system & dbus:///session
Identify the well-known buses (the mechanism to locate the address is as defined in "Well-known Message Bus Instances")
- dbus+unix:///path/to/socket, dbus+abstract:///abstract/path
- dbus+tcp://myserver:3289
(either ipv4 or ipv6?))
- dbus+unixexec:///path/to/program
(launchd & systemd should be covered by dbus+unix)
(autolaunch transport is not covered by the URI syntax at this point)
- dbus:///session?name=org.freedesktop.Service&path=/org/freedesktop/Path&interface=org.freedesktop.Interface
Identify the `org.freedesktop.Service` & `/org/freedesktop/Path` & `org.freedesktop.Interface` on the session bus.
The `name` parameter may be a well-known name or a unique name (a bus name).
## Extra parameters
Extra parameters can be added to URIs as part of the query string (the part following "?"). URIs understand the extra parameters shown below. Any others are passed unmodified through to the back end. Note that parameter values must be URI-escaped.
| Name | Transport | Meaning |
| ------ | ------ | ------ |
| guid | all | The server GUID |
| name, path, interface, property or method or signal | all | D-Bus resource identification |
| noncefile | tcp | File location containing the secret |
| argv0, argv1... | unixexec | Program arguments |https://gitlab.freedesktop.org/dbus/dbus/-/issues/339sudden dbus-launch issue (see description)2021-09-24T15:38:41ZMichal D.sudden dbus-launch issue (see description)While normal usage, the session has suddenlly crashed and when attempting to login, I recieved followed error from dbus-launch:
> dbus-launch: fatal error setting up standard fds: Failed to open /dev/null: Permission denied
I use a Deb...While normal usage, the session has suddenlly crashed and when attempting to login, I recieved followed error from dbus-launch:
> dbus-launch: fatal error setting up standard fds: Failed to open /dev/null: Permission denied
I use a Debian 10 on a 64-bit system. Other details about it only on request.https://gitlab.freedesktop.org/dbus/dbus/-/issues/337systemd and dbus sometimes disagree about whether the system bus connection h...2021-07-07T08:15:24ZIain Lanesystemd and dbus sometimes disagree about whether the system bus connection has authenticatedThis is related to, possibly the same as, https://github.com/systemd/systemd/issues/15316 and the LP bug is https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1871538. I'm not confident we aren't observing two issues though. Here I'll t...This is related to, possibly the same as, https://github.com/systemd/systemd/issues/15316 and the LP bug is https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1871538. I'm not confident we aren't observing two issues though. Here I'll talk about "Connection has not authenticated soon enough, closing it" which we're most recently observing with Azure instances running Ubuntu 21.04.
In these logs I'm using systemd 248.3-1ubuntu1 and dbus-daemon 1.12.20-2ubuntu1 compiled with verbose messages and running with `DBUS_VERBOSE=1`, but we managed to reproduce without. Actually adding `DBUS_VERBOSE=1` seems to make the issue a bit easier to hit, so maybe it's a race which is easier to lose under load.
What happens is that "sometimes" on boot all Type=dbus services have failed to start (resp. the other case: when dist-upgrading, all running Type=dbus service units lose their bus connection and get torn down).
In the logs when this has happened I can observe the following:
```
laney@dev> egrep "(bus-api-system|soon enough|Connection terminated)" journal-sorted.log
Jun 17 09:23:59.399376 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state UNSET → OPENING
Jun 17 09:23:59.399391 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: sd-bus: starting bus bus-api-system by connecting to /run/dbus/system_bus_socket...
Jun 17 09:23:59.399429 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state OPENING → AUTHENTICATING
Jun 17 09:23:59.808194 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state AUTHENTICATING → HELLO
Jun 17 09:24:09.255136 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state HELLO → RUNNING
Jun 17 09:25:06.580618 alan-hirsute-base-jzwgzzozgdyqauuqajbr dbus-daemon[610]: [system] Connection has not authenticated soon enough, closing it (auth_timeout=30000ms, elapsed: 53691ms)
Jun 17 09:25:09.221680 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state RUNNING → CLOSING
Jun 17 09:25:09.221741 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: polkit.service: Unexpected error response from GetNameOwner(): Connection terminated
Jun 17 09:25:09.221799 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state CLOSING → CLOSED
# here it starts working AFAICS
Jun 17 09:26:14.221908 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state UNSET → OPENING
Jun 17 09:26:14.221921 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: sd-bus: starting bus bus-api-system by connecting to /run/dbus/system_bus_socket...
Jun 17 09:26:14.221978 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state OPENING → AUTHENTICATING
Jun 17 09:26:14.229261 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state AUTHENTICATING → HELLO
Jun 17 09:26:14.245763 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state HELLO → RUNNING
```
[I've attached the full log here.](/uploads/bbc13facc5f01ba6f76d8b71824a3060/journal-sorted.log.xz) I can't see from the super verbose dbus-daemon logging whether systemd is wrong when it thinks it authenticated or not. Maybe a maintainer could peruse and advise if this seems to be systemd or dbus having a problem?
(I've had to re-sort the attached log by the way; while dbus-daemon and systemd's messages were correctly ordered with respect to themselves, they were interleaved wrong in the journal output, although it seems to have correct timestamps, so not sure what that's about really.)https://gitlab.freedesktop.org/dbus/dbus/-/issues/335[Compile error][-m32] dbus/.libs/libdbus-1.so2021-06-21T11:15:12Z𐰀𐰞𐰃:𐰺𐰃𐰔𐰀:𐰚𐰀𐰾𐰚𐰃𐰤 (𐰽𐰆𐰞𐰃𐰤𐰆𐰽)[Compile error][-m32] dbus/.libs/libdbus-1.so![image](/uploads/eb7cebe49a1803f947981c1abd7b17cf/image.png)
compile command:
```shell
export CFLAGS="-m32"
export CXXFLAGS="-m32"
autoreconf -fvi
./configure --prefix=/usr \
--disable-selinux \
--with-xml=expat \
--with-dbus-user=mess...![image](/uploads/eb7cebe49a1803f947981c1abd7b17cf/image.png)
compile command:
```shell
export CFLAGS="-m32"
export CXXFLAGS="-m32"
autoreconf -fvi
./configure --prefix=/usr \
--disable-selinux \
--with-xml=expat \
--with-dbus-user=messagebus \
--with-system-pid-file=/var/run/dbus.pid \
--disable-verbose-mode \
--disable-static \
--enable-inotify \
--disable-dnotify \
--enable-modular-tests=yes \
--disable-asserts \
--enable-user-session \
--enable-xml-docs \
--with-session-socket-dir=/tmp \
--with-x
make -J5
```
Target file is broken symlink (libdbus-1.so.3.29.0)
```shell
104564|sulin@DonkeyHUB dbus-1.13.18 $ file /tmp/inary/dbus-1.13.18-10/work-emul32/dbus-1.13.18/dbus/.libs/libdbus-1.so
/tmp/inary/dbus-1.13.18-10/work-emul32/dbus-1.13.18/dbus/.libs/libdbus-1.so: broken symbolic link to libdbus-1.so.3.29.0
```https://gitlab.freedesktop.org/dbus/dbus/-/issues/334feature request: dbus-send: add the ability to send variant maps2021-04-19T12:17:55ZFrederik Van Bogaertfeature request: dbus-send: add the ability to send variant mapsTL;DR: please apply the following patch:
```patch
diff --git a/tools/dbus-send.c b/tools/dbus-send.c
index 343fd75a..f2ed58cf 100644
--- a/tools/dbus-send.c
+++ b/tools/dbus-send.c
@@ -235,6 +235,8 @@ type_from_name (const char *arg)
...TL;DR: please apply the following patch:
```patch
diff --git a/tools/dbus-send.c b/tools/dbus-send.c
index 343fd75a..f2ed58cf 100644
--- a/tools/dbus-send.c
+++ b/tools/dbus-send.c
@@ -235,6 +235,8 @@ type_from_name (const char *arg)
type = DBUS_TYPE_BOOLEAN;
else if (!strcmp (arg, "objpath"))
type = DBUS_TYPE_OBJECT_PATH;
+ else if (!strcmp (arg, "variant"))
+ type = DBUS_TYPE_VARIANT;
else
{
fprintf (stderr, "%s: Unknown type \"%s\"\n", appname, arg);
```
Longer story:
I recently wanted to add a key binding to quickly open a new tab in my terminal editor (QTerminal) using its D-Bus API.
I was unable to do this, however, because of how it's implemented:
```bash
frederik@fredevuan-pc:~/dbus$ qdbus | grep QTerminal
org.lxqt.QTerminal-2715
frederik@fredevuan-pc:~/dbus$ dbus-send --print-reply --dest=org.lxqt.QTerminal-2715 / org.lxqt.QTerminal.Process.getActiveWindow
method return time=1618697773.286794 sender=:1.33 -> destination=:1.264 serial=139 reply_serial=2
object path "/windows/8dc2b39f09c549d0b5c467f613ff1c40"
frederik@fredevuan-pc:~/dbus$ dbus-send --session --print-reply --dest=org.lxqt.QTerminal-2715 /windows/8dc2b39f09c549d0b5c467f613ff1c40 org.freedesktop.DBus.Introspectable.Introspect | grep -A4 newTab
<method name="newTab">
<annotation value="QHash<QString,QVariant>" name="org.qtproject.QtDBus.QtTypeName.In0"/>
<arg direction="in" type="a{sv}" name="termArgs"/>
<arg direction="out" type="o" name="newTerminal"/>
</method>
```
The type a{sv} (implemented using QHash<QString,QVariant> in QtDBus) corresponds to a dict of string->variant mappings.
It turns out just providing an empty dictionary would work fine in my case.
However, neither `dbus-send` nor `qdbus` seem to support sending this type of argument.
```
frederik@fredevuan-pc:~/dbus$ dbus-send --print-reply --dest=org.lxqt.QTerminal-2715 /windows/8dc2b39f09c549d0b5c467f613ff1c40 org.lxqt.QTerminal.Window.newTab 'dict:string:variant:'
dbus-send: Unknown type "variant"
```
I found some leads, including a 5 year-old patch claiming to add support for this on Stack Overflow: https://stackoverflow.com/questions/8846671/how-to-use-a-variant-dictionary-asv-in-dbus-send
However, I'm not sure it still applies cleanly, so I tried the simpler approach I mentioned at the top of the description.
After that, it works, and I can successfully spawn new tabs in QTerminal. Hurray!
```
frederik@fredevuan-pc:~/dbus$ bin/dbus-send --print-reply -dest=org.lxqt.QTerminal-2715 /windows/8dc2b39f09c549d0b5c467f613ff1c40 org.lxqt.QTerminal.Window.newTab 'dict:string:variant:'
method return time=1618698152.478846 sender=:1.33 -> destination=:1.273 serial=145 reply_serial=2
object path "/tabs/a7ec38e4bee34ca2890470973fd986a3"
```
I also tried the procedure specified in your Contributing.md file (forking the repo on the freedesktop.org gitlab, adding the patch on a separate branch there, and opening a MR to https://gitlab.freedesktop.org/dbus/dbus/merge_requests.
However, I'm lacking the permissions here to actually open a Merge Request.
If this procedure is not correct, perhaps the contributing.md could be updated?
My repo is here: https://gitlab.freedesktop.org/fvanbogaert/dbus-send-variant (branch: https://gitlab.freedesktop.org/fvanbogaert/dbus-send-variant/-/commits/dev_add_variant_type_to_dbus_send)
Thanks :slight_smile:
Fixes: #59https://gitlab.freedesktop.org/dbus/dbus/-/issues/333feature/bug: Don't bother connecting/etc when globally instructed to not do so2021-03-20T11:32:51ZMartin Misuthfeature/bug: Don't bother connecting/etc when globally instructed to not do soI don't know where to report this, so after some detective work I assumed this is the right place.
If this is not the right place to report this, please direct me where is.
##### Feature/bug:
Please, provide a way to configure dbus-l...I don't know where to report this, so after some detective work I assumed this is the right place.
If this is not the right place to report this, please direct me where is.
##### Feature/bug:
Please, provide a way to configure dbus-less operation for dbus-enabled software on dbus-less systems.
This is of concern mainly on dbus "client" side.
Any of the following ways would be welcome:
- environment variable
- sentinel/config file somewhere in /run (tmpfs)
- sentinel/config file somewhere in /etc (fs)
##### The rationale:
On some "systems", dbus is not mandatory nor wanted. Note first, that I want to avoid igniting discord, so let's try not to get into politics of such usecases, but let us concentrate on the possible solution.
Such systems might be trimmed down systems for specialty uses (like kiosks and such), chroots, ad-hoc containers and others. I also want to make a point, that all these usescases are legitimate situations.
For many reasons, even in such situations, software might be installed, that has dbus support enabled (eg. compiled-in, called from scripting lanugages (in case of dynamic languages) etc), but dbus is intentionally not working.
In most cases, unless dbus is really hard requirement, such software works fine (often with some functionality disabled - but that may even be intended by operator), even if other dbus components (like system/user level daemon) are not present (eg, installed and/or running). My problem is, this software still tries to access various system (and user) dbus daemons controlled files and resources.
Case in point:
```
$ some-program
...
...
(some-program:567): IBUS-WARNING **: 15:26:36.344: Unable to load /var/lib/dbus/machine-id: Failed to open file “/var/lib/dbus/machine-id”: No such file or directory
```
I sporadically also see accesses to other dbus machinery (sockets and whatnot).
I would like to politely ask you to provide some way for operators to hint to dbus libraries and subsystems, that dbus is not even present, so that dbus subsystems and libraries are allow to "fail" quickly and early and without access warnings or errors, and should not even bother with trying to connect somewhere.
What I mean by that: such software already works when dbus fails, but it's dbus subsystems still try to access runtime and machine specific files and resources. This proves software can work without dbus, but still causes errors and warnings to collect in processes, sometime misdirecting other users on multi-user multitenant machines and whatnot. I want to be able to drop file or perhaps define envvar somewhere, that makes dbus subsystems report something else instead of warning or error, eg. something like:
```
(some-program:567): IBUS-NOTICE **: 15:26:36.344: won't connect to dbus, administratively prohibited.
```
As for solution, envvar seemed like good first idea but then I realized, that even unprivileged users might set that, and that might be seen as security issue by some (perhaps? I don't know about lot about dbus software, but I think Network Manager has privileged parts and uses it (dbus)), or not, I don't know. So second next best idea to me appears to be presence of some "sentinel" file in root owned directories - those are not easily spoofable and only system user and system administrators have controls of those, so that might be good trade-off.
This whole thing is mostly about semantics, missing `/var/lib/dbus/machine-id` already indicates that dbus is not present, but does not communicate intent, eg that this configuration is intentional.
I want to be able to set this hint once and let it trickle down from system level daemons to normal user level software.
If this is successfully implemented, it would allow for this change to disseminate down the stream to many dbus consumers, fixing this issue permanently.
Of course, it is possible that there is already a way to administratively indicate described situation. In that case I have not found it, so I would like to ask you for pointers on how I can configure this on my affected machines and containers.
Thank you.https://gitlab.freedesktop.org/dbus/dbus/-/issues/330Is it necessary set DBUS_SESSION_BUS_ADDRESS with gvfs fixed the access check2021-03-10T10:30:01ZEinsler LeeIs it necessary set DBUS_SESSION_BUS_ADDRESS with gvfs fixed the access checkThis has been merged 5 years ago: https://gitlab.gnome.org/GNOME/gvfs/-/commit/ac80e77f6e45a3b688238e1fbf5b8baba98b58b4 .
So dbus now doesn't need to check DBUS_SESSION_BUS_ADDRESS.This has been merged 5 years ago: https://gitlab.gnome.org/GNOME/gvfs/-/commit/ac80e77f6e45a3b688238e1fbf5b8baba98b58b4 .
So dbus now doesn't need to check DBUS_SESSION_BUS_ADDRESS.https://gitlab.freedesktop.org/dbus/dbus/-/issues/327CI: Avoid manual selecting package to install2021-01-21T13:09:01ZRalf HabackerCI: Avoid manual selecting package to installFor building dbus on CI several packages are required and were added to https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/tools/ci-install.sh by hand.
Recently I saw another approach based on the capability of `apt` to install buil...For building dbus on CI several packages are required and were added to https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/tools/ci-install.sh by hand.
Recently I saw another approach based on the capability of `apt` to install build dependencies (see https://invent.kde.org/office/kmymoney/-/blob/master/.gitlab-ci.yml), which could reduce the number of required package updates by running
```
sed -i -- 's/#[ ]*deb-src/deb-src/g' /etc/apt/sources.list
apt update
apt build-dep -y dbus
```
which returns
```
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
autoconf autoconf-archive automake autopoint autotools-dev binutils binutils-common binutils-x86-64-linux-gnu bsdmainutils build-essential cpp cpp-9 debhelper
dh-autoreconf dh-exec dh-strip-nondeterminism docbook-xml docbook-xsl doxygen dpkg-dev ducktype dwz file g++ g++-9 gcc gcc-9 gcc-9-base gettext gettext-base
gir1.2-glib-2.0 groff-base intltool-debian itstool libapparmor-dev libapparmor1 libarchive-zip-perl libasan5 libatomic1 libaudit-dev libbinutils libblkid-dev libbsd0
libc-dev-bin libc6-dbg libc6-dev libcap-ng-dev libcc1-0 libclang1-10 libcroco3 libcrypt-dev libctf-nobfd0 libctf0 libdbus-1-3 libdebhelper-perl libdpkg-perl libedit2
libelf1 libexpat1 libexpat1-dev libffi-dev libfile-stripnondeterminism-perl libgcc-9-dev libgdbm-compat4 libgdbm6 libgirepository-1.0-1 libglib2.0-0 libglib2.0-bin
libglib2.0-data libglib2.0-dev libglib2.0-dev-bin libgomp1 libicu66 libisl22 libitm1 libllvm10 liblsan0 libmagic-mgc libmagic1 libmount-dev libmpc3 libmpdec2 libmpfr6
libnss-wrapper libpcre16-3 libpcre2-16-0 libpcre2-32-0 libpcre2-dev libpcre2-posix2 libpcre3-dev libpcre32-3 libpcrecpp0v5 libperl5.30 libpipeline1 libpthread-stubs0-dev
libpython3-stdlib libpython3.8-minimal libpython3.8-stdlib libquadmath0 libreadline8 libselinux1-dev libsepol1-dev libsigsegv2 libsqlite3-0 libssl1.1 libstdc++-9-dev
libsub-override-perl libsystemd-dev libtool libtsan0 libubsan1 libuchardet0 libx11-6 libx11-data libx11-dev libxapian30 libxau-dev libxau6 libxcb1 libxcb1-dev libxdmcp-dev
libxdmcp6 libxml2 libxml2-utils libxslt1.1 linux-libc-dev m4 make man-db mime-support patch perl perl-modules-5.30 pkg-config po-debconf python3 python3-dbus
python3-distutils python3-gi python3-lib2to3 python3-libxml2 python3-mallard.ducktype python3-minimal python3-pkg-resources python3.8 python3.8-minimal readline-common
sgml-base sgml-data tzdata uuid-dev valgrind x11proto-core-dev x11proto-dev xml-core xmlto xorg-sgml-doctools xsltproc xtrans-dev xz-utils yelp-tools yelp-xsl zlib1g-dev
The following packages will be upgraded:
libsystemd0
1 upgraded, 163 newly installed, 0 to remove and 5 not upgraded.
Need to get 140 MB of archives.
...
```https://gitlab.freedesktop.org/dbus/dbus/-/issues/326Not canceled pending calls lead to memory leaks during dbus connection close2021-11-18T10:49:05ZxgsaNot canceled pending calls lead to memory leaks during dbus connection closeWe have bumped into an issue, that Valgrind reports memory leaks in the case, when `dbus_pending_call_set_notify` registers a callback and dbus connection is shutdown before the reply arrives. Here is [the minimized program](/uploads/369...We have bumped into an issue, that Valgrind reports memory leaks in the case, when `dbus_pending_call_set_notify` registers a callback and dbus connection is shutdown before the reply arrives. Here is [the minimized program](/uploads/369aa72f13953b35b1aee0ff615d0e7f/mem_leaks_libdbus.cpp), which reproduces the issue:
```
#include <cstdio>
#include <cstdlib>
#include <dbus/dbus.h>
void printf_and_exit(const char* error)
{
printf(error);
exit(EXIT_FAILURE);
}
int main(int argc, char **argv)
{
DBusError error;
dbus_error_init(&error);
printf("Connecting...\n");
DBusConnection *connection = dbus_bus_get_private(DBUS_BUS_SESSION, &error);
if (!connection)
printf_and_exit("ERROR: cannot initialize connection");
dbus_connection_set_exit_on_disconnect(connection, false);
printf("Creating a message for a method call...\n");
DBusMessage *msg = dbus_message_new_method_call("org.freedesktop.DBus", "/", "org.freedesktop.DBus", "GetId");
if (!msg)
printf_and_exit("ERROR: The message was not created\n");
printf("Sending the message...\n");
DBusPendingCall *pending_call = nullptr;
if (!dbus_connection_send_with_reply(connection, msg, &pending_call, 10000))
printf_and_exit("ERROR: The message was not sent\n");
dbus_pending_call_set_notify(
pending_call,
[](DBusPendingCall*, void*) { printf(">> In callback!\n"); },
nullptr,
[](void*) { printf(">> In free function!\n"); }
);
printf("Flushing connection...\n");
dbus_connection_flush(connection);
// !!! Without canceling pending call, there are memory leaks in this program.
// !!! With this line uncommented, no memory leaks are reported by Valgrind.
// dbus_pending_call_cancel(pending_call);
printf("Cleaning up...\n");
dbus_pending_call_unref(pending_call);
dbus_message_unref(msg);
dbus_connection_close(connection);
dbus_connection_unref(connection);
dbus_error_free(&error);
dbus_shutdown();
return EXIT_SUCCESS;
}
```
Please, note that if `dbus_pending_call_cancel` is uncommented, no memory leaks are reported by Valgrind (checked on the latest master branch; valgrind reports for both of the cases with [commented](/uploads/12cc76a3d57f796d520a69d1723306d2/commented_line_valgrind.log) and [uncommented](/uploads/1b97e1ec091e3aebca0b4795f24ee376/uncommented_line_valgrind.log) line are attached).
Currently, we have to workaround the issue by gathering pending calls after `dbus_pending_call_set_notify`, removing them if callback is called and canceling all the gathered pending calls during connection shutdown. This seems not very optimal, but as far as I know, dbus does not provide a way to enumerate pending calls of the `DBusConnection`, whereas it tracks them.
The suggested solution is to cancel all the pending calls during connection close, which seems to be logical. I think, I could provide the patch implementing this if the issue is confirmed and the solution is considered as appropriate. So what do you think?