dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2023-05-27T07:19:05Zhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/2enable -Wtype-limits or document why not2023-05-27T07:19:05ZBugzilla Migration Userenable -Wtype-limits or document why not## Submitted by frederic heem
Assigned to **D-Bus Maintainers**
**[Link to original bug (#8164)](https://bugs.freedesktop.org/show_bug.cgi?id=8164)**
## Description
dbus doesn't compile with -Wall -Werror with gcc version 4.1.1 20...## Submitted by frederic heem
Assigned to **D-Bus Maintainers**
**[Link to original bug (#8164)](https://bugs.freedesktop.org/show_bug.cgi?id=8164)**
## Description
dbus doesn't compile with -Wall -Werror with gcc version 4.1.1 20060525 (Red
Hat 4.1.1-1)
Here are some examples:
dbus-marshal-header.c: In function '_dbus_header_toggle_flag':
dbus-marshal-header.c:1429: warning: pointer targets in assignment differ in
signedness
dbus-marshal-header.c: In function '_dbus_header_get_flag':
dbus-marshal-header.c:1450: warning: pointer targets in assignment differ in
signedness
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/13new, simpler config language for Unix system services2023-05-27T07:19:05ZBugzilla Migration Usernew, simpler config language for Unix system services[Originally from @walters on [#19593](https://bugs.freedesktop.org/show_bug.cgi?id=19593); issue description later rewritten by @smcv.]
The `<policy>` language is complicated and difficult to get right, and policy fragments intended to ...[Originally from @walters on [#19593](https://bugs.freedesktop.org/show_bug.cgi?id=19593); issue description later rewritten by @smcv.]
The `<policy>` language is complicated and difficult to get right, and policy fragments intended to apply to one system service can easily have "action at a distance" on an unrelated system service.
We should have a simpler policy language subset, either in the XML or out-of-band, in which things we do not want to encourage are simply not something you can express, and things we want to encourage are straightforward.
This is significantly complicated by the fact that the XML policy language is designed to be exhaustive: if you have a message or a connection in mind, you can start at the beginning, read the configuration files for the system or session bus to the end, and know without ambiguity whether the message/connection is allowed or denied. The policy language has no concept of "if no rules apply, do the reasonable thing". As a result, if someone designs a simpler policy language subset, it would probably need to be hooked into the XML policy language with something ugly and seemingly tautological like:
```
<policy context="default">
<allow reasonable_things="true"/>
</policy>
```
in an appropriate location where it will take precedence over the system bus's default-deny policy (but to avoid introducing security regressions on upgrade, other `<policy>` from a sysadmin must take precedence over it).
This is complicated further by the fact that restarting the dbus-daemon during runtime is not supported, reloading the dbus-daemon during upgrades is necessary, reloading the dbus-daemon requires policy and configuration files to be parsed, and the older dbus-daemon from which we are upgrading will refuse to parse configuration that contains any new syntax. This can be partially worked around with an `<include>`, because failure to parse an included file is not fatal (I think?).
One example of a sketch of a new configuration language is in <https://bugs.freedesktop.org/show_bug.cgi?id=50264#c1>. Another is in <https://bugs.freedesktop.org/show_bug.cgi?id=19593#c0>. Another possibility would be that the D-Bus `.service` file contains an outline of the service's high-level policy.https://gitlab.freedesktop.org/dbus/dbus/-/issues/16dbus-send can't send dict args2023-05-27T07:19:05ZBugzilla Migration Userdbus-send can't send dict args## Submitted by Tomas Pelka
Assigned to **D-Bus Maintainers**
**[Link to original bug (#19807)](https://bugs.freedesktop.org/show_bug.cgi?id=19807)**
## Description
Description of problem:
Dbus-send unable to send dict arguments.
...## Submitted by Tomas Pelka
Assigned to **D-Bus Maintainers**
**[Link to original bug (#19807)](https://bugs.freedesktop.org/show_bug.cgi?id=19807)**
## Description
Description of problem:
Dbus-send unable to send dict arguments.
Version-Release number of selected component (if applicable):
dbus-1.1.2
How reproducible:
100%
Steps to Reproduce:
1. Send:
dbus-send --print-reply --dest=org.freedesktop.DBus --type=signal \
/org/freedesktop/DBus/Examples/Echo org.freedesktop.DBus.Hello \ dict:string:int32:"one",1,"two",2,"three",3
Expected results:
Message should be send without error.
Actual result:
process 13920: arguments to dbus_message_iter_open_container() were incorrect, assertion "(type == DBUS_TYPE_STRUCT && contained_signature == NULL) || (type == DBUS_TYPE_DICT_ENTRY && contained_signature == NULL) || (type == DBUS_TYPE_VARIANT && contained_signature != NULL) || (type == DBUS_TYPE_ARRAY && contained_signature != NULL)" failed in file dbus-message.c line 2356.
This is normally a bug in some application using the D-Bus library.
process 13920: dbus message iterator looks uninitialized or corrupted
process 13920: arguments to dbus_message_iter_append_basic() were incorrect, assertion "_dbus_message_iter_append_check (real)" failed in file dbus-message.c line 2239.
This is normally a bug in some application using the D-Bus library.
process 13920: dbus message iterator looks uninitialized or corrupted
process 13920: arguments to dbus_message_iter_append_basic() were incorrect, assertion "_dbus_message_iter_append_check (real)" failed in file dbus-message.c line 2239.
This is normally a bug in some application using the D-Bus library.
process 13920: dbus message iterator looks uninitialized or corrupted
process 13920: arguments to dbus_message_iter_close_container() were incorrect, assertion "_dbus_message_iter_append_check (real_sub)" failed in file dbus-message.c line 2414.
This is normally a bug in some application using the D-Bus library.
process 13920: arguments to dbus_message_iter_open_container() were incorrect, assertion "(type == DBUS_TYPE_STRUCT && contained_signature == NULL) || (type == DBUS_TYPE_DICT_ENTRY && contained_signature == NULL) || (type == DBUS_TYPE_VARIANT && contained_signature != NULL) || (type == DBUS_TYPE_ARRAY && contained_signature != NULL)" failed in file dbus-message.c line 2356.
This is normally a bug in some application using the D-Bus library.
process 13920: dbus message iterator looks uninitialized or corrupted
process 13920: arguments to dbus_message_iter_append_basic() were incorrect, assertion "_dbus_message_iter_append_check (real)" failed in file dbus-message.c line 2239.
This is normally a bug in some application using the D-Bus library.
process 13920: dbus message iterator looks uninitialized or corrupted
process 13920: arguments to dbus_message_iter_append_basic() were incorrect, assertion "_dbus_message_iter_append_check (real)" failed in file dbus-message.c line 2239.
This is normally a bug in some application using the D-Bus library.
process 13920: dbus message iterator looks uninitialized or corrupted
process 13920: arguments to dbus_message_iter_close_container() were incorrect, assertion "_dbus_message_iter_append_check (real_sub)" failed in file dbus-message.c line 2414.
This is normally a bug in some application using the D-Bus library.
process 13920: arguments to dbus_message_iter_open_container() were incorrect, assertion "(type == DBUS_TYPE_STRUCT && contained_signature == NULL) || (type == DBUS_TYPE_DICT_ENTRY && contained_signature == NULL) || (type == DBUS_TYPE_VARIANT && contained_signature != NULL) || (type == DBUS_TYPE_ARRAY && contained_signature != NULL)" failed in file dbus-message.c line 2356.
This is normally a bug in some application using the D-Bus library.
process 13920: dbus message iterator looks uninitialized or corrupted
process 13920: arguments to dbus_message_iter_append_basic() were incorrect, assertion "_dbus_message_iter_append_check (real)" failed in file dbus-message.c line 2239.
This is normally a bug in some application using the D-Bus library.
process 13920: dbus message iterator looks uninitialized or corrupted
process 13920: arguments to dbus_message_iter_append_basic() were incorrect, assertion "_dbus_message_iter_append_check (real)" failed in file dbus-message.c line 2239.
This is normally a bug in some application using the D-Bus library.
process 13920: dbus message iterator looks uninitialized or corrupted
process 13920: arguments to dbus_message_iter_close_container() were incorrect, assertion "_dbus_message_iter_append_check (real_sub)" failed in file dbus-message.c line 2414.
This is normally a bug in some application using the D-Bus library.
Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/17ability to add activation directories later2023-05-27T07:19:06ZBugzilla Migration Userability to add activation directories later## Submitted by Colin Walters `@walters`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#20099)](https://bugs.freedesktop.org/show_bug.cgi?id=20099)**
## Description
Source: https://bugzilla.redhat.com/show_bug.cgi?id=...## Submitted by Colin Walters `@walters`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#20099)](https://bugs.freedesktop.org/show_bug.cgi?id=20099)**
## Description
Source: https://bugzilla.redhat.com/show_bug.cgi?id=484945
The summary is that both KDE and GNOME would like to be able to provide an implementation of the service "org.gnome.PolicyKit".
If dbus was started by the desktop environment, then it could have full control, but this is an inversion problem similar to the one motivating the already extant SetActivationEnvironment bus method.
Proposals:
1) Add a bus method org.freedesktop.DBus.AddServiceDirectory(s) with obvious semantics
2) Go the full general route and do org.freedesktop.DBus.ParseConfig(s) which takes a fragment of bus configuration format.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/18Dbus needs better tracking (logging) possibilities2023-01-26T16:00:04ZBugzilla Migration UserDbus needs better tracking (logging) possibilities## Submitted by Dag Nygren
Assigned to **D-Bus Maintainers**
**[Link to original bug (#23375)](https://bugs.freedesktop.org/show_bug.cgi?id=23375)**
## Description
I have been trying to debug a dbus configuration problem here for ...## Submitted by Dag Nygren
Assigned to **D-Bus Maintainers**
**[Link to original bug (#23375)](https://bugs.freedesktop.org/show_bug.cgi?id=23375)**
## Description
I have been trying to debug a dbus configuration problem here for ages now and noticed that the possibilities of tracking a message through DBUS are virtually non-existant. With the new Polcykit etc. coming up it would be a lot easier if we got:
1. All debugging info to syslog. Now if you turn on verbose for the system bus daemon it doesn't write to stderr, but somewhere, and you have no possibility to catch it.
2. Tracking of all the config files (paths) opened to syslog
3. Tracking of messages passed through. Incoming info, security decisions and where it was sent.
I am sure there could be more, but the above would have saved me some days of trying to figure out...
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/23needs to link with -z nodelete2023-01-26T16:00:04ZBugzilla Migration Userneeds to link with -z nodelete## Submitted by Lennart Poettering
Assigned to **Havoc Pennington**
**[Link to original bug (#26031)](https://bugs.freedesktop.org/show_bug.cgi?id=26031)**
## Description
See:
http://lists.fedoraproject.org/pipermail/devel/2010-J...## Submitted by Lennart Poettering
Assigned to **Havoc Pennington**
**[Link to original bug (#26031)](https://bugs.freedesktop.org/show_bug.cgi?id=26031)**
## Description
See:
http://lists.fedoraproject.org/pipermail/devel/2010-January/129179.html
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/24Sending too large messages results in "Disconnected" and exit()2023-01-26T16:00:04ZBugzilla Migration UserSending too large messages results in "Disconnected" and exit()## Submitted by Philip Van Hoof `@pvanhoof`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#27775)](https://bugs.freedesktop.org/show_bug.cgi?id=27775)**
## Description
...
When you dbus_g_method_send_reply a DBusMess...## Submitted by Philip Van Hoof `@pvanhoof`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#27775)](https://bugs.freedesktop.org/show_bug.cgi?id=27775)**
## Description
...
When you dbus_g_method_send_reply a DBusMessage that is over around 160MB in size.
Because getting the current size of a DBusMessage is either deprecated or not easily possible in the API (without first marshaling, meaning a performance impact just to know the predicted size right in front of sending it - which will do a marshal again), and because there's zero clarity about what the actual maximum message size is (the one in session.conf is apparently not relevant at all), I conclude that this is a bug.
Please either create clarity, make it possible to get the size of your DBusMessage and make it possible to compare that size against a well defined max, or don't exit() my process without *any* warning whatsoever.
Cheers
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/25Implement "maybe", nullable container type2023-09-13T21:57:07ZBugzilla Migration UserImplement "maybe", nullable container type## Submitted by Christian Dywan
Assigned to **Christian Dywan**
**[Link to original bug (#27857)](https://bugs.freedesktop.org/show_bug.cgi?id=27857)**
## Description
There have been requests and suggestions for a "maybe" or nulla...## Submitted by Christian Dywan
Assigned to **Christian Dywan**
**[Link to original bug (#27857)](https://bugs.freedesktop.org/show_bug.cgi?id=27857)**
## Description
There have been requests and suggestions for a "maybe" or nullable type in the past, and so I propose the following:
"maybe", literal "m", is a container type much like an array, but it can only hold either 0 or 1 element. So "ms" could be either "spam", "" or null.
Think of 'string? eggs' in Vala or C#, where the question mark indicates that the string can be null.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/27dbus-daemon hangs while starting if users are in LDAP/NIS/etc.2023-01-26T16:00:05ZBugzilla Migration Userdbus-daemon hangs while starting if users are in LDAP/NIS/etc.## Submitted by BinLi
Assigned to **D-Bus Maintainers**
**[Link to original bug (#28355)](https://bugs.freedesktop.org/show_bug.cgi?id=28355)**
## Description
https://bugzilla.redhat.com/show_bug.cgi?id=502072
Please review this ...## Submitted by BinLi
Assigned to **D-Bus Maintainers**
**[Link to original bug (#28355)](https://bugs.freedesktop.org/show_bug.cgi?id=28355)**
## Description
https://bugzilla.redhat.com/show_bug.cgi?id=502072
Please review this bug for more information.
Description of problem:
mesagebus service hangs on boot on system with ldap auth configured.
Version-Release number of selected component (if applicable):
dbus-0.60-7.2
kernel-2.6.15-1.1969_FC5
How reproducible:
always
Steps to Reproduce:
1.boot
2.
3.
Actual results:
hang until bored
Expected results:
fedora niceness
Additional info:
workaround is to remove the entry for ldap from the group line in
/etc/nsswitch.conf not an acceptible long term solution.
Version: 1.5
### See also
* https://bugzilla.redhat.com/show_bug.cgi?id=182464https://gitlab.freedesktop.org/dbus/dbus/-/issues/29_dbus_get_autolaunch_address can be slow closing file descriptors2023-01-26T16:00:05ZBugzilla Migration User_dbus_get_autolaunch_address can be slow closing file descriptors## Submitted by Padraig O'Briain
Assigned to **Havoc Pennington**
**[Link to original bug (#29526)](https://bugs.freedesktop.org/show_bug.cgi?id=29526)**
## Description
Created attachment 37806
Proposed patch
On my system _dbus_g...## Submitted by Padraig O'Briain
Assigned to **Havoc Pennington**
**[Link to original bug (#29526)](https://bugs.freedesktop.org/show_bug.cgi?id=29526)**
## Description
Created attachment 37806
Proposed patch
On my system _dbus_get-autolaunch_address takes almost 1.5 seconds.
This is because the maximum number of file descriptors is 65536.
**Attachment 37806**, "Proposed patch":
[dbus-02-closefrom.diff](/uploads/5f90c2c56fea973d04199c05060ac24d/dbus-02-closefrom.diff)
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/30Add DBUS_MACHINE_UUID_FILE enviroment variable2023-01-26T16:00:05ZBugzilla Migration UserAdd DBUS_MACHINE_UUID_FILE enviroment variable## Submitted by Louis-Francis Ratté-Boulianne
Assigned to **D-Bus Maintainers**
**[Link to original bug (#29618)](https://bugs.freedesktop.org/show_bug.cgi?id=29618)**
## Description
Created attachment 37923
Add DBUS_MACHINE_UUID_...## Submitted by Louis-Francis Ratté-Boulianne
Assigned to **D-Bus Maintainers**
**[Link to original bug (#29618)](https://bugs.freedesktop.org/show_bug.cgi?id=29618)**
## Description
Created attachment 37923
Add DBUS_MACHINE_UUID_FILE enviroment variable
Right now, you can't package dbus into another application bundle (on OSX) because the dbus-daemon is still looking for the machine uuid file at the path set at compile time.
I'm attaching a patch that allows to set that path at runtime using an environment variable.
~~**Attachment 37923**~~, "Add DBUS_MACHINE_UUID_FILE enviroment variable":
[0008-uuid-env.patch](/uploads/c707b73cd6f2895ab318c94eb49f9c1c/0008-uuid-env.patch)
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/31shutdown request2023-01-26T16:00:05ZBugzilla Migration Usershutdown request## Submitted by Colin Walters `@walters`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#30630)](https://bugs.freedesktop.org/show_bug.cgi?id=30630)**
## Description
Currently various OS vendors like Fedora ship the sy...## Submitted by Colin Walters `@walters`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#30630)](https://bugs.freedesktop.org/show_bug.cgi?id=30630)**
## Description
Currently various OS vendors like Fedora ship the system bus as a service, but restarting it will break all users of it, especially for stateful interactions.
What I suggest we do is export an interface (ideally, this should be an administrative-only interface, like a separate socket as I suggested), that requests a shutdown. When we reach zero connections on the main bus, we exit().
If you think about it actually, in a systemd world we could negotiate shutting down the process by default. You could think of this as a "fast userspace restart", i.e. shut down libvirt, shut down NM, shut down messagebus, all the way down to just systemd, and then have systemd reexec itself and respawn everything.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/34Scope autolaunch to requesting client2023-01-26T16:00:05ZBugzilla Migration UserScope autolaunch to requesting client## Submitted by Colin Walters `@walters`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#32509)](https://bugs.freedesktop.org/show_bug.cgi?id=32509)**
## Description
See
https://bugzilla.redhat.com/show_bug.cgi?id=663...## Submitted by Colin Walters `@walters`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#32509)](https://bugs.freedesktop.org/show_bug.cgi?id=32509)**
## Description
See
https://bugzilla.redhat.com/show_bug.cgi?id=663467
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/35[PATCH] Allow to setup connect timeout for TCP transport2023-01-26T16:00:05ZBugzilla Migration User[PATCH] Allow to setup connect timeout for TCP transport## Submitted by Pavel Strashkin
Assigned to **D-Bus Maintainers**
**[Link to original bug (#33234)](https://bugs.freedesktop.org/show_bug.cgi?id=33234)**
## Description
There is no way to setup connect timeout when you're trying t...## Submitted by Pavel Strashkin
Assigned to **D-Bus Maintainers**
**[Link to original bug (#33234)](https://bugs.freedesktop.org/show_bug.cgi?id=33234)**
## Description
There is no way to setup connect timeout when you're trying to connect
to dbus via TCP. For an example, if you have the following connection
string "tcp:host=A,port=B", and host "A" is unavailable by some reason
then your client will get in stuck. When it come back or when
ETIMEDOUT error happens depends on OS. Get in stuck is a bad thing so
there has to be a way to configure connect timeout via "timeout"
keyword in connection string. The value is in miliseconds. Default
timeout may be 60s.
Attached patch introduces such feature so it's possible to use the
following connection string: "tcp:host=A,port=B,timeout=5000" (5s
timeout). I believe that it's a very helpfull feature. I'm sorry that
my patch is for 1.2.24, but if everything is clear (logic, code, ...)
then i'll backport it to master branch.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/39add peak message sizes to Stats interface2018-10-15T14:09:47ZBugzilla Migration Useradd peak message sizes to Stats interface## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#34040)](https://bugs.freedesktop.org/show_bug.cgi?id=34040)**
## Description
+++ This bug was initially created as a clone of Bug #33757 ++...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#34040)](https://bugs.freedesktop.org/show_bug.cgi?id=34040)**
## Description
+++ This bug was initially created as a clone of Bug #33757 +++
This branch adds a Stats interface. It doesn't yet solve Bug #24307 (it doesn't include the actual match rules), but it does include various potentially-interesting numbers.
In the longer term Colin wants such things to be on a secondary /var/run/dbus/system_bus_management_socket or some such, but splitting off interfaces now seems like a good start on that.
Version: 1.5
### Depends on
* [Bug 33757](https://bugs.freedesktop.org/show_bug.cgi?id=33757)
### Blocking
* [Bug 24307](https://bugs.freedesktop.org/show_bug.cgi?id=24307)https://gitlab.freedesktop.org/dbus/dbus/-/issues/59Feature request: support for variant maps in dbus-send2021-04-19T09:27:18ZBugzilla Migration UserFeature request: support for variant maps in dbus-send## Submitted by Elizabeth Jones `@ellyjones`
Assigned to **Havoc Pennington**
**[Link to original bug (#43555)](https://bugs.freedesktop.org/show_bug.cgi?id=43555)**
## Description
Created attachment 54159
Patch against dbus-1.4.1...## Submitted by Elizabeth Jones `@ellyjones`
Assigned to **Havoc Pennington**
**[Link to original bug (#43555)](https://bugs.freedesktop.org/show_bug.cgi?id=43555)**
## Description
Created attachment 54159
Patch against dbus-1.4.12 to add this feature.
dbus-send(1) does not support nested containers at all. There is a common idiom of having a{sv} as the last argument of dbus API functions to support later extensions, but dbus-send(1) cannot call these functions. Therefore, add special-case support for a{sv}, which can be done without extending the dbus-send(1) syntax in a backward-incompatible way.
Patch attached.
**Patch 54159**, "Patch against dbus-1.4.12 to add this feature.":
[dbus-1.4.12-send-variant-dict.patch](/uploads/dc30ce45e45d9c52bb0b6e42a96f78a8/dbus-1.4.12-send-variant-dict.patch)
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/60Feature request: support for file descriptors in dbus-send2018-10-15T14:28:04ZBugzilla Migration UserFeature request: support for file descriptors in dbus-send## Submitted by Elizabeth Jones `@ellyjones`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#43557)](https://bugs.freedesktop.org/show_bug.cgi?id=43557)**
## Description
Created attachment 54161
Patch against dbus-1.4....## Submitted by Elizabeth Jones `@ellyjones`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#43557)](https://bugs.freedesktop.org/show_bug.cgi?id=43557)**
## Description
Created attachment 54161
Patch against dbus-1.4.12 to add this feature.
dbus-send(1) cannot currently send file descriptors, although the underlying dbus protocol can. Add support for same, with a new syntax "fd:`<n>`".
Patch attached.
**Patch 54161**, "Patch against dbus-1.4.12 to add this feature.":
[dbus-1.4.12-send-unix-fd.patch](/uploads/3d03d8321d0bc1cff43b7f112dfda3eb/dbus-1.4.12-send-unix-fd.patch)
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/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/114Use secure_getenv if it is available2018-10-15T15:08:07ZBugzilla Migration UserUse secure_getenv if it is available## Submitted by Umut Tezduyar
Assigned to **D-Bus Maintainers**
**[Link to original bug (#84871)](https://bugs.freedesktop.org/show_bug.cgi?id=84871)**
## Description
Created attachment 107657
git patch on master
If available use...## Submitted by Umut Tezduyar
Assigned to **D-Bus Maintainers**
**[Link to original bug (#84871)](https://bugs.freedesktop.org/show_bug.cgi?id=84871)**
## Description
Created attachment 107657
git patch on master
If available use secure_getenv over _dbus_check_setuid() and getenv() in _dbus_getenv().
**Attachment 107657**, "git patch on master":
[0001-Use-secure_getenv-if-available.patch](/uploads/46ede878d05423fd7e1df8abf838bf10/0001-Use-secure_getenv-if-available.patch)
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/130[SPEC EXTENSION][PATCH] Add new "arg0has=" string array matches2018-10-15T14:31:41ZBugzilla Migration User[SPEC EXTENSION][PATCH] Add new "arg0has=" string array matches## Submitted by Lennart Poettering
Assigned to **D-Bus Maintainers**
**[Link to original bug (#91755)](https://bugs.freedesktop.org/show_bug.cgi?id=91755)**
## Description
Created attachment 117913
preparation: fix whitespace in t...## Submitted by Lennart Poettering
Assigned to **D-Bus Maintainers**
**[Link to original bug (#91755)](https://bugs.freedesktop.org/show_bug.cgi?id=91755)**
## Description
Created attachment 117913
preparation: fix whitespace in the spec XML
This adds support for "arg0has=" style matches that test strings against messages containing string arrays ("as"). It applies if there's at least one string in the array that matches.
This is useful for implementing udev style "tagging" of devices.
This has been discussed on the ML a while back:
http://lists.freedesktop.org/archives/dbus/2015-April/016666.html
There's also a sd-bus PR implementing this:
https://github.com/systemd/systemd/pull/1036
This bug also adds a preparatory patch containing a trailing whitespace cleanup for the spec, to make it easier to edit and patch.
~~**Patch 117913**~~, "preparation: fix whitespace in the spec XML":
[0001-spec-trailing-whitespace-clean-up.patch](/uploads/753cd08b41acef712cef563396d44f91/0001-spec-trailing-whitespace-clean-up.patch)
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/142Check ListNames() permissions with MLS (SELinux)2018-11-21T16:48:44ZBugzilla Migration UserCheck ListNames() permissions with MLS (SELinux)## Submitted by David King
Assigned to **D-Bus Maintainers**
**[Link to original bug (#93920)](https://bugs.freedesktop.org/show_bug.cgi?id=93920)**
## Description
It's desirable to block services with different MLS permissions fr...## Submitted by David King
Assigned to **D-Bus Maintainers**
**[Link to original bug (#93920)](https://bugs.freedesktop.org/show_bug.cgi?id=93920)**
## Description
It's desirable to block services with different MLS permissions from knowing about other, specifically when calling ListNames(). Attaching a patch that is included in dbus in RHEL 7.
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/150W32: dbus does not support SSPI-based authentication mechanisms2019-05-31T18:24:51ZBugzilla Migration UserW32: dbus does not support SSPI-based authentication mechanisms## Submitted by LRN
Assigned to **D-Bus Maintainers**
**[Link to original bug (#96577)](https://bugs.freedesktop.org/show_bug.cgi?id=96577)**
## Description
As discussed on dbus@lists.freedesktop.org ML, dbus could use
an actual O...## Submitted by LRN
Assigned to **D-Bus Maintainers**
**[Link to original bug (#96577)](https://bugs.freedesktop.org/show_bug.cgi?id=96577)**
## Description
As discussed on dbus@lists.freedesktop.org ML, dbus could use
an actual OS-supported authentication on Windows (EXTERNAL on Windows
is a hack, DBUS_COOKIE_SHA1 has obvious drawbacks).
### Depends on
* [Bug 99512](https://bugs.freedesktop.org/show_bug.cgi?id=99512)https://gitlab.freedesktop.org/dbus/dbus/-/issues/151AppArmor mode not reloaded until a process reconnects2018-10-15T13:50:59ZBugzilla Migration UserAppArmor mode not reloaded until a process reconnects## Submitted by Philip Withnall
Assigned to **D-Bus Maintainers**
**[Link to original bug (#96720)](https://bugs.freedesktop.org/show_bug.cgi?id=96720)**
## Description
• I have a process (A) running in enforce mode under AppArmor...## Submitted by Philip Withnall
Assigned to **D-Bus Maintainers**
**[Link to original bug (#96720)](https://bugs.freedesktop.org/show_bug.cgi?id=96720)**
## Description
• I have a process (A) running in enforce mode under AppArmor, and connected to dbus-daemon
• Process B is also running in enforce mode, and the profile for process A does not allow incoming method calls from process B (but doesn’t deny them either)
• Process B tries to call a method on process A — this is correctly rejected by dbus-daemon
• I call `sudo aa-complain /path/to/process/A` to switch process A to complain mode, which instantly affects all AppArmor decisions made on the syscall boundary for it
• Process B should now be able to call methods on process A, but they are still denied
• If I restart process A, process B //can// now call methods on it
So it seems like the AppArmor mode for a connection to dbus-daemon is being cached and not updated when it changes in the kernel.
dbus version 1.10.8 on an Ubuntu derivative.
Version: 1.10https://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/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/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/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/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/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/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/177[SELinux] Return the context of the dbus-daemon process if asking about org.f...2018-10-15T14:49:37ZBugzilla Migration User[SELinux] Return the context of the dbus-daemon process if asking about org.freedesktop.DBus## Submitted by Laurent Bigonville
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101315)](https://bugs.freedesktop.org/show_bug.cgi?id=101315)**
## Description
Hi,
Currently when asked the SELinux context of the own...## Submitted by Laurent Bigonville
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101315)](https://bugs.freedesktop.org/show_bug.cgi?id=101315)**
## Description
Hi,
Currently when asked the SELinux context of the owner of org.freedesktop.DBus, the dbus-daemon is returning an error.
In the same situation when asked about the Unix user or the PID, the daemon would return its own user or pid.
The following patch is doing the same for the SELinux context by returning the daemon one
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/178It would be nice if dbus-send also accepted "--user"2018-10-15T14:30:24ZBugzilla Migration UserIt would be nice if dbus-send also accepted "--user"## Submitted by Danny Milosavljevic
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101375)](https://bugs.freedesktop.org/show_bug.cgi?id=101375)**
## Description
Created attachment 131848
dbus-send: Add "--user"
**...## Submitted by Danny Milosavljevic
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101375)](https://bugs.freedesktop.org/show_bug.cgi?id=101375)**
## Description
Created attachment 131848
dbus-send: Add "--user"
**Patch 131848**, "dbus-send: Add "--user"":
[dbus-send-user-bus.patch](/uploads/1c0b79719e29aa41783f9a978c7e159f/dbus-send-user-bus.patch)
Version: 1.10https://gitlab.freedesktop.org/dbus/dbus/-/issues/184Containers (#100344): fd-passing-based creation2018-10-15T13:41:25ZBugzilla Migration UserContainers (#100344): fd-passing-based creation## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#101898)](https://bugs.freedesktop.org/show_bug.cgi?id=101898)**
## Description
+++ This bug was initially created as a clone of Bug #100344 ++...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#101898)](https://bugs.freedesktop.org/show_bug.cgi?id=101898)**
## Description
+++ This bug was initially created as a clone of Bug #100344 +++
Following on from Bug #101354, Allison wants to be able to arrange for container instances' servers to appear inside containers in a more elegant way than creating them outside and bind-mounting them in. I already intended to do this, but it is not part of the minimum viable product (Bug #101354).
Design sketch:
The named_parameters a{sv} argument may contain:
ServerSocket: h
A socket (fstat() must indicate format S_IFSOCK)
with SO_DOMAIN = AF_UNIX and SO_TYPE = SOCK_STREAM. The
container manager will arrange for bind() and listen() to be called
on this socket so that it is made available inside the container.
If ServerSocketReadyNotifier is not provided, the container manager
must already have called bind() and listen() (the SO_ACCEPTCONN socket
option is 1 and getsockname() returns an address), such that this
socket is already ready for the message bus to call accept() on it.
In this case the AddServer() method will return the socket's path
and D-Bus address as usual.
If ServerSocketReadyNotifier is provided, then the container manager
may delay calling bind() and listen() until just before it makes the
ServerSocketNotifierReadyNotifier poll readable. In this case the
AddServer() method cannot determine the socket's address, so it
will return an empty byte-array instead of the socket's absolute
path, and an empty string instead of its D-Bus address.
ServerSocketReadyNotifier: h
The reading end of a pipe or FIFO (format S_IFIFO). The container
manager will wait for this pipe to poll readable, then close it
and begin to accept() on the ServerSocket.
(The container manager should keep the write end of this socket open
until it has called bind() and listen() on the ServerSocket,
then close the write end, resulting in the read end polling readable.)
Version: git master
### Depends on
* [Bug 101354](https://bugs.freedesktop.org/show_bug.cgi?id=101354)
### Blocking
* [Bug 100344](https://bugs.freedesktop.org/show_bug.cgi?id=100344)https://gitlab.freedesktop.org/dbus/dbus/-/issues/185Containers (#171): message filtering/policy2023-10-27T19:02:17ZBugzilla Migration UserContainers (#171): message filtering/policy## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#101902)](https://bugs.freedesktop.org/show_bug.cgi?id=101902)**
## Description
+++ This bug was initially created as a clone of Bug #100344 ++...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#101902)](https://bugs.freedesktop.org/show_bug.cgi?id=101902)**
## Description
+++ This bug was initially created as a clone of Bug #100344 +++
Bug #101354 does not let container managers arrange for messages to be filtered. This is part of the wish-list for Bug #100344, because it would eventually let us get rid of flatpak-dbus-proxy.
Design sketch:
* New named parameter:
Allow: a(usos)
Array of tuples (flags: u, bus name: s, object path: o, interface: s)
If this parameter is given, it sets the messages and operations
that are allowed.
An empty array allows sending method calls to the message
bus, and receiving exactly one reply or error for each method call
successfully sent (unless it was NO_REPLY). It also allows
receiving method calls from connections that are not in a container,
and sending exactly one reply or error for each method call
received (unless it was NO_REPLY). It does not allow receiving
broadcast signals. This is the most restrictive possible policy.
[TODO: Does it allow receiving unicast signals from connections
that are not in a container?]
Each array entry is a /rule/ which allows additional operations
according to its flags. If the bus name is the empty string,
it matches all bus names (and hence all possible connections).
If the interface is the empty string, it matches messages with
any interface or no interface. If the object path is "/" and
the OBJECT_PATH_IS_SUBTREE flag is present, it matches messages
with any object path or no object path.
SEE:
The connection may call GetNameOwner(), NameHasOwner(),
GetConnectionCredentials(), etc. to inspect connections
that are in the queue to own the given bus name.
The object path and interface are ignored when checking
for SEE access.
CALL_METHODS:
The connection may send method call messages to
connections that are in the queue to own the given
bus name. Implies SEE.
RECEIVE_BROADCASTS (or RECEIVE_SIGNALS?):
The connection may receive broadcasts (or all signals?)
from connections that are in the queue to own the given
bus name, if they match the given object path and
interface.
TALK: alias for SEE | CALL_METHODS | RECEIVE_whatever
BUS_NAME_IS_SUBTREE:
The bus name is matched in the same way as arg0namespace
in signal match rules, instead of as an exact match.
OBJECT_PATH_IS_SUBTREE:
In addition to messages that match exactly, the object
path matches messages with an object path that has
additional components. For example, "/foo" matches messages
with object path "/foo" or "/foo/bar" but not "/foolish".
Note that this is not identical to arg0path in signal
match rules.
SEND_UNIX_FDS, RECEIVE_UNIX_FDS:
The connection may send, receive messages that contain
Unix fds and match the given bus name, object path and
interface.
OWN_BUS_NAME:
The connection may use RequestName and ReleaseName
to own the given bus name. Implies SEE and TALK.
The object path must be "/" and the interface must
be "".
Not giving this parameter is equivalent to providing policies
that allow the confined connection to send and receive every
message, own every bus name, etc. This is the least restrictive
possible policy.
* o.fd.Containers.GrantAccess(a(uos): rules)
Rules are as above, but bus name is implicitly the caller's
unique name
* o.fd.Containers.RevokeAccess(a(uos): rules)
Rules are as for GrantAccess. If a rule was added more than
once, each revocation removes one of the identical copies.
Version: git master
### Depends on
* #201
* #202
* #203
* #204
* #205
* #206https://gitlab.freedesktop.org/dbus/dbus/-/issues/186Containers (#100344): allow container to live longer than container manager2023-11-30T19:09:01ZBugzilla Migration UserContainers (#100344): allow container to live longer than container manager## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#101903)](https://bugs.freedesktop.org/show_bug.cgi?id=101903)**
## Description
+++ This bug was initially created as a clone of Bug #100344 ++...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#101903)](https://bugs.freedesktop.org/show_bug.cgi?id=101903)**
## Description
+++ This bug was initially created as a clone of Bug #100344 +++
Following on from Bug #101354, we want to let short-lived container manager helper processes create a container with a lifetime and then get out of the way. In particular, Flatpak does not have a "supervisor" process once the sandboxed app is running, except for bwrap (which is minimal, sometimes setuid, and does not use D-Bus) and the flatpak-dbus-proxy (which, long term, we want to remove).
In Bug #101354, the container would stop listening when its creator falls off the bus. This is not suitable for Flatpak long-term.
The design we had at the GTK hackfest was to fd-pass in the read end of a pipe. Until it polls readable, the container server keeps listening. When it polls readable, the container server stops.
This can go in the named parameters a{sv}.
Version: git master
### Depends on
* [Bug 101354](https://bugs.freedesktop.org/show_bug.cgi?id=101354)
### Blocking
* [Bug 100344](https://bugs.freedesktop.org/show_bug.cgi?id=100344)https://gitlab.freedesktop.org/dbus/dbus/-/issues/188Containers (#171): consider adding an option to let other uids in2023-09-06T17:15:44ZBugzilla Migration UserContainers (#171): consider adding an option to let other uids in## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#103457)](https://bugs.freedesktop.org/show_bug.cgi?id=103457)**
## Description
::: bus/containers.c
@@ +318,5 @@
> + *
> + * TODO: For the...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#103457)](https://bugs.freedesktop.org/show_bug.cgi?id=103457)**
## Description
::: bus/containers.c
@@ +318,5 @@
> + *
> + * TODO: For the system bus we might want a way to opt-in to allowing
> + * other uids, in which case we would refrain from overwriting the
> + * BusContext's unix_user_function; but that isn't part of the
> + * lowest-common-denominator implementation. */
Version: git master
### Depends on
* [Bug 101354](https://bugs.freedesktop.org/show_bug.cgi?id=101354)
* [Bug 104610](https://bugs.freedesktop.org/show_bug.cgi?id=104610)
### Blocking
* [Bug 100344](https://bugs.freedesktop.org/show_bug.cgi?id=100344)https://gitlab.freedesktop.org/dbus/dbus/-/issues/190Containers (#100344): Let monitors match messages to/from a container2018-10-15T13:40:12ZBugzilla Migration UserContainers (#100344): Let monitors match messages to/from a container## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#103470)](https://bugs.freedesktop.org/show_bug.cgi?id=103470)**
## Description
Flatpak has "flatpak run --log-system-bus --log-session-bus", i...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#103470)](https://bugs.freedesktop.org/show_bug.cgi?id=103470)**
## Description
Flatpak has "flatpak run --log-system-bus --log-session-bus", implemented by passing arguments to the flatpak-dbus-proxy.
To get rid of the flatpak-dbus-proxy, we should achieve feature parity with it; so there should be some arguments that Flatpak can pass to dbus-monitor that will make it log traffic to/from a container.
dbus-monitor uses the Monitoring interface, which uses match rules, so we will need a match rule with container=/org/freedesktop/DBus/Containers1/c47, or a pair of rules with sender_container=/org/freedesktop/DBus/Containers1/c47 and destination_container=/org/freedesktop/DBus/Containers1/c47.
Version: git master
### Depends on
* [Bug 101354](https://bugs.freedesktop.org/show_bug.cgi?id=101354)https://gitlab.freedesktop.org/dbus/dbus/-/issues/201Containers message filtering/policy (#101902): basic, strict policy2024-02-23T20:15:34ZBugzilla Migration UserContainers message filtering/policy (#101902): basic, strict policy## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#105656)](https://bugs.freedesktop.org/show_bug.cgi?id=105656)**
## Description
+++ This bug was initially created as a clone of Bug #101902 ++...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#105656)](https://bugs.freedesktop.org/show_bug.cgi?id=105656)**
## Description
+++ This bug was initially created as a clone of Bug #101902 +++
As a starting point for T7327, implement the most basic form of the Allow named argument: an empty list of things to allow.
This is planned to have the following semantics:
* Things that are unconditionally allowed are allowed
* Anything that is conditional is forbidden
Version: git master
### Blocking
* [Bug 101902](https://bugs.freedesktop.org/show_bug.cgi?id=101902)
* [Bug 105657](https://bugs.freedesktop.org/show_bug.cgi?id=105657)
* [Bug 105658](https://bugs.freedesktop.org/show_bug.cgi?id=105658)https://gitlab.freedesktop.org/dbus/dbus/-/issues/202Containers message filtering/policy (#101902): control over receiving Unix fds2023-09-06T17:04:39ZBugzilla Migration UserContainers message filtering/policy (#101902): control over receiving Unix fds## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105657)](https://bugs.freedesktop.org/show_bug.cgi?id=105657)**
## Description
+++ This bug was initially created as a clone of Bug #101902...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105657)](https://bugs.freedesktop.org/show_bug.cgi?id=105657)**
## Description
+++ This bug was initially created as a clone of Bug #101902 +++
Allow rules (see Bug #101902) need to be able to opt-in to a container instance receiving Unix fds.
To be designed
==============
One of:
* The rule's object path, bus name, interface must match the message
* The bus name must match but the object path and interface must be non-specific
* The object path, bus name, interface must be non-specific
One of:
* The flag works for both method calls and unicast signals and does not differentiate (this is a bit odd if filtering by path or interface is allowed, because they have different meanings in each direction)
* The flag is split into RECEIVE_UNIX_FD_METHOD_CALLS and RECEIVE_UNIX_FD_SIGNALS
* RECEIVE_UNIX_FDS is assumed to mean method calls because putting fds in signals is silly
Out of scope
============
* Sending Unix fds
* Receiving Unix fds in broadcast signals (which is ridiculous)
Version: git master
### Depends on
* [Bug 105656](https://bugs.freedesktop.org/show_bug.cgi?id=105656)
### Blocking
* [Bug 101902](https://bugs.freedesktop.org/show_bug.cgi?id=101902)https://gitlab.freedesktop.org/dbus/dbus/-/issues/203Containers message filtering/policy (#101902): SEE access control2023-09-06T17:04:39ZBugzilla Migration UserContainers message filtering/policy (#101902): SEE access control## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#105658)](https://bugs.freedesktop.org/show_bug.cgi?id=105658)**
## Description
+++ This bug was initially created as a clone of Bug #101902 ++...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#105658)](https://bugs.freedesktop.org/show_bug.cgi?id=105658)**
## Description
+++ This bug was initially created as a clone of Bug #101902 +++
Implement the SEE access-control model as a step towards Bug #101902.
* Allow list can contain tuples with SEE flag and bus name
* If a contained peer calls ListActivatableNames, ListNames,
NameHasOwner or GetNameOwner, names that it can SEE are not
treated as if they didn't exist
* A contained peer can see NameOwnerChanged signals where the
name in question is one that it can SEE
* If a contained peer can SEE a well-known name, then it can SEE the unique
name that owns that well-known name too (the primary owner)
* If a contained peer receives a method call or unicast signal from
outside the container, then it receives SEE access to the sender's unique name
* Add a named parameter or a special allow rule that lets the contained peer SEE every unique name
* Bus name can be "" to match anything
* Bus name can be combined with BUS_NAME_IS_SUBTREE flag to match like arg0namespace
* Object path is ignored for SEE checks
* Interface is ignored for SEE checks
To be designed
==============
One of these:
* If a contained peer can SEE a well-known name, then it can SEE every
unique name in the queue for that well-known name
* If a contained peer can SEE a well-known name, this does not affect
whether it can SEE unique names that are in the queue for the
well-known name but are not the primary owner
Version: git master
### Depends on
* [Bug 105656](https://bugs.freedesktop.org/show_bug.cgi?id=105656)
### Blocking
* [Bug 101902](https://bugs.freedesktop.org/show_bug.cgi?id=101902)
* [Bug 105659](https://bugs.freedesktop.org/show_bug.cgi?id=105659)
* [Bug 105660](https://bugs.freedesktop.org/show_bug.cgi?id=105660)https://gitlab.freedesktop.org/dbus/dbus/-/issues/204Containers message filtering/policy (#101902): control over messages leaving ...2023-09-06T17:04:39ZBugzilla Migration UserContainers message filtering/policy (#101902): control over messages leaving container## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105659)](https://bugs.freedesktop.org/show_bug.cgi?id=105659)**
## Description
+++ This bug was initially created as a clone of Bug #101902...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105659)](https://bugs.freedesktop.org/show_bug.cgi?id=105659)**
## Description
+++ This bug was initially created as a clone of Bug #101902 +++
[ ] Can add rules to give a contained app permission to send method calls
[ ] ... to any bus name
[ ] ... to specified bus names
[ ] ... only if they are to a specified object path
[ ] ... only if they are to a specified object path hierarchy (OBJECT_PATH_IS_SUBTREE flag)
[ ] ... only if they are on a specified interface
[ ] ... only if they are a specified member of a specified interface
[ ] Sending Unix fds is only allowed if a rule with the SEND_UNIX_FDS flag allows it
[ ] Can add rules to give a contained app permission to send unicast signals
[ ] ... to any bus name
[ ] ... to specified bus names
[ ] ... only if they are from a specified object path
[ ] ... only if they are from a specified object path hierarchy
[ ] ... only if they are from a specified interface
[ ] ... only if they are a specified member of a specified interface (INTERFACE_IS_REALLY_MEMBER flag, or some better name)
[ ] Can add rules to give a contained app permission to send broadcast signals outside its own container instance
[ ] ... only if they are from a specified object path
[ ] ... only if they are from a specified object path hierarchy
[ ] ... only if they are from a specified interface
[ ] ... only if they are a specified member of a specified interface
[ ] Failing to send a broadcast does not return an error to the caller at all
[ ] Failing to send a broadcast to an interested connection does notify monitors
[ ] Each method call sent can have exactly 1 reply, unless it has NO_REPLY_EXPECTED
[ ] If the sender cannot even SEE the proposed destination, the error returned does not allow discovery of whether the destination was even present (ideally check this before even finding out whether the destination exists)
[ ] Unit tests
To be designed
==============
One of these:
* ACTIVATE flag controls StartServiceByName()
* You can StartServiceByName(foo) if there is any method call that
you would be allowed to send to foo
Out of scope
============
* Receiving non-reply messages
Version: git master
### Depends on
* [Bug 105658](https://bugs.freedesktop.org/show_bug.cgi?id=105658)
### Blocking
* [Bug 101902](https://bugs.freedesktop.org/show_bug.cgi?id=101902)https://gitlab.freedesktop.org/dbus/dbus/-/issues/205Containers message filtering/policy (#101902): control over receiving broadcasts2023-09-06T17:04:39ZBugzilla Migration UserContainers message filtering/policy (#101902): control over receiving broadcasts## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105660)](https://bugs.freedesktop.org/show_bug.cgi?id=105660)**
## Description
+++ This bug was initially created as a clone of Bug #101902...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105660)](https://bugs.freedesktop.org/show_bug.cgi?id=105660)**
## Description
+++ This bug was initially created as a clone of Bug #101902 +++
[ ] Rules can allow connections in the container instance to receive broadcasts
[ ] from any bus name
[ ] from a subtree of bus names
[ ] from a specific bus name
[ ] from any object path
[ ] from a subtree of object paths
[ ] from a specific object path
[ ] from any interface
[ ] from a specific interface
[ ] a specific signal in a specific interface
[ ] Broadcasts can't normally contain Unix fds
Version: git master
### Depends on
* [Bug 105658](https://bugs.freedesktop.org/show_bug.cgi?id=105658)
### Blocking
* [Bug 101902](https://bugs.freedesktop.org/show_bug.cgi?id=101902)https://gitlab.freedesktop.org/dbus/dbus/-/issues/206Containers message filtering/policy (#185) followup: allow dconf etc. to gran...2023-09-06T17:15:21ZBugzilla Migration UserContainers message filtering/policy (#185) followup: allow dconf etc. to grant extra accesses## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105661)](https://bugs.freedesktop.org/show_bug.cgi?id=105661)**
## Description
+++ This bug was initially created as a clone of Bug #101902...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105661)](https://bugs.freedesktop.org/show_bug.cgi?id=105661)**
## Description
+++ This bug was initially created as a clone of Bug #101902 +++
Allison Lortie wants dconf to be able to give contained apps access to specific subtrees of the dconf object path tree, without giving them general access to 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(s) of dconf configuration space, and no access to the rest.
Allison suggested an API in which the dconf service creates a new *cursor* object, and asks dbus-daemon to open up access to that object for a particular container instance.
(If it was just about method calls, we could require dconf to implement this itself. However, dconf sends broadcasts, and we want to lock those down too.)
Snap developers suggested that the Containers1 API should be usable for MAC as well as for DAC. To support that, we might want to have this be an opt-in feature, where rules added by dconf or similar only take effect if the container manager has opted-in to "can grant access". (Or we might want to decide that Containers1 is DAC, and tell Snap developers that if they want MAC they need to stick to AppArmor.)
[ ] New message filtering rules can be added by unconfined peers at runtime
[ ] Contained peers cannot alter message filtering rules
[ ] Peers can revoke exact access rules that they added (by making a method call with identically-matching parameters, or with a cookie that was returned when the rule was added, or something)
Out of scope
============
* Peers are not required to be able to revoke access rules by any more complex match rule than an exact one
* Peers are not required to be able to revoke access rules that were added at creation (the Allow parameter from Bug #101902), although it might also be acceptable if they can
Version: git master
### Depends on
#185https://gitlab.freedesktop.org/dbus/dbus/-/issues/207Integrate coverity scans in dbus travis-ci2018-10-15T13:25:08ZBugzilla Migration UserIntegrate coverity scans in dbus travis-ci## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105689)](https://bugs.freedesktop.org/show_bug.cgi?id=105689)**
## Description
dbus is registered at coverity (https://scan.cov...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105689)](https://bugs.freedesktop.org/show_bug.cgi?id=105689)**
## Description
dbus is registered at coverity (https://scan.coverity.com/projects/dbus), at travis-ci (https://travis-ci.org/d-bus/dbus) and github (https://github.com/d-bus/dbus), which makes it possible to run coverity scans on a regular interval very easily. The related howto is located at https://scan.coverity.com/travis_ci
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/211Warn about reaching max received_size2018-10-15T15:10:55ZBugzilla Migration UserWarn about reaching max received_size## Submitted by Alexander Larsson `@alexl`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106826)](https://bugs.freedesktop.org/show_bug.cgi?id=106826)**
## Description
I just debugged an issue where we were leaking r...## Submitted by Alexander Larsson `@alexl`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106826)](https://bugs.freedesktop.org/show_bug.cgi?id=106826)**
## Description
I just debugged an issue where we were leaking replies returned from dbus_connection_send_with_reply_and_block(). These replies are small, but still count against the the max-received-size live_messages counter, even on the client side.
This would have been much easier to debug if the logs had any kind of warning about reaching this limit, especially for the client (rather than bus) side where we're not really expecting this to *ever* happen, because we're unlikely to be overloaded by replies from the bus.https://gitlab.freedesktop.org/dbus/dbus/-/issues/218Run tests under valgrind2018-11-16T15:16:49ZBugzilla Migration UserRun tests under valgrind## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#107194)](https://bugs.freedesktop.org/show_bug.cgi?id=107194)**
## Description
On Bug #105656, Philip suggested running the tests under valgri...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#107194)](https://bugs.freedesktop.org/show_bug.cgi?id=107194)**
## Description
On Bug #105656, Philip suggested running the tests under valgrind. This is a larger task than one might think, because many of the tests are not fully valgrind-clean (and because valgrind doesn't currently work on Debian unstable due to binutils behaviour changes, so I'm having to test all this in a Debian 9 chroot).
I've mostly found false positives, but a couple of actual bugs.
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/219[RFC] specification extension: ConnectClient()2018-10-15T13:17:34ZBugzilla Migration User[RFC] specification extension: ConnectClient()## Submitted by Tom Gundersen `@tomegun`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107245)](https://bugs.freedesktop.org/show_bug.cgi?id=107245)**
## Description
This is a follow-up on the discussion in <https://...## Submitted by Tom Gundersen `@tomegun`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107245)](https://bugs.freedesktop.org/show_bug.cgi?id=107245)**
## Description
This is a follow-up on the discussion in <https://github.com/systemd/systemd/issues/9503>.
I want to suggest adding a new call, ConnectClient() to the org.freedesktop.DBus interface. The intention behind this is to allow a (privileged) client to connect and claim names on behalf of another (unprivileged) one.
The discussion that precipitated this was the desire to allow PID1 to spawn dbus-clients running as a dynamic user, without having to update the DBus policy dynamically to allow these new users to connect and claim names on the bus.
The proposed API extension would allow PID1 to tell dbus daemon to connect the new client, acquire for it a set of given names, and pin in it its dynamic (unprivileged) credentials, but to use PID1's (privileged) credentials for the policy checks when deciding if the client is allowed to be connected and to acquire the names.
This would solve the immediate problem at hand of dynamic users, but it would also allow other features:
1) Scheduling of well-known names
Currently, if a name is activatable, it is always activatable. There is no way of delaying the availability of a name, or making a name no longer activatable. Short of delaynig the start-up of the whole bus, or shutting the bus down.
2) Socket activation of DBus clients
Allowing DBus clients to be socket-activated is both a simpler scheme than the current name activation, but it would also allow for proper exit-on-idle, which name activation does not allow (without potentially dropping messages).
3) Simplification of XML policy
This is obviously up to the implementers, but this scheme would long-term allow systems without own/user/group directives. And as send_* recv_* directives are already not strictly speaking necessary (one could use polkit instead), this could in the future allow for greatly simplified policies in the common case.
Suggested API (based on suggestion by David Herrmann):
`org.freedesktop.DBus.ConnectClient(h socket, a{sv} args) -> (s unique_name);
This pre-connects, pre-authenticates, and prepares an AF_UNIX socket for use as a D-Bus connection. The socket is taken as input rather than output, to guarantee that the owning-uid/creds are correct. If the socket is not AF_UNIX+SOCK_STREAM+unconnected, the call simply fails.
The args parameter can be extended in the future to modify this call. Examples:
`RequestNames`: Takes a string array as argument; specifies which names are pre-acquired by the client.
`AllowUnixFds`: Set the ALLOW_UNIX_FDS flag for the new connection.
The message daemon makes this call available to everyone, but verifies the caller (not the passed in client socket) is allowed to connect and claim the names specified in `RequestNames`.
Note that it isn't expected that existing clients connecting in the traditional way can necessarily be ported over to this new API without further notification. As pointed out by smcv in the above bug, care must be taken with the fact that names are claimed before the client has been initialized. In the common case this shouldn't make a difference, and in the case a client needs to make calls on the bus before processing incomming method calls on its names, it would either have to buffer messages, or use a separate connection to the bus for the initialization before starting to process the main connection (much could be said on that topic, I'm just mentioning it briefly here to note that it is on the radar).
If we agree that we want something like this and on a basic design, I'm happy to write it up as a patch to the spec.https://gitlab.freedesktop.org/dbus/dbus/-/issues/246autolaunch:scope=*install-path for Mac2021-05-06T08:40:49ZHannah von Rethautolaunch:scope=*install-path for MacOn Windows we have the feature and it enables us to provide standalone installers for KDE applications.
To improve our KDE Mac support it would be awesome to have something similar there, to allow a autolaunched dbus per .app dir.
Thanks.On Windows we have the feature and it enables us to provide standalone installers for KDE applications.
To improve our KDE Mac support it would be awesome to have something similar there, to allow a autolaunched dbus per .app dir.
Thanks.https://gitlab.freedesktop.org/dbus/dbus/-/issues/258Gather coverage stats from GitLab CI2019-01-24T10:20:39ZSimon McVittieGather coverage stats from GitLab CI@pwithnall writes:
> Have you considered hooking [coverage stats] up to GitLab CI? There are two things to do there:
>
> - Run `lcov` as part of a CI step after all the tests succeed, and export the HTML pages as artifacts. GLib does tha...@pwithnall writes:
> Have you considered hooking [coverage stats] up to GitLab CI? There are two things to do there:
>
> - Run `lcov` as part of a CI step after all the tests succeed, and export the HTML pages as artifacts. GLib does that [here](https://gitlab.gnome.org/GNOME/glib/blob/85b5a72e699a20a65d116805670db14a1db45cad/.gitlab-ci.yml#L156).
>
> - Note the `coverage: (regex)` line there. You can add a badge to GitLab [here](https://gitlab.freedesktop.org/dbus/dbus/edit) which shows the `master` coverage at a glance. GLib uses these settings:
> - Link: https://gnome.pages.gitlab.gnome.org/glib/coverage/
> - Badge image URL: [https://gitlab.gnome.org/%{project_path}/badges/%{default_branch}/coverage.svg](https://gitlab.gnome.org/%%7Bproject_path%7D/badges/%%7Bdefault_branch%7D/coverage.svg)https://gitlab.freedesktop.org/dbus/dbus/-/issues/477Containers (#171): minimal, identification-only version2023-10-27T19:02:17ZSimon McVittieContainers (#171): minimal, identification-only version## User story
Maintainers of xdg-desktop-portal want to identify whether a message comes from a sandboxed Flatpak/Snap/(etc.) app, so that they can present appropriate UI and apply appropriate restrictions.
(Other D-Bus services that o...## User story
Maintainers of xdg-desktop-portal want to identify whether a message comes from a sandboxed Flatpak/Snap/(etc.) app, so that they can present appropriate UI and apply appropriate restrictions.
(Other D-Bus services that offer portal-like functionality could have similar requests and should also be considered; x-d-p is just one example.)
## Description
This is a subset of the Containers interface (#171) and was originally designed and implemented in:
* [fdo#101354](https://bugs.freedesktop.org/show_bug.cgi?id=101354)
* [fdo#101899](https://bugs.freedesktop.org/show_bug.cgi?id=101899)
* [fdo#104610](https://bugs.freedesktop.org/show_bug.cgi?id=104610)
The implementation was disabled in 505233a5 and 9d60676a before freezing 1.14.0, to avoid having to support an interface in which we might want to make incompatible changes. It was also removed from the spec in f8a2a03c.
### APIs included in dbus 1.14.0
These are included in 1.14.0, so we cannot remove them, only deprecate them if necessary.
* Add a new header field to messages, C macro `DBUS_HEADER_FIELD_CONTAINER_INSTANCE`, with value 10. C accessors in libdbus are `dbus_bool_t dbus_message_set_container_instance(DBusMessage *, const char *)` and `const char *dbus_message_get_container_instance (DBusMessage *)`. It is documented as being an object path or `NULL`.
* Add a new error, C macro `DBUS_ERROR_NOT_CONTAINER`, with value `org.freedesktop.DBus.Error.NotContainer`.
### APIs that were never in a stable release
This exists in dbus-daemon, but most of it is `#if 0` since late 2021.
* Container instances are identified by an object path, the *instance ID*, which is different from `/`. This is currently treated as opaque and has no interfaces. Most methods raise `NotContainer` if given an object path that is not a valid instance ID.
* New interface on `o.fd.DBus`: `org.freedesktop.DBus.Containers1`
* Implementation detail: this is only available on Unix, and only if enabled at compile time.
* `RequestHeader() -> ()`
* After you call this method succesfully, `DBUS_HEADER_FIELD_CONTAINER_INSTANCE` will be added to messages delivered to you. Its value is the instance ID of the sender, or `/` if the sender is on the main (non-contained) connection.
* `DBUS_HEADER_FIELD_CONTAINER_INSTANCE` will be removed from all other messages, if present.
* `signal InstanceRemoved(o: instance_id)`
* Emitted when a container instance vanishes.
* `StopListening(o: instance_id) -> ()`
* Stop listening for new connections on the socket belonging to *instance_id*, but do not terminate existing connections.
* Only the same Unix uid that created *instance_id* can call this.
* `StopInstance(o: instance_id) -> ()`
* Same as `StopListening`, but also disconnect any existing connections.
* Only the same Unix uid that created *instance_id* can call this.
* `GetInstanceInfo(o: instance_id) -> (a{sv}: creds, s: type, s: name, a{sv}: metadata)`
* *creds* is the result of calling `GetConnectionCredentials()` on the connection that created *instance_id*.
* *type* is a reversed-DNS-style name for the container manager, canonically `org.flatpak` or `io.snapcraft`.
* *name* is what the container manager calls this app. I expect Flatpak to use reversed-DNS app IDs, but I expect Snap to use its own app IDs (which are simple strings like `firefox` and `steam`).
* *metadata* is currently defined by the container manager, but should probably be changed to have some sort of standardization, with either a convention or a separate dict for container-manager-specific stuff.
* `GetConnectionInstance(s: bus_name) -> (o: instance_id, a{sv}, s, s, a{sv})`
* If *bus_name* is from a container instance, return its instance ID and the same information as for `GetInstanceInfo`.
* Otherwise, raise `o.fd.DBus.Error.NotContainer`.
* `AddServer(s: type, s: name, a{sv}: metadata, a{sv}: kwargs) -> (o: instance_id, ay: socket_path, s: dbus_address)`
* Create a new listening socket.
* `type`, `name`, `metadata` are the same as for `GetInstanceInfo`.
* When the caller disconnects from the bus, the equivalent of `StopListening` happens. #186 adds an opt-out for this behaviour but is not on the critical path.
* `kwargs` is for future extension. Namespace management is the same as for [Features](https://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-properties-features).
* `property SupportedArguments: as, readable`
* A list of keys you can put in the last parameter of `AddServer`.
Other API surface area:
* In `GetConnectionCredentials`, add one new field: `org.freedesktop.DBus.Containers1.Instance`, which is the same object path as `DBUS_HEADER_FIELD_CONTAINER_INSTANCE`.
* Connections to container sockets cannot call any "bus driver" method with `METHOD_FLAG_PRIVILEGED` or `METHOD_FLAG_NO_CONTAINERS`: currently this means `UpdateActivationEnvironment`, `BecomeMonitor` and the dbus-daemon-specific `EnableVerbose`, plus the new `AddServer`, `StopInstance` and `StopListening`.
## Acceptance
* [x] Decision on #210: either we switch the instance ID from an object path to an integer, or we leave it as an object path. Arbitrary deadline: if there is no movement on this and #478 by the end of September 2023, then @smcv considers the conclusion to be: we leave it as an object path.
* [x] Decision on #189: what to do about extra-privileged methods. Arbitrary deadline: if there is no movement on this by the end of September 2023, then @smcv considers the conclusion to be: take no action, the initial implementation was fine.
* [ ] Decision on #479: how we represent metadata
* [ ] Re-enable Containers interface in development git branch, gated by `-Dcontainers=true` (by reverting 505233a5 and 9d60676a)
* [ ] Document Containers interface in its current form in dbus-specification.xml (revert f8a2a03c and update)
* [ ] Unit tests pass and have good coverage
* [ ] Code review
* [ ] Merge to development branch
## Deadline
Targeted for inclusion in dbus 1.16.0.
In the interests of having this not stall for another 5 years, @smcv is setting an arbitrary deadline of the end of 2023 for this. If anything is still under discussion at that point, then the version that got merged by then is what we will ship (and if someone doesn't like it then that's too bad); or if nothing was merged at that point, then @smcv will reinstate the version that was disabled in late 2021 on an as-is basis.
## Nice to have
Nice-to-haves should be minimized, please. In an effort to avoid avoid a serious risk that this feature will never be available at all, @smcv would like to avoid it being delayed by anything that is not on the critical path for getting this feature finished, documented, tested and available to users.
## Out of scope
* Obsoleting xdg-dbus-proxy by providing filtering/policy is #185 and all its various sub-tasks, and is out of scope for the purposes of this issue, to avoid having this never happen.
* The CMake build system does not have a way to enable this feature. We are moving towards Meson as the recommended (only?) build system for dbus on Unix, so this is not considered to be a blocker. If the Meson feature is switched to be enabled-by-default, then it can be added to CMake as enabled-by-default or enabled-on-Linux at that time.
* Stable release1.16.0https://gitlab.freedesktop.org/dbus/dbus/-/issues/478AddMatch pattern for integers2023-09-07T11:47:20ZSimon McVittieAddMatch pattern for integers## User story
Some reviewers of #171 wanted it to use opaque integers, instead of opaque object paths, to identify an object.
## Description
If we want to support users of D-Bus using opaque integers to identify a resource, then it sh...## User story
Some reviewers of #171 wanted it to use opaque integers, instead of opaque object paths, to identify an object.
## Description
If we want to support users of D-Bus using opaque integers to identify a resource, then it should be possible to match that resource by its opaque integer value in signal arguments. For example, if this interface exists:
```
CreateThing(...) -> (t: opaque_id)
signal ThingUpdated(t: opaque_id, a{sv}: info)
```
then it should be possible for a caller of `CreateThing(...) -> 42` to match `ThingUpdated(42, {...})` without needing to watch for every signal affecting any other Thing.
We can do this for strings with `arg0` and object paths with `arg0path`, but we can't currently do this for integers.
If this functionality is important to someone, I'd be happy to review a merge request that adds this to the spec and the reference implementation. I don't intend to implement this myself; consider this to be an experiment in crowdsourcing minor feature implementations.
I do not intend to change the Containers interface (#171) to use opaque integers (#210) unless someone steps forward in the next few weeks to say that they will be implementing this, and then follows through with spec wording and a reference implementation.
### Proposed spec
A straw-man spec for this:
Callers of `AddMatch` can specify a match rule with `arg0int`, ..., analogous to `arg0path`, for example `arg0int=0,arg1int=-1,arg2int="42"`.
The pattern must be written in ASCII decimal in a canonical form: either `0`, or a strictly positive integer with no leading zeroes and an optional `-` sign prefix. `0x1`, `0755`, `-0`, `1e+5` are not valid patterns.
If the pattern has too many digits to be representable in D-Bus' largest types (currently signed and unsigned 64-bit), the implementation may either return an error from `AddMatch`, or treat it as a pattern that does not match any messages.
These patterns can match any integer argument (types `bynqiuxt`) in the corresponding position. Other types (including `d`, `h`, all string-like types and all containers) never match this pattern. For the purposes of matching this pattern, `b` is treated as an integer in the range 0 to 1 inclusive, and `y` is treated as an integer in the range 0 to 255 inclusive.
Messages are matched against the pattern as if by converting both the pattern and the argument to an arbitrarily large signed integer type and comparing their values, or equivalently, as if by writing both the pattern and the argument in the same canonical ASCII form and comparing their string values. Production-quality implementations are encouraged to use a more efficient implementation than either of these, but it must give the same results. In particular, there is no wrap-around: a pattern `arg0int=-1` does not match a uint16 argument with value 65535.
(A different spec would be fine, if documented clearly and with a rationale given.)
### Proposed implementation
Store the pattern as `{ dbus_uint64_t value; dbus_bool_t negative; }`, where `value` is `(dbus_uint64_t) actual_value` in the case of negative numbers, or as sign-and-magnitude, or something similar.
## Acceptance
* [ ] Reference implementation can match integer arguments in messages against a pattern
* [ ] How these match rules work is documented in `dbus-specification.xml`
* [ ] Matching any message against any pattern has a single unambiguous correct result defined by the spec
* [ ] The reference implementation matches strictly:
* [ ] Patterns match exactly those messages that the spec says they should match (no non-determinism, aliasing, etc.)
* [ ] Only patterns that match the definition in the spec are accepted, all others cause `AddMatch` to fail
* [ ] Automated tests covering at least: positive, negative, zero, matching booleans, not matching other types, quoting being optional, rejecting invalid patterns
* [ ] Code review
* [ ] Merge to development git branch
## Out of scope
* Type `d` (double)
* Type `h` (the actual numeric value is an implementation detail)
* Comparing other than for equality (`<`, `>`, `!=`, bitmasks, etc.)
/cc @dvdhrm @desrthttps://gitlab.freedesktop.org/dbus/dbus/-/issues/479Containers (#171): finalize metadata representation2024-01-31T13:35:44ZSimon McVittieContainers (#171): finalize metadata representation## User stories
xdg-desktop-portal maintainers would like to be able to use #171 generically, to identify applications that are managed by a non-Flatpak, non-Snap container manager without having to write container-manager-specific code...## User stories
xdg-desktop-portal maintainers would like to be able to use #171 generically, to identify applications that are managed by a non-Flatpak, non-Snap container manager without having to write container-manager-specific code for it.
Some non-maintainers commenting on #171 are not happy with the metadata representation in various ways.
## Description
@swick points out on #171:
> One big issue in x-d-p is that right now we need sandbox engine specific ways of looking up metadata like the desktop file. The sandbox engine could provide this information to us easily.
I am sympathetic towards this view, but the design that was merged (and then disabled in late 2021) did not address this: it only had:
* *type*: Reversed domain name identifying a container manager or container technology, as passed to the `AddServer`</literal>` method, such as org.flatpak or io.snapcraft
* *name*: Some unique identifier for an application or container, whose meaning is defined by the maintainers of the container type.
* Implementation detail: for Flatpak, I expect that this would be the Flatpak app ID (`$FLATPAK_ID`), a reversed DNS name, for example `org.gnome.Weather`. Flatpak apps are constrained to only be allowed to export AppStream metadata that is either `$FLATPAK_ID` or `$FLATPAK_ID.desktop`, Desktop Entry files that are `$FLATPAK_ID.desktop` or `$FLATPAK_ID.anything.desktop`, D-Bus names that are in a similar namespace (unless special permissions are added), and so on.
* Implementation detail: for Snap, I expect that this would be the Snap app ID, which is a short string like `firefox` or `steam` in a namespace curated by Canonical's single canonical Snap repository, and does not necessarily have anything to do with the AppStream or Desktop Entry namespaces.
* *metadata*: `a{sv}` of metadata describing the application or container, with the keys and values defined by the maintainers of the container type.
We could get what @swick is looking for by simply redefining the spec for *metadata*, for example using the same sort of namespacing as [Features](https://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-properties-features): we could say that names with no dot are defined by the D-Bus Specification, or by some freedesktop.org spec shared by D-Bus and Wayland (for example we could say that `desktop_id` is an exported Desktop Entry for the app), while names with a dot are reversed-DNS and defined by the domain owner (for example Canonical could define `com.ubuntu.apparmor_profile` and make Snap set it, if they want to).
Meanwhile, @whynothugo requested an "instance ID" as a top-level thing (presumably namespaced by the *type*, and available in all the same places that the *type* and *name* are), and @swick pointed out that the equivalent [Wayland specification](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/68) has an instance ID (although not yet any extensible metadata).
In Flatpak specifically, the instance ID is important because two instances of `org.gnome.Weather` don't *necessarily* have the same permissions and other sandboxing parameters, but two processes within the same instance ID definitely *do* have the same permissions and sandboxing parameters.
It's not clear to me where the best place is to draw the line between "top-level, guaranteed to exist" and "extension point, not guaranteed". The sandboxing framework that "owns" the container instance makes sense to me as top-level and guaranteed, because other fields are going to be defined in terms of it. I think it's reasonable to assume that every sandboxing framework is going to have some concept of an app name that is broadly equivalent to what Flatpak and Snap have, and even if it doesn't, the empty string is a valid value. It's less clear to me whether "instance ID" is equally universally-applicable - but since Wayland security contexts have it at top level, if we want to share a registry/namespace of metadata with those, it might be a good idea to be consistent.
## Acceptance
* [ ] Decision needed: How are keys in the metadata dict namespaced? (As far as I can see, this is just a documentation problem: it's likely to be an `a{sv}` either way.)
* [ ] Provide spec wording for the namespacing, referring to some external spec if appropriate.
* [x] Decision needed: Do we add an instance ID at top level, next to the type and name?
* [x] If a top-level instance ID is desirable, add it to the implementation (trivial change by mimicking how we handle the type and name, should be relatively suitable for dbus beginners). Allow the empty string as a possible instance ID.
## Nice to have
* [x] Ask Snap maintainers what they consider to be the canonical (no pun intended) domain name for Snap, and use the reverse of that in our examples, analogous to `org.flatpak`. I previously used `io.snapcraft` but because Snap is centralized, it isn't immediately obvious whether `snapcraft.io` is the equivalent of `flatpak.org` (the sandbox implementation itself), or `flathub.org` (the conventional app-store), or both.
## Out of scope
* Defining specific metadata fields for interoperable/fd.o use
* Defining specific metadata fields for Flatpak
* Defining specific metadata fields for Snaphttps://gitlab.freedesktop.org/dbus/dbus/-/issues/490CI should mostly be on Debian 12 'bookworm', with maybe one job using Debian ...2023-12-01T19:18:34ZSimon McVittieCI should mostly be on Debian 12 'bookworm', with maybe one job using Debian 11 'bullseye'Debian 12 'bookworm' was released as stable in mid 2023, so we shouldn't be trying too hard to target anything older than that. Newer compilers will probably give us better diagnostics.
Let's get the CI green again before we do anything...Debian 12 'bookworm' was released as stable in mid 2023, so we shouldn't be trying too hard to target anything older than that. Newer compilers will probably give us better diagnostics.
Let's get the CI green again before we do anything in this direction, but after CI is working, it would be good to get the Debian-based parts of our CI running on bookworm instead of the current bullseye.
Optionally, we could have one job that runs on bullseye, to verify that we're at least somewhat backwards-compatible (the same way we had a Debian 10 'buster' job before it was removed in 5d192278).https://gitlab.freedesktop.org/dbus/dbus/-/issues/499dbus-activation applications shouldn't be in session.slice2024-02-23T18:39:19ZMatt Johnstonmatt@ucc.asn.audbus-activation applications shouldn't be in session.slice## To reproduce
Steps to reproduce the behavior:
- Run a standard Gnome desktop (Ubuntu 23.10 here, so dbus 1.14.10, systemd 253.5-1ubuntu6.1)
- Click Files icon to start Nautilus
It runs via dbus-activation:
```
Feb 05 16:32:06 dust d...## To reproduce
Steps to reproduce the behavior:
- Run a standard Gnome desktop (Ubuntu 23.10 here, so dbus 1.14.10, systemd 253.5-1ubuntu6.1)
- Click Files icon to start Nautilus
It runs via dbus-activation:
```
Feb 05 16:32:06 dust dbus-daemon[263850]: [session uid=1001 pid=263850] Activating service name='org.gnome.Nautilus' requested by ':1.28' (uid=1001 pid=264522 comm="/usr/bin/gnome-shell" label="unconfined")
```
## Expected result
Nautilus runs in app.slice or a similar cgroup/slice under that. This would be seen running `systemd-cgls`.
## Actual result
Nautilus runs as part of dbus.service slice, which is under session.slice.
The slice is set in the user service file
https://gitlab.freedesktop.org/dbus/dbus/-/commit/03b4fba4b0d6e7294a5390d6de9de6cf5e50ec25
session.slice is meant to be for
"All essential services and applications required for the
session should use this slice. These are services that either
cannot be restarted easily"
https://www.freedesktop.org/software/systemd/man/latest/systemd.special.html#session.slice
Instead something like Nautilus should be in app.slice.
`systemd-cgls` shows:
```
Control group /:
-.slice
├─user.slice (#361)
│ → user.invocation_id: fa8aa6526dd44a01be2aa1c509494d2f
│ └─user-1001.slice (#6298)
│ → user.invocation_id: 2ce5f7ea76bf48e58c6b9e79ab0d4a21
│ ├─user@1001.service … (#8184)
│ │ → user.invocation_id: 260ffcb0b0fa45edb3ef8e3d8f20557b
│ │ → user.delegate: 1
│ │ ├─session.slice (#8717)
...
│ │ │ ├─dbus.service (#69985)
│ │ │ │ → user.xdg.inactive-since: 91549941866
│ │ │ │ ├─263850 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
│ │ │ │ ├─264725 /usr/libexec/gnome-shell-calendar-server
│ │ │ │ ├─264739 /usr/bin/gjs -m /usr/share/gnome-shell/org.gnome.Shell.Notifications
│ │ │ │ ├─264893 /usr/libexec/ibus-portal
│ │ │ │ ├─264959 /usr/libexec/goa-daemon
│ │ │ │ ├─264974 /usr/libexec/goa-identity-service
│ │ │ │ ├─265271 /usr/bin/gjs -m /usr/share/gnome-shell/org.gnome.ScreenSaver
│ │ │ │ ├─268197 /usr/bin/nautilus --gapplication-service
│ │ │ │ ├─271088 /usr/bin/gnome-calendar --gapplication-service
│ │ │ │ ├─281847 /bin/evince /home/matt/path/to/some.pdf
│ │ │ │ └─281856 /usr/libexec/evinced
```
## Additional context
The reason I'm reporting this is that if something in dbus.service is oom-killed, systemd might kill everything in dbus.service.
(https://github.com/systemd/systemd/issues/25376 is somewhat related, in terms of preventing systemd killing the whole slice. But Nautilus etc shouldn't be in dbus.service's slice)
I saw this with evince running in dbus.service's cgroup, so the whole desktop crashes. Evince had been launched by double-clicking on a file in Nautilus, running via dbus-activation
```
Feb 05 19:12:40 dust dbus-daemon[263850]: [session uid=1001 pid=263850] Activating service name='org.gnome.evince.Daemon' requested by ':1.480' (uid=1001 pid=281847 comm="/bin/evince /home/matt/path/to/some.pdf" label="/usr/bin/evince (enforce)")
```
dmesg:
```
[351225.625584] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=user.slice,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1001.slice/user@1001.service/session.slice/dbus.service,task=evince,pid=238570,uid=1001
[351225.625617] Out of memory: Killed process 238570 (evince) total-vm:1455872kB, anon-rss:309100kB, file-rss:1292kB, shmem-rss:32324kB, UID:1001 pgtables:976kB oom_score_adj:200
```
journalctl:
```
Feb 05 16:09:27 dust kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=user.slice,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1001.slice/user@1001.service/session.slice/dbus.service,task=evince,pid=238570,uid=1001
Feb 05 16:09:26 dust systemd[2282]: dbus.service: A process of this unit has been killed by the OOM killer.
Feb 05 16:09:26 dust systemd[2282]: dbus.service: Failed with result 'oom-kill'.
...
Feb 05 16:09:26 dust systemd[2282]: dbus.service: Failed with result 'oom-kill'.
```
I'm not sure if this issue entirely belongs as a bug in dbus, but certainly having the user dbus.service file set `Slice=session.slice` (but no other slice switching) seems like it's part of the problem.