dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2018-10-12T21:18:04Zhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/105dbus-daemon memory grows when a process behaves abusively2018-10-12T21:18:04ZBugzilla Migration Userdbus-daemon memory grows when a process behaves abusively## Submitted by Richard H.
Assigned to **Havoc Pennington**
**[Link to original bug (#81043)](https://bugs.freedesktop.org/show_bug.cgi?id=81043)**
## Description
Since I updated my Gentoo System to 1.8.4 (1.8.6 did also not help)...## Submitted by Richard H.
Assigned to **Havoc Pennington**
**[Link to original bug (#81043)](https://bugs.freedesktop.org/show_bug.cgi?id=81043)**
## Description
Since I updated my Gentoo System to 1.8.4 (1.8.6 did also not help) I have a strangely high memory consumption on my dbus-daemon process for my session. Just since starting to write this report it grew from 5% to 7% of my 4 GB of memory. This continues until the system starts stuttering due to heavy swapping (the highest I had was 53% of memory usage!)
I am using stable ebuilds, KDE with Akonadi but without Nepomuk running. Kontact usage seems to worsen the effect, but not using it does not stop the problem from happening.
The really strange thing is I have two almost identical systems and while system A runs fine on system B this bug is happening.
I can gladly support you with anything you need, I already tried using dbus-monitor. Nothing special to be seen there.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/104followup for CVE-2014-3532: messages with abusive recursion are silently dropped2018-10-12T21:18:00ZBugzilla Migration Userfollowup for CVE-2014-3532: messages with abusive recursion are silently dropped## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#80817)](https://bugs.freedesktop.org/show_bug.cgi?id=80817)**
## Description
+++ This bug was initially created as a clone of Bug #80163 ++...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#80817)](https://bugs.freedesktop.org/show_bug.cgi?id=80817)**
## Description
+++ This bug was initially created as a clone of Bug #80163 +++
> An original fd can be inserted in the ancillary data of a message.
> While that message is waiting in the socket queue of the other end,
> the fd of the other end can itself be inserted in the ancillary data
> of another message. [Recent Linux] considers that doing that
> recursively more than 4 times is abusive:
> #define MAX_RECURSION_LEVEL 4
...
> dbus-daemon has no way to check whether a
> received fd will trigger a ETOOMANYREFS when forwarding the D-Bus
> message to recipients. Moreover, the ability to forward the file
> descriptor changes asynchronously when other processes append messages
> on the fd's delivery queue.
Since 1.8.6, if sendmsg() fails with ETOOMANYREFS, dbus-daemon silently drops the message on the floor to avoid DoS.
It would be nice if it sent back an error reply, if the message was one that expects a reply (i.e. a method call). Alban started trying to implement that, but ran into considerable practical difficulties, and we agreed that the patch he proposed was too big for a security fix.
If someone wants to implement the rest of the ideal solution, i.e. sending back an error reply, now is the time.
Alternatively, logging the bad message to syslog might be a reasonable thing to do. This is, again, complicated by the fact that the error condition is hit in generic libdbus code, and we would only want dbus-daemon to syslog it.
Version: 1.5
### Depends on
* [Bug 80163](https://bugs.freedesktop.org/show_bug.cgi?id=80163)https://gitlab.freedesktop.org/dbus/dbus/-/issues/103reloading dbus-daemon configuration does not affect existing connections' ACLs2018-10-12T21:17:58ZBugzilla Migration Userreloading dbus-daemon configuration does not affect existing connections' ACLs## Submitted by Jussi Pakkanen
Assigned to **D-Bus Maintainers**
**[Link to original bug (#80186)](https://bugs.freedesktop.org/show_bug.cgi?id=80186)**
## Description
Start with a default install. Add a configuration file to allo...## Submitted by Jussi Pakkanen
Assigned to **D-Bus Maintainers**
**[Link to original bug (#80186)](https://bugs.freedesktop.org/show_bug.cgi?id=80186)**
## Description
Start with a default install. Add a configuration file to allow dbus monitoring as described here:
https://wiki.ubuntu.com/DebuggingDBus
Have dbus reload its configuration either by 'sudo reload dbus' or 'service messagebus reload'. After this the new setting should be in effect but it's not. To verify, do this:
dbus-monitor --system (as root)
Then as non-root use d-feet go to call e.g. NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager state(). This call should show up in the monitor dump but it does not. Only calls made by root processes show up.
To get monitoring working you need to reboot.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/102main loop implementations can't provide a function to wake up other threads2018-10-12T21:17:55ZBugzilla Migration Usermain loop implementations can't provide a function to wake up other threads## Submitted by nichel
Assigned to **D-Bus Maintainers**
**[Link to original bug (#78730)](https://bugs.freedesktop.org/show_bug.cgi?id=78730)**
## Description
usage of dbus core library:
1.application use core library directory(n...## Submitted by nichel
Assigned to **D-Bus Maintainers**
**[Link to original bug (#78730)](https://bugs.freedesktop.org/show_bug.cgi?id=78730)**
## Description
usage of dbus core library:
1.application use core library directory(no binding)and implement main loop myself.
2.2 threads, dbus main loop and application tasking thread.
issue: tasking thread call dbus_connection_send_with_reply_and_block(), it will drop connection lock before poll I/O fd. In this gap, is very likely to occur when there have a large data(read 2K once).
dbus main loop thread may read last block data from socket. and tasking thread will block until timeout(because nothing to read), it is a long time if use default value(25s).
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/101Checks for leaked file descriptors in do_exec in dbus/dbus-spawn.c and _dbus_...2020-09-23T18:49:56ZBugzilla Migration UserChecks for leaked file descriptors in do_exec in dbus/dbus-spawn.c and _dbus_close_all in dbus/dbus-sysdeps-unix.c miss files opened to a previously higher resource limit## Submitted by Steven Stewart-Gallus
Assigned to **D-Bus Maintainers**
**[Link to original bug (#77781)](https://bugs.freedesktop.org/show_bug.cgi?id=77781)**
## Description
I noticed this issue while I was stracing my processes ...## Submitted by Steven Stewart-Gallus
Assigned to **D-Bus Maintainers**
**[Link to original bug (#77781)](https://bugs.freedesktop.org/show_bug.cgi?id=77781)**
## Description
I noticed this issue while I was stracing my processes and it started
to bug me. Checks for leaked file descriptors in do_exec in
dbus/dbus-spawn.c and _dbus_close_all in dbus/dbus-sysdeps-unix.c miss
files opened to a previously higher resource limit. Some code that
illustrates having a file open that is higher than the resource limit
reported by sysconf is below:
#include <errno.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <sys/time.h>
#include <sys/resource.h>
int main() {
struct rlimit const limit = {
.rlim_cur = 0,
.rlim_max = 0
};
if (-1 == setrlimit(RLIMIT_NOFILE, &limit)) {
fprintf(stderr, "error: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
puts("Printing to standard output even though the resource limit is lowered past standard output's number!");
return EXIT_SUCCESS;
}
Luckily, on Linux _dbus_close_all tries to optimize using
/proc/self/fd which catches this exception. Unfortunately, the code
falls back to using the shitty and incorrect method of testing all
files below the sysconf resource limit when /proc/self/fd is not
available which may potentially be a security issue. Also, this
doesn't work if sysconf reports the file limit as unlimited. Stupidly,
the code just picks the random default of 1024 in the case where
sysconf reports an unlimited file limit.
The code in do_exec which reports leaked file descriptors does not use
/proc/self/fd at all and misses this corner case.
Unfortunately, a portable, correct and secure solution might need to
use platform specific tricks (such as /proc/self/fd) in every case and
never fallback to a compromise such as checking all files below a
resource limit.
As as side note, the /proc/self/fd method breaks use of Valgrind (see
issue https://bugs.kde.org/show_bug.cgi?id=331311).
As a side note, it may be smarter to move the file descriptor closing
inside of the various DBus binaries instead of into the library code
that spawns processes from them. That way, people who use those
binaries directly will get protection for free.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/100Avoid windows firewall complains about tcp usage2018-10-12T21:17:49ZBugzilla Migration UserAvoid windows firewall complains about tcp usage## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#76996)](https://bugs.freedesktop.org/show_bug.cgi?id=76996)**
## Description
Running dbus on windows often raises the firewall ...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#76996)](https://bugs.freedesktop.org/show_bug.cgi?id=76996)**
## Description
Running dbus on windows often raises the firewall to request permissions for opening tcp ports. If a user do not allow this, dbus will be nonfunctional.
A way to solve this issue may be to use named pipes on windows, for which several implementation examples are available:
1.1. server part using Overlapped I/O (http://en.wikipedia.org/wiki/Overlapped_I/O)
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365603%28v=vs.85%29.aspx
1.2. server part using threading
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365588%28v=vs.85%29.aspx
1.3. server using Completion routines (using overlapped i/o)
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365601%28v=vs.85%29.aspx
1.4. client
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365592%28v=vs.85%29.aspx
1.5.1 Qt named pipe server (QLocalServer)
http://qt-project.org/doc/qt-5.0/qtnetwork/qlocalserver.html
https://qt.gitorious.org/qt/qt/source/0315971ee951e9abe7f288564ddf2e81aeed1fd8:src/network/socket/qlocalserver.h
1.5.2 Qt named pipe client (QLocalSocket)
qt-project.org/doc/qt-5.0/qtnetwork/qlocalsocket.html
https://qt.gitorious.org/qt/qt/source/0315971ee951e9abe7f288564ddf2e81aeed1fd8:src/network/socket/qlocalclient.h
So in general it seems to doable.
In general looking at the example 1.5 I would say that at a minimum the following stuff is required:
2. client
2.1 structure to hold variables of the client instance
2.2 functions
- connect to a pipe
- disconnect from a pipe
- return connection state
- write data to pipe
- receive data from pipe
- check write state of pipe
- check read state of pipe
- error handling
3. server
3.1 structure to hold variables of the server instance
3.2 functions for the server part
- create a server instance
- destroy a server instance
- start listening
- stop listening
- return listening state
- handle new connections
- functions from the client part
4. open questions
4.1. At http://cgit.freedesktop.org/dbus/dbus/tree/README.win there has been stated that it would require a "bigger change to the dbus code", which lead to the question, what kind of changes are required to be able to make an implementation of named pipe support on windows ?
4.2. Which one of the available implementation would be the best choice to use in the dbus code ?
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/97would be nice if uid 0 was exempt from max_connections_per_user?2018-10-12T21:17:39ZBugzilla Migration Userwould be nice if uid 0 was exempt from max_connections_per_user?## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#74788)](https://bugs.freedesktop.org/show_bug.cgi?id=74788)**
## Description
Debian [bug 738947](https://bugs.freedesktop.org/show_bug.cgi?...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#74788)](https://bugs.freedesktop.org/show_bug.cgi?id=74788)**
## Description
Debian [bug 738947](https://bugs.freedesktop.org/show_bug.cgi?id=738947) concerns an installation of XDMCP in which 100 gdm greeters cannot all communicate with AccountsService:
Feb 4 11:53:21 bari gdm-welcome][15095]: AccountsService-WARNING: Failed to connect to the D-Bus daemon: GDBus.Error:org.freedesktop.DBus.Error.LimitsExceeded: The maximum number of active connections for UID 0 has been reached
Perhaps uid 0 should be allowed to have more than max_connections_per_user connections, since it's highly privileged anyway?
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/96dbus-launch: has non-obvious critical sections in which an X error would caus...2018-10-12T21:17:31ZBugzilla Migration Userdbus-launch: has non-obvious critical sections in which an X error would cause process leaks## Submitted by Роман Донченко
Assigned to **D-Bus Maintainers**
**[Link to original bug (#74698)](https://bugs.freedesktop.org/show_bug.cgi?id=74698)**
## Description
Created attachment 93633
Proposed patch
If an X error occurs ...## Submitted by Роман Донченко
Assigned to **D-Bus Maintainers**
**[Link to original bug (#74698)](https://bugs.freedesktop.org/show_bug.cgi?id=74698)**
## Description
Created attachment 93633
Proposed patch
If an X error occurs before the main dbus-launch process transmits the daemon's PID to the babysitter, x_io_error_handler will try to kill the bus with bus_pid_to_kill still set to -1. This will result in killing every process that dbus-launch can get its hands on.
I can easily reproduce this by running xvfb-run sh -c 'dbus-launch --autolaunch=11111111111111111111111111111111 &' a bunch of times.
The attached patch fixes this by making sure bus_pid_to_kill doesn't try to kill -1. It also fixes a related problem: if the X error happens after the fork but before the babysitter gets the bus PID, the bus won't be killed, because bus_pid_to_kill isn't initialized yet.
~~**Patch 93633**~~, "Proposed patch":
[dont-kill-minus-one.patch](/uploads/006e3b7320d4fb8bd62e213d319ae317/dont-kill-minus-one.patch)
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/95[PATCH] unixexec transport is supported only for the parent process2018-10-12T21:17:24ZBugzilla Migration User[PATCH] unixexec transport is supported only for the parent process## Submitted by Alex Kanavin
Assigned to **D-Bus Maintainers**
**[Link to original bug (#74454)](https://bugs.freedesktop.org/show_bug.cgi?id=74454)**
## Description
The patch that introduces the unixexec transport in [bug 35230](...## Submitted by Alex Kanavin
Assigned to **D-Bus Maintainers**
**[Link to original bug (#74454)](https://bugs.freedesktop.org/show_bug.cgi?id=74454)**
## Description
The patch that introduces the unixexec transport in [bug 35230](https://bugs.freedesktop.org/show_bug.cgi?id=35230) covers the parent-side of the unixexec transport, but it's missing the child side - making a dbus connection out of input and output file descriptors. Something like dbus_connection_open_using_fds() is needed.
I can write a patch for this, but I wanted to first ask for tips about how to integrate the functionality into the existing codebase without too many invasive changes all over the place.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/94init_session_address() should raise a DBusError instead of doing _dbus_warn()2018-10-12T21:17:20ZBugzilla Migration Userinit_session_address() should raise a DBusError instead of doing _dbus_warn()## Submitted by Guy Harris
Assigned to **D-Bus Maintainers**
**[Link to original bug (#74029)](https://bugs.freedesktop.org/show_bug.cgi?id=74029)**
## Description
[Bug 6964](https://bugs.freedesktop.org/show_bug.cgi?id=6964) agai...## Submitted by Guy Harris
Assigned to **D-Bus Maintainers**
**[Link to original bug (#74029)](https://bugs.freedesktop.org/show_bug.cgi?id=74029)**
## Description
[Bug 6964](https://bugs.freedesktop.org/show_bug.cgi?id=6964) against Wireshark:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9694
is due to:
the person using the MacPorts version of Wireshark, which uses the MacPorts version of libpcap;
the MacPorts version of libpcap being a recent version, with support for capturing D-Bus traffic, and built with D-Bus support;
libpcap refusing to provide, in its API to get a list of devices on which it can capture, devices that can't be opened, and testing that by trying to open them;
calls to try to open the "dbus-system" device calling dbus_bus_get with DBUS_BUS_SYSTEM as the first argument;
the system perhaps not being configured properly;
Wireshark running its dumpcap program to get a list of devices on which it can capture (so that, if special privileges are needed to open devices on which to capture traffic, only dumpcap needs them, not Wireshark in its entirety), with the standard output and error from dumpcap piped to it, and assuming that only serious "I can't function" errors will show up on the standard error, in a standard format determined by dumpcap (failure to open a device is *not* such an error, under any circumstances, not even failure due to org.freedesktop.dbus-session.plist not having been loaded on OS X);
init_session_address() calling _dbus_warn() if _dbus_lookup_session_address() sets "supported" to TRUE and returns FALSE, causing exactly such an error to go to the standard error.
I didn't find any obvious way to suppress the error message, so I'm probably just going to forcibly disable D-Bus support on OS X in libpcap, pending some way to suppress it.
It's probably best if library routines not write to the standard output or error except in calls whose purpose is to write to the standard output or error. (And, yes, I know libpcap does that in some places; I'll fix that soon.)https://gitlab.freedesktop.org/dbus/dbus/-/issues/93dbus install location issue2018-10-12T21:17:09ZBugzilla Migration Userdbus install location issue## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#73636)](https://bugs.freedesktop.org/show_bug.cgi?id=73636)**
## Description
While comparing install locations of various distr...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#73636)](https://bugs.freedesktop.org/show_bug.cgi?id=73636)**
## Description
While comparing install locations of various distributions where dbus is build for I recognized some differences:
source-build (autotools)
config: /etc/dbus-1
doc: /usr/share/doc/dbus
include: /usr/include/dbus-1/dbus
services: /share/dbus-1/services
/share/dbus-1/system-services
source-build (cmake)
config: /etc/dbus-1
doc: /usr/share/doc/dbus
include: /usr/include/dbus/dbus
services: n.a.
opensuse (autotools):
config: /etc/dbus-1
doc: /usr/share/doc/packages/dbus-1
include: /usr/include/dbus-1.0/dbus
/usr/lib64/dbus-1.0/include/dbus
services: /lib/dbus-1/system-services
/lib/systemd/system
mingw32-dbus (autotools cross build)
config: `<mingw-root>`/etc/dbus-1
doc: `<mingw-root>`/share/doc/dbus
include: `<mingw-root>`/include/dbus-1/dbus
`<mingw-root>`/lib/dbus-1.0/include/dbus
services: /share/dbus-1/services
mingw32-dbus (cmake cross build)
config: `<mingw-root>`/etc/dbus-1
doc: `<mingw-root>`/share/doc/dbus
include: `<mingw-root>`/include/dbus
services: n.a.
windows (cmake)
config: `<install-root>`/etc/dbus-1
doc: `<install-root>`/share/doc/dbus
include: `<install-root>`/include/dbus
services: n.a.
Other distros has not been checked because of missing access.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/92Mac OS X build (clang) broken due to -Wcast-align error2018-10-12T21:17:07ZBugzilla Migration UserMac OS X build (clang) broken due to -Wcast-align error## Submitted by Roland
Assigned to **D-Bus Maintainers**
**[Link to original bug (#73279)](https://bugs.freedesktop.org/show_bug.cgi?id=73279)**
## Description
Created attachment 91483
build log
I'm trying to build dbus from git ...## Submitted by Roland
Assigned to **D-Bus Maintainers**
**[Link to original bug (#73279)](https://bugs.freedesktop.org/show_bug.cgi?id=73279)**
## Description
Created attachment 91483
build log
I'm trying to build dbus from git (branch master).
My toolchain is:
gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
Unfortunately I get several warnings from the type:
error: cast from 'unsigned char *' to 'dbus_uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Werror,-Wcast-align]
Attached is the build log.
As a workaround I removed the -Wcast-align flag in Makefile and the build went fine. But I guess its worth to fix that warnings.
**Attachment 91483**, "build log":
[build.log](/uploads/23d97d88f2f8981cbc8ae330e09d813e/build.log)
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/91bus-test dispatch test fail on FreeBSD 9.12018-10-12T21:17:00ZBugzilla Migration Userbus-test dispatch test fail on FreeBSD 9.1## Submitted by Chengwei Yang `@chengwei`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#72251)](https://bugs.freedesktop.org/show_bug.cgi?id=72251)**
## Description
After applied patch to fix #bug72213
./bus/bus-tes...## Submitted by Chengwei Yang `@chengwei`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#72251)](https://bugs.freedesktop.org/show_bug.cgi?id=72251)**
## Description
After applied patch to fix #bug72213
./bus/bus-test test/data dispatch
still fails like below
Activating service name='org.freedesktop.DBus.TestSuiteEchoService'
Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService'
Activating service name='org.freedesktop.DBus.TestSuiteEchoService'
Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService'
Activating service name='org.freedesktop.DBus.TestSuiteEchoService'
Failed to activate service 'org.freedesktop.DBus.TestSuiteEchoService': timed out
Did not expect error org.freedesktop.DBus.Error.TimedOut
existent_service_no_auto_start failed during oom
File "dispatch.c" line 4445 process 91803 should not have been reached: test failed
D-Bus not compiled with backtrace support so unable to print a backtrace
Abort trap (core dumped)
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/90dbus-launch will refuse start a dbus-daemon though the previous started was t...2018-10-12T21:16:56ZBugzilla Migration Userdbus-launch will refuse start a dbus-daemon though the previous started was terminated## Submitted by Chengwei Yang `@chengwei`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#69877)](https://bugs.freedesktop.org/show_bug.cgi?id=69877)**
## Description
dbus-launch which used to start a dbus-daemon mainl...## Submitted by Chengwei Yang `@chengwei`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#69877)](https://bugs.freedesktop.org/show_bug.cgi?id=69877)**
## Description
dbus-launch which used to start a dbus-daemon mainly used in autolaunch:, in this situation, dbus-launch will save related infomations into X window system, for example, the bus daemon address. And will decide whether a dbus-daemon is already running according to if an address can get from X window system.
So here comes the problem: if the previously started dbus-daemon was terminated but the dbus-launch is still running, then the next connection request will always fail because dbus-launch refused to start a dbus-daemon.
This behaviour somehow like #bug25841, I'm not quite sure.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/89Running dbus as windows service2022-03-25T16:02:00ZBugzilla Migration UserRunning dbus as windows service## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#68741)](https://bugs.freedesktop.org/show_bug.cgi?id=68741)**
## Description
Created attachment 84892
Add dbus service helper a...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#68741)](https://bugs.freedesktop.org/show_bug.cgi?id=68741)**
## Description
Created attachment 84892
Add dbus service helper application
The append patches implements a basic implementation for running dbus as windows service, which has been requested.
**Patch 84892**, "Add dbus service helper application":
[0001-Add-windows-service-handler.patch](/uploads/5a0962c3d5e267fea527e3c2e3042106/0001-Add-windows-service-handler.patch)
Version: 1.5
### Depends on
dbus should definitely not be used across privilege boundaries on Windows until it is in a security-supportable state, which means issues like #45 need to be fixed first.https://gitlab.freedesktop.org/dbus/dbus/-/issues/87update document about listenable address in dbus spec and dbus-damon manpage2018-10-12T21:16:28ZBugzilla Migration Userupdate document about listenable address in dbus spec and dbus-damon manpage## Submitted by Chengwei Yang `@chengwei`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#66915)](https://bugs.freedesktop.org/show_bug.cgi?id=66915)**
## Description
Copied from http://lists.freedesktop.org/archives/d...## Submitted by Chengwei Yang `@chengwei`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#66915)](https://bugs.freedesktop.org/show_bug.cgi?id=66915)**
## Description
Copied from http://lists.freedesktop.org/archives/dbus/2013-July/015718.html
Hi List,
I just found that there is an inconsistent issue of message bus server
address.
There are two ways to specify the message bus server addresses, from
command line option "--address" or configure "`<listen>`" element in bus
config file.
However, they behave a little different as below.
Quote from DBus Spec
[FIXME clarify if attempting to connect to each is a requirement or
just a suggestion] When connecting to a server, multiple server
addresses can be separated by a semi-colon. The library will then try
to connect to the first address and if that fails, it'll try to connect
to the next one specified, and so forth. For example
unix:path=/tmp/dbus-test;unix:path=/tmp/dbus-test2
Quote from dbus-daemon(1)
· `<listen>`
Add an address that the bus should listen on. The address
is in the standard D-Bus format that contains a transport
name plus possible parameters/options.
Example: `<listen>`unix:path=/tmp/foo`</listen>`
Example: `<listen>`tcp:host=localhost,port=1234`</listen>`
If there are multiple `<listen>` elements, then the bus listens
on multiple addresses. The bus will pass its address to
started services or other interested parties with
the last address given in `<listen>` first. That
is, apps will try to connect to the last `<listen>`
address first.
So seems that we're saying: there is no way to listen on multiple
address if you're using '--address' option, if that is your case,
configure '`<listen>`' in config file instead.
Should this to be fixed?
If so, how? Align '`<listen>`(man page)' with '--address(dbus spec)' or
the reverse?
--
Thanks,
Chengwei
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/86[PATCH] launch-helper: fix error code parsing2019-05-13T15:10:20ZBugzilla Migration User[PATCH] launch-helper: fix error code parsing## Submitted by Chengwei Yang `@chengwei`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#66728)](https://bugs.freedesktop.org/show_bug.cgi?id=66728)**
## Description
If `<servicehelper>` used to activate a system serv...## Submitted by Chengwei Yang `@chengwei`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#66728)](https://bugs.freedesktop.org/show_bug.cgi?id=66728)**
## Description
If `<servicehelper>` used to activate a system service, it will do some user check, however, if `<user>` doesn't specified in system.conf, the user will be "" because it always make sure parser->user initialized as a DBusString, I think the idea behind is to avoid OOM later.
However, when the above situation occurrs, the error is a little confusing.
"
Error org.freedesktop.DBus.Error.Spawn.PermissionsInvalid: The permission of the setuid helper is not correct
"
I think it's better to compalin like below.
"
Error org.freedesktop.DBus.Error.Spawn.ConfigInvalid: Could not get user from config file
"
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/85[PATCH] two small fixes for dbus hash: remove dead code, fix comments and rem...2018-10-12T21:16:11ZBugzilla Migration User[PATCH] two small fixes for dbus hash: remove dead code, fix comments and remove redundant AND operation## Submitted by Chengwei Yang `@chengwei`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#66576)](https://bugs.freedesktop.org/show_bug.cgi?id=66576)**
## Description
Version: 1.5## Submitted by Chengwei Yang `@chengwei`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#66576)](https://bugs.freedesktop.org/show_bug.cgi?id=66576)**
## Description
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/84change spec so unknown match rule keys are ignored2018-10-15T14:29:57ZBugzilla Migration Userchange spec so unknown match rule keys are ignored## Submitted by Chengwei Yang `@chengwei`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#66114)](https://bugs.freedesktop.org/show_bug.cgi?id=66114)**
## Description
unknown key in match rule just like unknown field i...## Submitted by Chengwei Yang `@chengwei`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#66114)](https://bugs.freedesktop.org/show_bug.cgi?id=66114)**
## Description
unknown key in match rule just like unknown field in message header, to avoid compatibility issue if new key/field introduced in future, the dbus specification says "Again, if an implementation sees a header field code that it does not expect, it must ignore that field, as it will be part of a new (but compatible) version of this specification."
I think this is applicable to unknown key in match rule situation.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/83Callback for dbus_connection_send_with_reply never is called if service answe...2018-10-12T21:16:01ZBugzilla Migration UserCallback for dbus_connection_send_with_reply never is called if service answers incorrectly## Submitted by Philip Rauwolf
Assigned to **D-Bus Maintainers**
**[Link to original bug (#65134)](https://bugs.freedesktop.org/show_bug.cgi?id=65134)**
## Description
Created attachment 79978
Possible fix for dbus-1.6.11
If the ...## Submitted by Philip Rauwolf
Assigned to **D-Bus Maintainers**
**[Link to original bug (#65134)](https://bugs.freedesktop.org/show_bug.cgi?id=65134)**
## Description
Created attachment 79978
Possible fix for dbus-1.6.11
If the dbus iteration is done via "dbus_connection_read_write_dispatch",
and any asynchronous method call message with timeout was sent (via "dbus_connection_send_with_reply"), but the target service does not answer properly (i.e. by returning "DBUS_HANDLER_RESULT_HANDLED" despite not sending a reply), the asynchronous call does NEVER return, not even when the timeout expires. Reason is that during the iteration those timeouts are never checked again.
We tested this for dbus 1.4.16 and for 1.6.11, both builds showed the same behavior.
The patch appended to this bug report is a possible fix for this bug, though it is not the optimal solution. Optimal in our opinion would be the extension of the DBusPendingCall by a member variable that remembers the time the call was issued, and to check the current time against this value plus the timeout interval, instead of relying on the timeout appended to a DBusPendingCall firing only once and using the "interval" member variable of this timeout object for the very same purpose.
The following code reliably reproduces the error (the test uses the google test framework, https://code.google.com/p/googletest/):
#include <gtest/gtest.h>
#include <dbus/dbus.h>
class LibdbusTest: public ::testing::Test {
protected:
virtual void SetUp() {
}
virtual void TearDown() {
}
};
::DBusHandlerResult onLibdbusObjectPathMessageThunk(::DBusConnection* libdbusConnection,
::DBusMessage* libdbusMessage,
void* userData) {
return ::DBusHandlerResult::DBUS_HANDLER_RESULT_HANDLED;
}
DBusObjectPathVTable libdbusObjectPathVTable = {
NULL,
&onLibdbusObjectPathMessageThunk
};
::DBusConnection* createConnection() {
const ::DBusBusType libdbusType = ::DBusBusType::DBUS_BUS_SESSION;
::DBusConnection* libdbusConnection = dbus_bus_get_private(libdbusType, NULL);
dbus_connection_ref(libdbusConnection);
dbus_connection_set_exit_on_disconnect(libdbusConnection, false);
return libdbusConnection;
}
static void onLibdbusPendingCallNotifyThunk(::DBusPendingCall* libdbusPendingCall, void *userData) {
replyArrived = true;
::DBusMessage* libdbusMessage = dbus_pending_call_steal_reply(libdbusPendingCall);
ASSERT_TRUE(libdbusMessage);
dbus_pending_call_unref(libdbusPendingCall);
}
TEST_F(LibdbusTest, NonreplyingLibdbusConnectionsAreHandled) {
const char* problemServiceName = "problem.service";
replyArrived = false;
bool running = true;
dbus_threads_init_default();
::DBusConnection* serviceConnection = createConnection();
::DBusConnection* clientConnection = createConnection();
dbus_bus_request_name(serviceConnection,
problemServiceName,
DBUS_NAME_FLAG_DO_NOT_QUEUE,
NULL);
dbus_connection_try_register_object_path(serviceConnection,
"/",
&libdbusObjectPathVTable,
NULL,
NULL);
std::thread([&, this] {
while(running) {
dbus_connection_read_write_dispatch(serviceConnection, 10);
}
}).detach();
usleep(100000);
::DBusMessage* message = dbus_message_new_method_call(problemServiceName, "/", NULL, "someMethod");
::DBusPendingCall* libdbusPendingCall;
dbus_connection_send_with_reply(
clientConnection,
message,
&libdbusPendingCall,
3000);
dbus_pending_call_set_notify(
libdbusPendingCall,
onLibdbusPendingCallNotifyThunk,
NULL,
NULL);
//100*50 = 5000 (ms) ==> 3 seconds timeout pending call *should* have arrived by now.
for (unsigned int i = 0; i < 100 && (!replyArrived); i++) {
dbus_connection_read_write_dispatch(clientConnection, 50);
}
EXPECT_TRUE(replyArrived);
running = false;
usleep(100000);
dbus_connection_close(serviceConnection);
dbus_connection_unref(serviceConnection);
dbus_connection_close(clientConnection);
dbus_connection_unref(clientConnection);
}
**Patch 79978**, "Possible fix for dbus-1.6.11":
[dbus-v1.6.11-DBusConnection-fix-asynchronous-call-timeouts.patch](/uploads/1c64bba1e1c08dd1de61f05eede11a69/dbus-v1.6.11-DBusConnection-fix-asynchronous-call-timeouts.patch)
Version: 1.5