dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2018-10-15T14:51:02Zhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/175failed RemoveMatch sends error after return (protocol violation)2018-10-15T14:51:02ZBugzilla Migration Userfailed RemoveMatch sends error after return (protocol violation)## Submitted by Matthijs van Duin
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101161)](https://bugs.freedesktop.org/show_bug.cgi?id=101161)**
## Description
When RemoveMatch fails, it sends a org.freedesktop.DBus.E...## Submitted by Matthijs van Duin
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101161)](https://bugs.freedesktop.org/show_bug.cgi?id=101161)**
## Description
When RemoveMatch fails, it sends a org.freedesktop.DBus.Error.MatchRuleNotFound error after first sending a normal method return. As a result, clients are unable to determine that RemoveMatch failed.
Example:
~$ dbus-send --dest=org.freedesktop.DBus --print-reply / org.freedesktop.DBus.RemoveMatch string:""
method return time=1495590462.736592 sender=org.freedesktop.DBus -> destination=:1.255 serial=3 reply_serial=2
Monitoring the bus while performing the above reveals that an error reply is also sent, but the client of course discards it.
dbus 1.10.18 and 1.11.12 tested
Version: 1.10https://gitlab.freedesktop.org/dbus/dbus/-/issues/173libdbus calls malloc() after fork(), causing clients to deadlock2020-09-21T19:56:11ZBugzilla Migration Userlibdbus calls malloc() after fork(), causing clients to deadlock## Submitted by Primiano Tucci
Assigned to **D-Bus Maintainers**
**[Link to original bug (#100843)](https://bugs.freedesktop.org/show_bug.cgi?id=100843)**
## Description
TL;DR
dbus-autolaunch causes random hangs, if the hosting pr...## Submitted by Primiano Tucci
Assigned to **D-Bus Maintainers**
**[Link to original bug (#100843)](https://bugs.freedesktop.org/show_bug.cgi?id=100843)**
## Description
TL;DR
dbus-autolaunch causes random hangs, if the hosting process uses an allocator which doesn't have multithreads+fork protections.
This is because a malloc() happens after fork() in _dbus_close_all() via opendir().
Related chromium bugs:
https://crbug.com/695643
https://crbug.com/715658
We had a number of bug reports in chromium where chrome just hangs during startup on Linux.
I narrowed down the cause to libdbus.
The scenario is the following:
- somebody starts chrome in a session that doesn't have a dbus running. This is very common in test harness that run via xvfb. doing that triggers dbus-autolaunch.
- The following happens in the caller process (chrome, in our case):
_dbus_transport_open()
_dbus_transport_open_autolaunch()
_dbus_transport_new_for_autolaunch()
_dbus_get_autolaunch_address()
_read_subprocess_line_argv()
fork()
wait() (on the pipe)
- While in the child process:
fork()
_dbus_close_all()
opendir("/proc/self/fd")
malloc()
Calling malloc in a fork()ed process is bad: if the allocator has no atfork handler, doing that will cause random hangs. More details in crbug.com/695643 .
All this seems to come from an optimization in _dbus_close_all() for Linux [1]. You folks seem to have already a fallback there that is doing a:
maxfds = sysconf (_SC_OPEN_MAX);
for (i = 3; i < maxfds; i++)
close (i);
Which is good and harmless.
The problem instead is when you opendir(/proc/self/fd). Sadly opendir() implies a malloc.
Doing a fork()+malloc() is just asking for troubles. Given that libdbus is a library and not an hemertic executable, IMHO it isn't sensible to expect that hosting process has an allocator with a post-fork handler which handles this corner case.
Can you just always use the fallback and get rid of that /proc/self/fd optimization ? Or achieve that with some other way that doesn't involve a malloc after fork?
For the chrome specific bug we'll be looking into disabling dbus autolunch and reducing our dependencies to that, but in general this feels to me could impact and surprise quite lot of other dbus users (fun fact, the root bug in chrome was caused by somebody calling gconf_client_get_bool).
Regards,
Primiano
[1] https://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-sysdeps-unix.c?id=d42d167cc3ba0d20aa891a75aa1cd80ec5f490f1#n4368
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/172Specify the drivers error code in the dbus specification2018-11-07T16:57:10ZBugzilla Migration UserSpecify the drivers error code in the dbus specification## Submitted by Tom Gundersen `@tomegun`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#100795)](https://bugs.freedesktop.org/show_bug.cgi?id=100795)**
## Description
Created attachment 131047
document all driver call...## Submitted by Tom Gundersen `@tomegun`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#100795)](https://bugs.freedesktop.org/show_bug.cgi?id=100795)**
## Description
Created attachment 131047
document all driver calls in the same section
These patches document some well-known error codes returned by the dbus daemon in response to calls to the driver. Error codes returned as a result of internal errors or a misconfigured daemon are not documented.
~~**Patch 131047**~~, "document all driver calls in the same section":
[0001-docs-document-all-of-the-org.freedesktop.DBus-method.patch](/uploads/29d1aa3b0d07bfb1bd18a2929803662d/0001-docs-document-all-of-the-org.freedesktop.DBus-method.patch)https://gitlab.freedesktop.org/dbus/dbus/-/issues/171Containers1: Add restricted, identifiable bus servers for use in containers2023-09-07T21:31:55ZBugzilla Migration UserContainers1: Add restricted, identifiable bus servers for use in containersThis issue is a metabug for the general concept of the Containers interface.
Older comments have been copied from Bugzilla by an automated process, and are likely to be more readable on the [original bug (#100344)](https://bugs.freedesk...This issue is a metabug for the general concept of the Containers interface.
Older comments have been copied from Bugzilla by an automated process, and are likely to be more readable on the [original bug (#100344)](https://bugs.freedesktop.org/show_bug.cgi?id=100344).
## Description
In app-container projects like Flatpak, Snap, Firejail and AppImage, there's a need for a confined/contained/sandboxed app to be able to reach services on the normal session and system buses. However, unrestricted access to those buses is scary (and in particular, the session bus is not considered to be a security boundary, so various services there have APIs that are arbitrary code execution).
The motivating use cases right now are:
* Portals: Portal authors need to be able to identify whether the
container is being contacted by an uncontained process (running with
the user's full privileges), or whether it is being contacted by a
contained process (in a container created by Flatpak or Snap).
* dconf: Currently, a contained app either has full read/write access
to dconf, or no access. It should have read/write access to its own
subtree of dconf configuration space, and no access to the rest.
At the moment, Flatpak runs a D-Bus proxy (xdg-dbus-proxy) for each app instance that has access to D-Bus, connects to the appropriate bus on the app's behalf, and passes messages through. That proxy is in a container similar to the actual app instance, but not actually the same container; it is trusted to not pass messages through that it shouldn't pass through. Portals identify the contained app by reading the proxy's `/proc/$pid/root/.flatpak-info`, which is Flatpak-specific. Reading through `/proc/$pid/root` like that also has an inherent race condition: if the process exits at exactly the wrong time, and the process ID space (which is only 15 bits) wraps around such that an uncontained or differently-contained process gets the same process ID allocated for it, then the portal would see the differently-contained process's identity instead. Flatpak is effectively trusting the proxy not to exit at a sufficiently inconvenient time.
Meanwhile, Snap does its sandboxing with AppArmor, on kernels where it is enabled both at compile-time (Ubuntu, openSUSE, Debian, Debian derivatives like Tails) and at runtime (Ubuntu, openSUSE and Tails, but not Debian by default). Ubuntu's kernel has extra AppArmor features that haven't yet gone upstream, some of which provide reliable app identification via LSM labels, which `dbus-daemon` can learn by querying its `AF_UNIX` socket; however, other kernels like the ones in openSUSE and Debian don't have those. The access-control (AppArmor *mediation*) is implemented in upstream dbus-daemon, but again doesn't work portably: the kernel needs to have the necessary non-upstream features available, and they need to have been enabled at compile time and at runtime. The AppArmor rules are also somewhat inflexible: they are fixed at load time, and do not have access to a lot of useful domain-specific information. They're enough for rules like "allow talking to portals A, B and C", but not really enough for dconf's needs.
@smcv discussed this with Allison Lortie and Alexander Larsson at the GTK Hackfest a long time ago, and we came up with a plan for obsoleting the Flatpak proxy by enhancing dbus-daemon.
As of 2023, this work did not reach a point where it could genuinely obsolete xdg-dbus-proxy. There has been a lot of design bikeshedding, and as of late 2021 when we were starting to think about freezing dbus 1.14.x, @smcv was not confident that it had the required multi-year stability.
Migration from freedesktop.org Bugzilla to freedesktop.org Gitlab has not helped the readability of this issue either.
In the short term (for 1.16.0) @smcv is hoping to provide a subset of this interface that has the "secure identification" layer, but still relies on Flatpak's xdg-dbus-proxy for the filtering layer, and does not have advanced or elaborate functionality.
## Dependencies for basic functionality
See #477.
## Dependencies if we want to obsolete xdg-dbus-proxy
Fully obsoleting xdg-dbus-proxy requires message filtering/policy: #185, originally [fdo#101902](https://bugs.freedesktop.org/show_bug.cgi?id=101902). This is not going to be quick to implement, and is out of scope for #477.
## Other nice-to-haves
* #186
* #188
* #189
* #206
## Other related issues
* [Original bug (fdo#100344)](https://bugs.freedesktop.org/show_bug.cgi?id=100344)https://gitlab.freedesktop.org/dbus/dbus/-/issues/170don't record activatable service entries in memory if name is invalid2018-10-15T13:43:04ZBugzilla Migration Userdon't record activatable service entries in memory if name is invalid## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99877)](https://bugs.freedesktop.org/show_bug.cgi?id=99877)**
## Description
If the search path contains an activatable service whose Name ...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99877)](https://bugs.freedesktop.org/show_bug.cgi?id=99877)**
## Description
If the search path contains an activatable service whose Name is not a syntactically valid well-known name, in particular names longer than 255 characters, then we should not load it.
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/169prefer recommended service naming on collision2020-03-13T10:55:55ZBugzilla Migration Userprefer recommended service naming on collision## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99876)](https://bugs.freedesktop.org/show_bug.cgi?id=99876)**
## Description
As noted in Bug #99873, many session services are named in a n...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99876)](https://bugs.freedesktop.org/show_bug.cgi?id=99876)**
## Description
As noted in Bug #99873, many session services are named in a non-canonical way.
One thing we can do to make this better is: if a directory in the search path contains a canonically-named service and a non-canonically-named service for the same well-known bus name, we should prefer the canonically-named one, instead of just taking whichever comes first in readdir() order.
Version: git master
### Depends on
* [Bug 99825](https://bugs.freedesktop.org/show_bug.cgi?id=99825)https://gitlab.freedesktop.org/dbus/dbus/-/issues/168make recommended system service naming mandatory2018-10-15T13:43:32ZBugzilla Migration Usermake recommended system service naming mandatory## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99874)](https://bugs.freedesktop.org/show_bug.cgi?id=99874)**
## Description
dbus-daemon currently has the following unintended behaviour f...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99874)](https://bugs.freedesktop.org/show_bug.cgi?id=99874)**
## Description
dbus-daemon currently has the following unintended behaviour for system services whose filenames are not the canonical name (the well-known name + ".service"):
* Parse whichever service came first in readdir() order (might be the canonical name, or any other name[1]).
* Silently ignore any others.
* If the one that got parsed has a SystemdService set, use that for activation.
* If the one that got parsed does not have a SystemdService set, use the setuid helper for activation - but the setuid helper will load the file that has the canonical name instead (!), or if there is none, activation will fail.
When Bug #99825 lands, [1] will at least become a warning.
For the development branch, I think we should consider tightening this to: if the name is not canonical, just fail to load it. After Bug #99825, this would be easy to do.
Version: git master
### Depends on
* [Bug 99825](https://bugs.freedesktop.org/show_bug.cgi?id=99825)https://gitlab.freedesktop.org/dbus/dbus/-/issues/167consider warning when session services have the wrong name2018-10-15T13:43:42ZBugzilla Migration Userconsider warning when session services have the wrong name## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99873)](https://bugs.freedesktop.org/show_bug.cgi?id=99873)**
## Description
Best practice for D-Bus session services is to define the serv...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99873)](https://bugs.freedesktop.org/show_bug.cgi?id=99873)**
## Description
Best practice for D-Bus session services is to define the service com.example.Foo in a file named com.example.Foo.service. This ensures that it is unambiguous which one is started: the one that is first in directory search order (this is not 100% reliable until one of the patches from Bug #99825 lands).
dbus-daemon could warn if a service is encountered that does not satisfy that constraint. However, this is currently wrong in a lot of software <https://lintian.debian.org/tags/dbus-session-service-wrong-name.html> so we should probably get some of those fixed first.
The cost of obeying that constraint is that if two software packages are deliberately providing implementations of the same well-known bus name, they will have file conflicts. However, this does not seem a whole lot worse than the current situation, where whichever one appears first in readdir() order is chosen, which I'm fairly sure is not what the software author intended.
Version: git master
### Depends on
* [Bug 99825](https://bugs.freedesktop.org/show_bug.cgi?id=99825)https://gitlab.freedesktop.org/dbus/dbus/-/issues/166Different parameter usage design of dbus-monitor2018-10-15T14:52:43ZBugzilla Migration UserDifferent parameter usage design of dbus-monitor## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99809)](https://bugs.freedesktop.org/show_bug.cgi?id=99809)**
## Description
Most dbus related command line tools provides comm...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99809)](https://bugs.freedesktop.org/show_bug.cgi?id=99809)**
## Description
Most dbus related command line tools provides command line parameter with additional args in the form --`<key>`=`<value>`, which dbus-monitor uses --`<key>` `<value>`
e.g see --address parameter in the following help pages:
dbus-daemon [--version] [--session] [--system] [--config-file=FILE] [--print-address[=DESCRIPTOR]] [--print-pid[=DESCRIPTOR]] [--introspect] [--address=ADDRESS] [--nopidfile] [--nofork] [--fork] [--systemd-activation]
versus
Usage: dbus-monitor [--system | --session | --address ADDRESS] [--monitor | --profile ] [watch expressions]
Version: 1.10https://gitlab.freedesktop.org/dbus/dbus/-/issues/165Mismatch in documentation of dbus-send parameter --bus, --peer and --address2018-10-15T13:43:54ZBugzilla Migration UserMismatch in documentation of dbus-send parameter --bus, --peer and --address## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99808)](https://bugs.freedesktop.org/show_bug.cgi?id=99808)**
## Description
dbus-send command line help prints
Usage: dbus-s...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99808)](https://bugs.freedesktop.org/show_bug.cgi?id=99808)**
## Description
dbus-send command line help prints
Usage: dbus-send [--help] [--system | --session | --bus=ADDRESS | --peer=ADDRESS] [--dest=NAME] [--type=TYPE] [--print-reply[=literal]] [--reply-timeout=MSEC] `<destination object path>` `<message name>` [contents ...]
while the man page prints out
dbus-send [--system | --session | --address=ADDRESS] [--dest=NAME] [--print-reply [=literal]] [--reply-timeout=MSEC] [--type=TYPE] OBJECT_PATH INTERFACE.MEMBER [CONTENTS...]
....
--address=ADDRESS
Send to ADDRESS.
It differs in the parameter --bus, --address and --peer.
Looking at the implementation of dbus-send there are all mentioned parameters supported:
if ((strstr (arg, "--bus=") == arg) || (strstr (arg, "--peer=") == arg) || (strstr (arg, "--address=") == arg))
{
if (arg[2] == 'b') /* bus */
{
is_bus = TRUE;
}
else if (arg[2] == 'p') /* peer */
{
is_bus = FALSE;
}
else /* address; keeping backwards compatibility */
{
is_bus = FALSE;
}
address = strchr (arg, '=') + 1;
if (address[0] == '\0')
{
fprintf (stderr, "\"--peer=\" and \"--bus=\" require an ADDRESS\n");
usage (1);
}
except that --address looks to be outdated and could not be used to connect to a bus. In the opposite dbus-monitor provides connecting to a bus using --address.
Version: 1.10https://gitlab.freedesktop.org/dbus/dbus/-/issues/164Shut down autolaunched Windows session bus after disconnecting last client2022-05-03T06:25:24ZBugzilla Migration UserShut down autolaunched Windows session bus after disconnecting last client## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99751)](https://bugs.freedesktop.org/show_bug.cgi?id=99751)**
## Description
DBus on windows auto by default starts dbus daemon...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99751)](https://bugs.freedesktop.org/show_bug.cgi?id=99751)**
## Description
DBus on windows auto by default starts dbus daemon only on demand. If a client tries to connect to the session bus using the autolaunch meta protocol dbus library starts a dbus session daemon by default.
Unfortunally if the last clients disconnects dbus-daemon is still running which is an issue for example in case the application has been started from an external drive or usb stick.
There should be a dbus daemon configuration option to let the daemon shutdown itself after a timeout in case last client has been disconnected.
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/163Add dbus verbose channels to verbose output.2018-10-15T13:44:36ZBugzilla Migration UserAdd dbus verbose channels to verbose output.## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99585)](https://bugs.freedesktop.org/show_bug.cgi?id=99585)**
## Description
Dbus verbose messages are spread all over the dbus...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99585)](https://bugs.freedesktop.org/show_bug.cgi?id=99585)**
## Description
Dbus verbose messages are spread all over the dbus code and prints out
internal informations helping to find issues. Caused by the amount of
generated messages it is partially hard to follow messages from special
categories which is provided by this patch.
DBus verbose channels are special keywords which are defined on file level
and are print out on each _dbus_verbose() call which makes it possible
to filter out unrelated messages.
DBus verbose channels are enabled by adding the following code fragment
...
DBUS_VERBOSE_CHANNEL(`<category>`)
in a file before using any dbus_verbose () calls.
In case someone do not want to have the keyword in each verbose message,
it would be possible to extend DBUS_VERBOSE environment variable parsing
to support filtering verbose categories by specifing DBUS_VERBOSE=`<category>`.https://gitlab.freedesktop.org/dbus/dbus/-/issues/162Missing dbus daemon auth config test coverage2018-10-15T13:44:45ZBugzilla Migration UserMissing dbus daemon auth config test coverage## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99512)](https://bugs.freedesktop.org/show_bug.cgi?id=99512)**
## Description
While working on [bug 96577](https://bugs.freedesk...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99512)](https://bugs.freedesktop.org/show_bug.cgi?id=99512)**
## Description
While working on [bug 96577](https://bugs.freedesktop.org/show_bug.cgi?id=96577) issues with dbus daemon auth config implementation has been detected and therefore it would be nice to have a easy to run test case to ensure that changes in the auth (and config) implementation of dbus daemon do not introduce regressions.
Version: 1.10
### Depends on
* [Bug 99621](https://bugs.freedesktop.org/show_bug.cgi?id=99621)
* [Bug 99622](https://bugs.freedesktop.org/show_bug.cgi?id=99622)
### Blocking
* [Bug 96577](https://bugs.freedesktop.org/show_bug.cgi?id=96577)https://gitlab.freedesktop.org/dbus/dbus/-/issues/161dbus-monitor: optionally print monotonic timestamps in Linux kernel style2018-10-15T13:45:03ZBugzilla Migration Userdbus-monitor: optionally print monotonic timestamps in Linux kernel style## Submitted by Mikhail Durnev
Assigned to **D-Bus Maintainers**
**[Link to original bug (#98898)](https://bugs.freedesktop.org/show_bug.cgi?id=98898)**
## Description
Created attachment 128263
Add timestamps to dbus-monitor logs
...## Submitted by Mikhail Durnev
Assigned to **D-Bus Maintainers**
**[Link to original bug (#98898)](https://bugs.freedesktop.org/show_bug.cgi?id=98898)**
## Description
Created attachment 128263
Add timestamps to dbus-monitor logs
Dbus logs from IVI (In-Vehicle Infotainment) are difficult or impossible to fully analyse because they do not have timestamps.
**Patch 128263**, "Add timestamps to dbus-monitor logs":
[add-timestamps-to-dbus-monitor-logs.patch](/uploads/385e2a020b1bc738f7c900b091c9961c/add-timestamps-to-dbus-monitor-logs.patch)https://gitlab.freedesktop.org/dbus/dbus/-/issues/160No 'org.freedesktop.DBus.Error.PropertyWriteOnly' error2018-10-15T13:45:43ZBugzilla Migration UserNo 'org.freedesktop.DBus.Error.PropertyWriteOnly' error## Submitted by nschoe
Assigned to **D-Bus Maintainers**
**[Link to original bug (#98722)](https://bugs.freedesktop.org/show_bug.cgi?id=98722)**
## Description
DBus properties can have 3 different access mode:
- readonly
- read
-...## Submitted by nschoe
Assigned to **D-Bus Maintainers**
**[Link to original bug (#98722)](https://bugs.freedesktop.org/show_bug.cgi?id=98722)**
## Description
DBus properties can have 3 different access mode:
- readonly
- read
- write
When trying to set a new value to a `readonly` property, we get the DBus error: `org.freedesktop.DBus.Error.PropertyReadOnly`, but there is no such equivalent for trying to read a `write` property.
Admittedly this should not happen too often as I read that the use of write-only properties is discouraged, but since it is explicitly supported, I think we should provide a proper error.https://gitlab.freedesktop.org/dbus/dbus/-/issues/159Please support a relocatable root2018-10-12T21:29:03ZBugzilla Migration UserPlease support a relocatable root## Submitted by Michael Terry
Assigned to **D-Bus Maintainers**
**[Link to original bug (#98260)](https://bugs.freedesktop.org/show_bug.cgi?id=98260)**
## Description
Created attachment 127303
proposed patch
It would be nice if D...## Submitted by Michael Terry
Assigned to **D-Bus Maintainers**
**[Link to original bug (#98260)](https://bugs.freedesktop.org/show_bug.cgi?id=98260)**
## Description
Created attachment 127303
proposed patch
It would be nice if DBus added support for a runtime relocatable root in Unix. i.e. at runtime, be able to be run from /opt/dbus/ or some such, without having that be a compile-time prefix.
I notice the Windows version has some basic support for this. Detecting its installation directory and treating paths as relative to that.
My specific use case is testing a snap [1] of a full desktop environment. This bundled in dbus and session services and all sorts of things. The session DBus was trying to activate services with their compile-time hardcoded paths and not finding them.
And I bet similar use cases exist.
The plumbing already exists to fix those paths up, thanks to the Windows support.
So I threw together a patch for the Unix side of things, to listen to the new variable DBUS_ROOT. If you prefer a different env name, let me know.
[1] http://snapcraft.io/
**Patch 127303**, "proposed patch":
[0001-Support-runtime-relocation-in-Unix-with-the-DBUS_ROO.patch](/uploads/ec7dbdfd1bc750e8726057012fd6bdee/0001-Support-runtime-relocation-in-Unix-with-the-DBUS_ROO.patch)
Version: git master
### See also
* https://launchpad.net/bugs/1633520https://gitlab.freedesktop.org/dbus/dbus/-/issues/158Add an org.fdo.Introspectable2 interface which returns structured introspecti...2023-10-17T13:17:40ZBugzilla Migration UserAdd an org.fdo.Introspectable2 interface which returns structured introspection data## Submitted by Philip Withnall
Assigned to **D-Bus Maintainers**
**[Link to original bug (#98006)](https://bugs.freedesktop.org/show_bug.cgi?id=98006)**
## Description
Receiving introspection data from D-Bus as XML means that any...## Submitted by Philip Withnall
Assigned to **D-Bus Maintainers**
**[Link to original bug (#98006)](https://bugs.freedesktop.org/show_bug.cgi?id=98006)**
## Description
Receiving introspection data from D-Bus as XML means that anybody consuming that data needs to have an XML parser, which is a bit of a pain if that software otherwise doesn’t need to depend on an XML parser.
Simon and I discussed potentially providing introspection data using the D-Bus type system (i.e. as basically a GVariant) as an alternative — org.freedesktop.DBus.Introspectable2.
Services would have to implement this interface before clients can use it. It would be allowed for a service to implement o.f.D.Introspectable, or o.f.D.Introspectable2, or both, or neither. If all the popular D-Bus libraries implemented both o.f.D.Introspectable and o.f.D.Introspectable2 then high coverage of services could be achieved fairly rapidly.
Here’s my suggestion for the interface design. Unless anybody has any objections, I’ll go ahead and implement it.
```
interface org.freedesktop.DBus.Introspectable2
{
org.freedesktop.DBus.Introspectable2.Introspect (out a(sa(sa(sa(sgya{sv})a{sv})a(sa(sga{sv})a{sv})a(sgya{sv})a{sv})a{sv}) introspection_data)
}
```
Because that type string is hideous, here it is in a more block-like format:
```
array of object structs /* calling it ‘object’ rather than ‘node’ seems clearer */
{
string path /* node name from the XML format */
array of interface structs
{
string name
array of method structs
{
string name
array of method argument structs
{
string name
signature type
byte direction /* enum of: in, out */
dict<string, variant> annotations
}
dict<string, variant> annotations
}
array of signal structs
{
string name
array of signal argument structs
{
string name
signature type
dict<string, variant> annotations
/* note: no direction, because it’s always out for signals */
}
dict<string, variant> annotations
}
array of property structs
{
string name
signature type
byte access_flags /* flags of: read, write, read|write */
dict<string, variant> annotations
}
dict<string, variant> annotations
}
dict<string, variant> annotations
}
```
The data format is a fairly direct conversion of the existing introspection XML format, with the differences that:
* it allows annotations anywhere (bug #86162);
* nodes cannot be nested, and must provide their path; they must all be listed in the top-level array, specifying their absolute path instead of nesting;
* argument names are not optional (because it is really annoying to see ‘arg0’, ‘arg1’, etc. in D-Feet);
* argument directions are required for method arguments, and are not specified for signal arguments.
The same semantics for empty nodes as given in the specification applies: if a node is empty (its interfaces array is empty), it is assumed that the service has elected not to return introspection data for that node because doing so is too expensive. The client should introspect that node explicitly to get the introspection data.
I should note that this interface is very much intended to return programmatically-generated introspection data. Implementing Introspect() by hand would be a massive headache. As such, I haven’t made any effort to make it easy to write this stuff manually.
I suggest documentation is encoded using Markdown strings (as is the current fashion) as annotations (key name: org.freedesktop.DBus.Introspectable2.Documentation, value: a{ss} mapping a locale name (see `man setlocale`, e.g. ‘en_GB’) to a documentation string in the given language). This differs from previous approaches (see bug #88997), none of which have been formalised in the specification. org.gtk.GDBus.DocString uses DocBook strings; the ‘doc’ namespace uses its own XML elements; and inline XML comments use old-style gtk-doc syntax (i.e. a combination of DocBook and custom syntax). None of these are particularly portable — but I acknowledge that using Markdown means that anyone who consumes the documentation from *this* interface will need a Markdown parser. If they care about documentation, they probably have one of those already. gtk-doc has switched to Markdown syntax in the last few years, and other documentation formats use Markdown too. The idea of support for localisation of documentation is taken from https://wiki.allseenalliance.org/irb/extended_introspection_xml.
Structured type information (as discussed in bug #93912) should be provided as annotations.
Finally, I was wondering about forwards compatibility — this interface is prone to becoming outdated if D-Bus adds some more concepts like properties (even if they are added in a forwards-compatible manner elsewhere in D-Bus). Depending on how likely that is, we could add a ‘version’ argument to the Introspect() method, which controls whether it returns newer versions of the introspection data format. The introspected data itself would have to be returned as a variant, version 1 of which would have the type given above. Personally, I think this is overkill and we should just move to version 3 of the interface if needed, but I thought I should mention the idea just in case.
Feedback very welcome.
Version: git master
*edited for Markdown legibility —smcv*https://gitlab.freedesktop.org/dbus/dbus/-/issues/157[OS X] : enable standard (non-launchd) dbus-launch and the use of privileged ...2020-09-28T12:27:25ZBugzilla Migration User[OS X] : enable standard (non-launchd) dbus-launch and the use of privileged services via the system bus## Submitted by René J.V. Bertin
Assigned to **D-Bus Maintainers**
**[Link to original bug (#97927)](https://bugs.freedesktop.org/show_bug.cgi?id=97927)**
## Description
Created attachment 126778
patch against the master branch, #...## Submitted by René J.V. Bertin
Assigned to **D-Bus Maintainers**
**[Link to original bug (#97927)](https://bugs.freedesktop.org/show_bug.cgi?id=97927)**
## Description
Created attachment 126778
patch against the master branch, #1e43857
After discussing this on the ML ("about using privileged (KAuth) helpers: system dbus daemon on OS X?") I think it is about time to open a ticket with a patch that I feel I can propose as a reference implementation.
This patch combines 2 wishes of mine:
1- being able to launch a session daemon when logged in remotely to OS X/macOS, i.e. when launchd cannot be used. In that case the OS is used as a traditional Unix, typically with X11 providing remote display, and there are no technical reasons why DBus wouldn't support this mode of operation ("shouldn't" may be a different thing).
I'm including this because making this possible was in fact in large part a side-effect of the 2nd wish:
2- allow the use of privileged services via the system bus, for instance those based on the KF5 KAuth framework.
With hindsight, point 2 was very easy to implement because the the mechanism to launch the privileged service executable is works as intended on OS X. What failed was the basic libdbus initialisation in the service executable, which didn't provide a session bus address entry in the bus_connection_addresses array.
Given the context the exact value of that entry is without importance. On Linux it would be set to "autolaunch:"; in the attached patch I set it to "launchd:env=DBUS_LAUNCHD_SESSION_BUS_SOCKET" because that appears to be an existing convention. Enabling the code path that takes care of setting this fallback value is what made it relevant to include point 1 above.
There are a few points that are open to discussion:
- is "launchd:env=FOO" indeed an appropriate fallback address? I don't think it will ever be used but may overlook a borderline situation.
- should the org.freedesktop.dbus-system.plist launchd profile provided by my patch be installed by default or should it be optional or an operation to be done manually? Note that installing it doesn't load profile.
- should _dbus_lookup_launchd_socket() indeed check the value of DBUS_LAUNCHD_SESSION_BUS_SOCKET in the environment, and if so should that value have priority over the value obtained from launchctl? The intention I had with the addition was to give a similar mechanism to override the "default" session bus as can be achieved on Linux by overriding DBUS_SESSION_BUS_ADDRESS. NB: changing the DBUS_LAUNCHD_SESSION_BUS_SOCKET value via launchctl has an immediate session-wide effect.
**Patch 126778**, "patch against the master branch, #1e43857":
[combined-patch.diff](/uploads/2a377b384d5b2f4e0feb42c19b21e7b3/combined-patch.diff)
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/156wid can be used without initialisation in dbus-launch.c2018-10-15T13:47:30ZBugzilla Migration Userwid can be used without initialisation in dbus-launch.c## Submitted by René J.V. Bertin
Assigned to **D-Bus Maintainers**
**[Link to original bug (#97924)](https://bugs.freedesktop.org/show_bug.cgi?id=97924)**
## Description
Going over the code I after noticing that dbus-launch set DB...## Submitted by René J.V. Bertin
Assigned to **D-Bus Maintainers**
**[Link to original bug (#97924)](https://bugs.freedesktop.org/show_bug.cgi?id=97924)**
## Description
Going over the code I after noticing that dbus-launch set DBUS_SESSION_BUS_WINDOWID to an invalid wid, I see that the wid variable can indeed be used without having been initialised.
IMHO, either dbus-launch.c should initialise the wid variable to 0 at declaration, or x11_get_address() should be modified as such:
diff --git a/tools/dbus-launch-x11.c b/tools/dbus-launch-x11.c
index a09444b..d79b4a7 100644
--- a/tools/dbus-launch-x11.c
+++ b/tools/dbus-launch-x11.c
@@ -305,10 +305,10 @@ x11_get_address (char **paddress, pid_t *pid, long *wid)
/* locate the selection owner */
owner = XGetSelectionOwner (xdisplay, selection_atom);
- if (owner == None)
- return TRUE; /* no owner */
if (wid != NULL)
*wid = (long) owner;
+ if (owner == None)
+ return TRUE; /* no owner */
/* get the bus address */
result = XGetWindowProperty (xdisplay, owner, address_atom, 0, 1024, False,
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/155DBus Manpage concerning SELinux wrong2018-10-15T13:47:43ZBugzilla Migration UserDBus Manpage concerning SELinux wrong## Submitted by Ralf Spenneberg
Assigned to **D-Bus Maintainers**
**[Link to original bug (#97528)](https://bugs.freedesktop.org/show_bug.cgi?id=97528)**
## Description
We have played around with dbus and SELinux. The only availab...## Submitted by Ralf Spenneberg
Assigned to **D-Bus Maintainers**
**[Link to original bug (#97528)](https://bugs.freedesktop.org/show_bug.cgi?id=97528)**
## Description
We have played around with dbus and SELinux. The only available documentation appears to be the dbus manpage. Unfortunately the example concerning the associate given in this manpage is not correct:
<associate own="org.freedesktop.Foobar" context="foo_t"/>
This should associate the ownership of the dbus service org.freedesktop.Foobar to the selinux domain foo_t. Actually you have to specify the full security context:
<associate own="org.freedesktop.Foobar" context="system_u:object_r:foo_t:s0"/>