dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2022-10-11T11:45:12Zhttps://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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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 Manjaro