dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2021-12-10T12:46:13Zhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/362Test applications do not display invalid test selection2021-12-10T12:46:13ZRalf HabackerTest applications do not display invalid test selectionOn https://gitlab.freedesktop.org/dbus/dbus/-/issues/360#note_1183092 you can see that an invalid name was used for a specific test, but the test application did not complain about this, which can lead to unexpected test results and shou...On https://gitlab.freedesktop.org/dbus/dbus/-/issues/360#note_1183092 you can see that an invalid name was used for a specific test, but the test application did not complain about this, which can lead to unexpected test results and should be corrected.https://gitlab.freedesktop.org/dbus/dbus/-/issues/361Running test-bus on Linux fails with 'dbus-daemon - Cannot initialize inotify'2022-09-08T17:55:49ZRalf HabackerRunning test-bus on Linux fails with 'dbus-daemon - Cannot initialize inotify'To see if the problem reported at https://gitlab.freedesktop.org/dbus/dbus/-/issues/360 was related to the cmake build system, the same test was compiled and run on Linux (openSUSE 15.2, gcc 7.5)
```
mkdir ~/src
cd ~/src
git clone https:...To see if the problem reported at https://gitlab.freedesktop.org/dbus/dbus/-/issues/360 was related to the cmake build system, the same test was compiled and run on Linux (openSUSE 15.2, gcc 7.5)
```
mkdir ~/src
cd ~/src
git clone https://gitlab.freedesktop.org/dbus/dbus.git
mkdir build-cmake
cd build-cmake
cmake ../dbus
make
ctest -R test-bus$ -VV
```
The following error occurred:
```
9: ok 6 - signals
9: # signals test took 1 seconds
9: ok 7 - signals did not leak memory
9: # Running test: activation-service-reload
9: dbus-daemon[28279]: Cannot initialize inotify
9: /home/xxx/src/dbus-cmake-build/lib/libdbus-1.so.3(_dbus_print_backtrace+0x1f) [0x7f0da73252cf]
9: /home/xxx/src/dbus-cmake-build/lib/libdbus-1.so.3(_dbus_abort+0xd) [0x7f0da731e2c9]
9: /home/xxx/src/dbus-cmake-build/lib/libdbus-1.so.3(_dbus_warn+0xf2) [0x7f0da730c292]
9: /home/xxx/src/dbus-cmake-build/bin/test-bus() [0x441fcf]
9: /home/xxx/src/dbus-cmake-build/bin/test-bus(bus_set_watched_dirs+0x1c) [0x442100]
9: /home/xxx/src/dbus-cmake-build/bin/test-bus() [0x416976]
9: /home/xxx/src/dbus-cmake-build/bin/test-bus(bus_context_new+0x7b6) [0x41713f]
9: /home/xxx/src/dbus-cmake-build/bin/test-bus(bus_context_new_test+0x107) [0x441886]
9: /home/xxx/src/dbus-cmake-build/bin/test-bus() [0x415235]
9: /home/xxx/src/dbus-cmake-build/bin/test-bus(bus_activation_service_reload_test+0xdd) [0x41551d]
9: /home/xxx/src/dbus-cmake-build/bin/test-bus(_dbus_test_main+0x252) [0x443155]
9: /home/xxx/src/dbus-cmake-build/bin/test-bus(main+0x3c) [0x41050a]
9: /lib64/libc.so.6(__libc_start_main+0xea) [0x7f0da685534a]
9: /home/xxx/src/dbus-cmake-build/bin/test-bus(_start+0x2a) [0x4103fa]
```
[error.log](/uploads/ecf91023840e2edd8a6205b989d6e512/error.log)
In the case of a temporary problem caused by too many open files, the message can be reproduced by a previous call to `sudo sh -c "echo 0 > /proc/sys/fs/inotify/max_user_instances"`, but this returns `-1` as the return value of `inotify_initx()` rather than the `0` value under discussion.
A different approach to reproduce is to run:
```
$ gdb --args bin/test-bus test/data
(gdb) b dir-watch-inotify.c:225
r
Breakpoint 1, _init_inotify (context=0x6824c0) at /home/ralf.habacker/src/dbus/bus/dir-watch-inotify.c:225
225 if (inotify_fd == -1)
(gdb) call (int)close(0)
$1 = 0
(gdb) c
dbus-daemon[9502]: Cannot initialize inotify
Breakpoint 1, _init_inotify (context=0x683880) at /home/ralf.habacker/src/dbus/bus/dir-watch-inotify.c:225
225 if (inotify_fd == -1)
(gdb) p inotify_fd
$3 = 0
```
The same behavior can be reproduced with `dbus-daemon`.
The problem with the message ` dbus-daemon[11508]: Cannot initialize inotify: Too many open files` also occurred after a package update of the Linux system (openSUSE Leap) that required a reboot, but the reboot had not yet been performed.https://gitlab.freedesktop.org/dbus/dbus/-/issues/360activation-service-reload in test-bus still fails with memory leaks on Windows2021-12-10T07:56:58ZRalf Habackeractivation-service-reload in test-bus still fails with memory leaks on WindowsRunning test-bus from a gcc cmake build for Windows from recent master with
```
set DBUS_TEST_TIMEOUT_MULTIPLIER=2
ctest -R test-bus$ --output-on-failure --timeout 180
```
fails on a local machine with the following error:
```
9: ok 8...Running test-bus from a gcc cmake build for Windows from recent master with
```
set DBUS_TEST_TIMEOUT_MULTIPLIER=2
ctest -R test-bus$ --output-on-failure --timeout 180
```
fails on a local machine with the following error:
```
9: ok 8 - activation-service-reload
9: # activation-service-reload test took 3 seconds
9: not ok 9 - activation-service-reload leaked 18 blocks
9: # Running test: unix-fds-passing
9: ok 10 # SKIP fd-passing not supported on this platform
9: ok 11 - unix-fds-passing
9: # unix-fds-passing test took 0 seconds
9: not ok 12 - unix-fds-passing leaked 18 blocks
9: # 2/12 tests failed
9: 1..12
1/1 Test #9: test-bus .........................***Failed 8.09 sec
```
The error happens regardless if running on a native host or with the help of wine.
The whole log file generated by this test has been appended [error.log](/uploads/0d25ec2ff46ee472664e93bad70ebd19/error.log)https://gitlab.freedesktop.org/dbus/dbus/-/issues/359test-dbus-daemon fails on CI with x86_64-w64-mingw32 builds2021-12-07T13:07:31ZRalf Habackertest-dbus-daemon fails on CI with x86_64-w64-mingw32 buildshttps://gitlab.freedesktop.org/dbus/dbus/-/jobs/16445975 show the following error:
```
14: # max perf: 10000 messages / 67.441041 seconds
14: # Time since timeout reset 000000000072eec0: 67.705 seconds
14: Bail out! Test timed out (GLib ...https://gitlab.freedesktop.org/dbus/dbus/-/jobs/16445975 show the following error:
```
14: # max perf: 10000 messages / 67.441041 seconds
14: # Time since timeout reset 000000000072eec0: 67.705 seconds
14: Bail out! Test timed out (GLib main loop timeout callback reached)
14/34 Test #14: test-dbus-daemon .................***Failed 81.88 sec
```https://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/357test-spawn-oom fails on Windows with memory checking enabled2021-12-06T13:02:32ZRalf Habackertest-spawn-oom fails on Windows with memory checking enabledRunning test-spawn-oom with memory checking enabled on Windows fails with the following errors:
```
dbus[32]: error: Not expecting error when launching segfaulting executable: org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to spawn ...Running test-spawn-oom with memory checking enabled on Windows fails with the following errors:
```
dbus[32]: error: Not expecting error when launching segfaulting executable: org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to spawn child
```
How to reproduce
----------------
In dbus/dbus-memory.c change the mentioned location below, then compile and run test-spawn-oom
```
dbus_bool_t
_dbus_decrement_fail_alloc_counter (void)
{
_dbus_initialize_malloc_debug ();
-#ifdef DBUS_WIN
+#ifdef _DBUS_WIN
```
Additional information
----------------------
With !223 the new error name has been introduced and needs to be added to this test as expected error.https://gitlab.freedesktop.org/dbus/dbus/-/issues/356When building with the CMake build system, a compiler warning configuration d...2021-12-10T14:16:40ZRalf HabackerWhen building with the CMake build system, a compiler warning configuration different from autotools is usedThis leads to hidden problems, such as those reported at https://gitlab.freedesktop.org/dbus/dbus/-/issues/355, and should be corrected.This leads to hidden problems, such as those reported at https://gitlab.freedesktop.org/dbus/dbus/-/issues/355, and should be corrected.https://gitlab.freedesktop.org/dbus/dbus/-/issues/355build error: cast between incompatible function types from 'FARPROC'2021-11-30T09:31:50ZRalf Habackerbuild error: cast between incompatible function types from 'FARPROC'While trying to reproduce the issue reported at #353 with a local docker build with autotools, it fails with
```
../../dbus/dbus-sysdeps-win.c: In function 'load_ex_ip_helper_procedures':
../../dbus/dbus-sysdeps-win.c:129:43: error: cast...While trying to reproduce the issue reported at #353 with a local docker build with autotools, it fails with
```
../../dbus/dbus-sysdeps-win.c: In function 'load_ex_ip_helper_procedures':
../../dbus/dbus-sysdeps-win.c:129:43: error: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'DWORD (*)(struct _MIB_TCPTABLE_OWNER_PID **, BOOL, void *, DWORD, DWORD)' {aka 'long unsigned int (*)(struct _MIB_TCPTABLE_OWNER_PID **, int, void *, long unsigned int, long unsigned int)'} [-Werror=cast-function-type]
lpfnAllocateAndGetTcpExTableFromStack = (ProcAllocateAndGetTcpExtTableFromStack)GetProcAddress (hModule, "AllocateAndGetTcpExTableFromStack");
^
```
I wonder why this does not occur on gitlab CI, since it uses the same docker image and packages.
The build steps performed, which are the same as those performed on Gitlab CI, are:
```
sudo docker pull debian:buster-slim
sudo docker run -v $PWD:/mnt -it debian:buster-slim /bin/bash
cd mnt
ci_buildsys=autotools ci_distro=debian ci_docker= ci_in_docker=yes ci_host=x86_64-w64-mingw32 ci_local_packages=yes ci_suite=buster ci_variant=debug ./tools/ci-install.sh
ci_buildsys=autotools ci_distro=debian ci_docker= ci_host=x86_64-w64-mingw32 ci_local_packages=yes ci_parallel=2 ci_suite=buster ci_test=yes ci_test_fatal=yes ci_variant=debug ci_runtime=static ./tools/ci-build.sh
```https://gitlab.freedesktop.org/dbus/dbus/-/issues/354If dbus-daemon fails to start up, Windows dbus-run-session does not detect it2021-11-25T15:55:43ZSimon McVittieIf dbus-daemon fails to start up, Windows dbus-run-session does not detect it## Steps to reproduce
Seen in for example https://gitlab.freedesktop.org/rhabacker/dbus/-/jobs/16153796 due to #353. Could be replicated by altering the dbus-daemon to `exit(1)` during startup (before the `--ready-event-handle` is signa...## Steps to reproduce
Seen in for example https://gitlab.freedesktop.org/rhabacker/dbus/-/jobs/16153796 due to #353. Could be replicated by altering the dbus-daemon to `exit(1)` during startup (before the `--ready-event-handle` is signalled), or by replacing it with an older dbus-daemon that does not implement the `--ready-event-handle` option.
## Expected result
If the dbus-daemon fails before the `--ready-event-handle` is signalled, then `dbus-run-session` should detect that, and exit unsuccessfully.
## Actual result
`dbus-run-session` does not exit until the 30 second timeout for `_dbus_win_event_wait()` has elapsed.https://gitlab.freedesktop.org/dbus/dbus/-/issues/353x86_64-w64-mingw32-cmake-debug CI sometimes fails with 'Library libexpat-1.dl...2021-12-01T12:17:24ZRalf Habackerx86_64-w64-mingw32-cmake-debug CI sometimes fails with 'Library libexpat-1.dll (..) not found'https://gitlab.freedesktop.org/rhabacker/dbus/-/jobs/16153796
> 29: 002b:err:module:import_dll Library libexpat-1.dll (which is needed by L"z:\\builds\\rhabacker\\dbus\\ci-build-debug-x86_64-w64-mingw32\\bin\\dbus-daemon.exe") not foundhttps://gitlab.freedesktop.org/rhabacker/dbus/-/jobs/16153796
> 29: 002b:err:module:import_dll Library libexpat-1.dll (which is needed by L"z:\\builds\\rhabacker\\dbus\\ci-build-debug-x86_64-w64-mingw32\\bin\\dbus-daemon.exe") not foundhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/352Clarify NULL vs. INVALID_HANDLE_VALUE in _dbus_win_event_free()2021-11-24T07:08:31ZSimon McVittieClarify NULL vs. INVALID_HANDLE_VALUE in _dbus_win_event_free()The following discussion from !195 should be addressed:
- [x] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/195#note_1167180):
> Perhaps
>
> ```suggestion:-0+0
> * @return TRU...The following discussion from !195 should be addressed:
- [x] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/195#note_1167180):
> Perhaps
>
> ```suggestion:-0+0
> * @return TRUE the event has been deleted successfully or the handle is one of the special sentinel values #NULL or #INVALID_HANDLE
> ```
>
> but I think that doesn't need to block this.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/3501.14 release2022-02-28T20:39:35ZMarkus Teich1.14 releaseAre there plans or an ETA for the 1.14 release yet?Are there plans or an ETA for the 1.14 release yet?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/347Wrong return type of GetConnectionCredentionals in DBus specification2021-11-09T12:46:04ZRalf HabackerWrong return type of GetConnectionCredentionals in DBus specificationAt https://dbus.freedesktop.org/doc/dbus-specification.html is documented
```
org.freedesktop.DBus.GetConnectionCredentials
as a method:
DICT<STRING,VARIANT> GetConnectionCredentials (in STRING bus_name).
```
The introspe...At https://dbus.freedesktop.org/doc/dbus-specification.html is documented
```
org.freedesktop.DBus.GetConnectionCredentials
as a method:
DICT<STRING,VARIANT> GetConnectionCredentials (in STRING bus_name).
```
The introspection data for this method contains
```
<method name="GetConnectionCredentials">
<arg direction="in" type="s"/>
<arg direction="out" type="a{sv}"/>
</method>
```
which defines it as an array of dict, which should make the correct documentation read:
```
org.freedesktop.DBus.GetConnectionCredentials
As a method:
ARRAY of DICT<STRING,VARIANT> GetConnectionCredentials (in STRING bus_name).
```https://gitlab.freedesktop.org/dbus/dbus/-/issues/346Cross compiling Qt6.2 with dbus/cmake build fails with 'Imported target "dbus...2021-11-18T15:12:14ZRalf HabackerCross compiling Qt6.2 with dbus/cmake build fails with 'Imported target "dbus-1" includes non-existent path'Qt6 has been switched to the cmake build system and compiling a mingw build with the dbus 1.13.18 development package generated by the cmake build system fails with the following error:
```
[ 34s] CMake Error in src/dbus/CMakeLists.txt...Qt6 has been switched to the cmake build system and compiling a mingw build with the dbus 1.13.18 development package generated by the cmake build system fails with the following error:
```
[ 34s] CMake Error in src/dbus/CMakeLists.txt:
[ 34s] Imported target "dbus-1" includes non-existent path
[ 34s]
[ 34s] "/usr/i686-w64-mingw32/sys-root/mingw//usr/i686-w64-mingw32/sys-root/mingw/lib/dbus-1.0/include"
[ 34s]
[ 34s] in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
[ 34s]
[ 34s] * The path was deleted, renamed, or moved to another location.
[ 34s]
[ 34s] * An install or uninstall procedure did not complete successfully.
[ 34s]
[ 34s] * The installation package was faulty and references files it does not
[ 34s] provide.
[ 34s]
[ 34s]
[ 34s]
```
[_log.txt](/uploads/6fca9ce70df4710743e55fac9dfed63d/_log.txt)
The reason for this is that on https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/cmake/DBus1Config.cmake.in#L29 two possibly absolute paths are linked.
It is recommended to leave the creation of the resulting paths to cmake. This can be realized with the `target_include_directories` command and the use of the `INSTALL_INTERFACE` as shown below
```
target_include_directories(dbus-1
INTERFACE
$<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}/dbus-1.0>
$<INSTALL_INTERFACE:${CMAKE_INSTALL_LIBDIR}/dbus-1.0/include>
)
```https://gitlab.freedesktop.org/dbus/dbus/-/issues/345Cross compiling Qt6.2 with dbus/autotools build fails with undefined IMPORTED...2021-11-18T15:52:49ZRalf HabackerCross compiling Qt6.2 with dbus/autotools build fails with undefined IMPORTED_IMPLIB target propertyQt6 has been switched to the cmake build system and compiling a mingw build with the dbus 1.12.20 development package generated by the autotools build system fails with the following error.
```
[ 31s] CMake Error in CMakeLists.txt:
[ ...Qt6 has been switched to the cmake build system and compiling a mingw build with the dbus 1.12.20 development package generated by the autotools build system fails with the following error.
```
[ 31s] CMake Error in CMakeLists.txt:
[ 31s] IMPORTED_IMPLIB not set for imported target "dbus-1" configuration
[ 31s] "RelWithDebInfo".
[ 31s]
```
[_log.txt](/uploads/4ad0651799753b053c93dd247560ccba/_log.txt)https://gitlab.freedesktop.org/dbus/dbus/-/issues/344Unauthorized access2021-09-29T10:11:33ZПавел РадуUnauthorized accessUndeclared function:
"The DBUS-Launch app is trying to access your Google Chrome browser credentials"
![Защита_паролей](/uploads/7b4806d1a4440ab1cc69dc92c1738242/Защита_паролей.PNG)
```
$ dbus-launch.exe --version
D-Bus Message Bus Lau...Undeclared function:
"The DBUS-Launch app is trying to access your Google Chrome browser credentials"
![Защита_паролей](/uploads/7b4806d1a4440ab1cc69dc92c1738242/Защита_паролей.PNG)
```
$ dbus-launch.exe --version
D-Bus Message Bus Launcher 1.10.22
Copyright (C) 2003 Red Hat, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```https://gitlab.freedesktop.org/dbus/dbus/-/issues/343Crash on reload if a connection has unknown user/group2023-08-21T13:49:33ZFabian VogtCrash on reload if a connection has unknown user/groupThis affects the system bus (mostly).
To reproduce:
1. Have a policy with group rules (provided by e.g. avahi)
2. Create a user account
3. As that user, create a connection to the system bus
4. Delete the user account forcibly, without ...This affects the system bus (mostly).
To reproduce:
1. Have a policy with group rules (provided by e.g. avahi)
2. Create a user account
3. As that user, create a connection to the system bus
4. Delete the user account forcibly, without killing the process.
`ps` then shows the plain uid instead of `testuser`.
5. Trigger a reload (`dbus-send --system --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig`)
6. Trigger another reload
As script:
```
useradd -m testuser
su testuser -c "dbus-monitor --system" &
userdel -f testuser
dbus-send --system --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig
dbus-send --system --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig
```
The result is a crash due to a nullptr deref:
```
bus_client_policy_unref
bus_connections_reload_policy
process_config_every_time
...
```
(With asserts enabled it would abort instead)
In many places, dbus assumes that every connection has a non-null policy,
but this can happen in `bus_connections_reload_policy`, which logs a message
in that case and returns an error. At that point the connection is in an invalid
state already though and the next `bus_connections_reload_policy` crashes due to
the null policy.
Found by openQA: https://openqa.opensuse.org/tests/1931448#step/wine/14
A previous step of that test creates various user accounts for testing
the display manager and deletes them again. The "dangling" process is caused
by geoclue2's agent in `/etc/xdg/autostart`.