dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2018-10-12T21:36:24Zhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/224Missing D-Bus C++ wrapper on wiki page2018-10-12T21:36:24ZBugzilla Migration UserMissing D-Bus C++ wrapper on wiki page## Submitted by Waqar Hameed
Assigned to **D-Bus Maintainers**
**[Link to original bug (#108271)](https://bugs.freedesktop.org/show_bug.cgi?id=108271)**
## Description
Lennart Poettering advised me to file a bug here for the wiki...## Submitted by Waqar Hameed
Assigned to **D-Bus Maintainers**
**[Link to original bug (#108271)](https://bugs.freedesktop.org/show_bug.cgi?id=108271)**
## Description
Lennart Poettering advised me to file a bug here for the wiki page regarding a missing sd-bus C++ wrapper library. Please see the attached mail conversation below:
>> Hi!
>>
>>
>> You have a nice collection of sd-bus wrappers for different
>> languages at
>> https://www.freedesktop.org/wiki/Software/DBusBindings/. I was just
>> wondering if there is any reasons for why you have not included
>> sdbusplus (https://github.com/openbmc/sdbusplus)??
> Consider filing a bug against the dbus project, as that wiki page is
> maintained as part of that.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
Thank you!https://gitlab.freedesktop.org/dbus/dbus/-/issues/220--enable-relocation support breaks assumptions made by mingw32-install-post.sh2018-11-15T13:29:45ZBugzilla Migration User--enable-relocation support breaks assumptions made by mingw32-install-post.sh## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107662)](https://bugs.freedesktop.org/show_bug.cgi?id=107662)**
## Description
Created attachment 141245
fix-order-of-dbus-1.pc...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107662)](https://bugs.freedesktop.org/show_bug.cgi?id=107662)**
## Description
Created attachment 141245
fix-order-of-dbus-1.pc.patch
Cross building dbus from git master with autotools for windows fails because of two issues
1.cross pkg-config 0.28 is confused to not have prefix= in the first line of dbus-1.pc
2. relocation support in configure.ac does not recognize --exec_prefix expanded to ${prefix} and --libdir to ${prefix}/lib
For both issues a related patch has been appended.
~~**Patch 141245**~~, "fix-order-of-dbus-1.pc.patch":
[fix-order-of-dbus-1.pc.patch](/uploads/711e79dd42873d93b2ef29685083b6b4/fix-order-of-dbus-1.pc.patch)
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/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/217Set default system bus socket address on ./configure to /run/dbus/system_bus_...2018-10-15T13:18:28ZBugzilla Migration UserSet default system bus socket address on ./configure to /run/dbus/system_bus_socket## Submitted by Dilian
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107192)](https://bugs.freedesktop.org/show_bug.cgi?id=107192)**
## Description
Doing systemd-239/meson && ninja install uses as bus socket address ...## Submitted by Dilian
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107192)](https://bugs.freedesktop.org/show_bug.cgi?id=107192)**
## Description
Doing systemd-239/meson && ninja install uses as bus socket address /run/dbus/system_bus_socket .
Doing dbus-1.12.8/configure prints:
System bus socket: /usr/local/var/run/dbus/system_bus_socket
System bus address: unix:path=/usr/local/var/run/dbus/system_bus_socket
Please adjust the defaults to match the systemd defaults on this parameter, see https://github.com/systemd/systemd/issues/9547 for discussion on systemd's side.
Note, there it is suggested to make the system bus address unconfigurable.
If you don't agree on any of this write in the documentation explictly that systemd and dbus have to be tweaked explicitly on the session bus address in order to work together.
Version: 1.12https://gitlab.freedesktop.org/dbus/dbus/-/issues/215Why does ListActivatableNames say o.fd.DBus is activatable?2018-10-15T13:21:11ZBugzilla Migration UserWhy does ListActivatableNames say o.fd.DBus is activatable?## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107024)](https://bugs.freedesktop.org/show_bug.cgi?id=107024)**
## Description
Ever since ListActivatableNames() was added, it has included...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107024)](https://bugs.freedesktop.org/show_bug.cgi?id=107024)**
## Description
Ever since ListActivatableNames() was added, it has included "org.freedesktop.DBus" as an activatable name:
commit 7628b541258d906e27e2000a402ed2d02383479c
Author: John (J5) Palmieri <johnp@redhat.com>
Date: 2006-07-14 01:17:59 +0000
* bus/activation.[ch] (bus_activation_list_services): new function to
get the list of services that can be activated
...
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,16 @@
+2006-07-13 Carlos Garcia Campos <carlosgc@gnome.org>
+
+ * bus/activation.[ch] (bus_activation_list_services): new function to
+ get the list of services that can be activated
...
--- a/bus/driver.c
+++ b/bus/driver.c
...
+ /* Include the bus driver in the list */
+ const char *v_STRING = DBUS_SERVICE_DBUS;
+ if (!dbus_message_iter_append_basic (&sub, DBUS_TYPE_STRING,
+ &v_STRING))
+ {
+ dbus_free_string_array (services);
+ dbus_message_unref (reply);
+ BUS_SET_OOM (error);
+ return FALSE;
+ }
This doesn't make a whole lot of sense to me: by calling ListActivatableNames() successfully, you've proved that o.fd.DBus exists, which means it's irrelevant whether it is activatable or not.
Does anyone know why it gets returned here? I think it would make sense in ListNames(), but not in ListActivatableNames().
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/214Drop chdir("/") in dbus-launch2018-11-19T15:42:21ZBugzilla Migration UserDrop chdir("/") in dbus-launch## Submitted by David King
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106987)](https://bugs.freedesktop.org/show_bug.cgi?id=106987)**
## Description
In RHEL 7, Paul Gozart came across some unexpected behaviour in...## Submitted by David King
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106987)](https://bugs.freedesktop.org/show_bug.cgi?id=106987)**
## Description
In RHEL 7, Paul Gozart came across some unexpected behaviour in gedit when run as a regular user, where the save dialog used the root path ("/") as the default location. This was traced down by Ray Strode to gedit in newer RHEL 7 versions being launched by dbus activation (as most GNOME applications are, if they use GApplication), and the dbus-daemon used for the session bus in RHEL being launched with dbus-launch (by gnome-session, as systemd is not used as a user session manager in RHEL 7).
There is a chdir("/") call in dbus-launch with the following justification:
/* We chdir ("/") since we are persistent and daemon-like, and fork
* again so dbus-launch can reap the parent. However, we don't
* setsid() or close fd 0 because the idea is to remain attached
* to the tty and the X server in order to kill the message bus
* when the session ends.
*/
Arguably, this is not the best behaviour for a tool that is only used to run session buses, which are scoped to the lifetime of the user's session (with some exceptions, of course), and given the pervasive use of dbus-launch by session managers to start dbus-daemon as a session bus, I think that it is best to drop the chdir() call entirely.
Version: git master
### See also
* https://bugzilla.redhat.com/show_bug.cgi?id=1470310https://gitlab.freedesktop.org/dbus/dbus/-/issues/213Failed to connect to bus: Connection refused2018-10-12T21:34:59ZBugzilla Migration UserFailed to connect to bus: Connection refused## Submitted by ali
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106874)](https://bugs.freedesktop.org/show_bug.cgi?id=106874)**
## Description
I don't know where is the root cause of problem. So I decided to report...## Submitted by ali
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106874)](https://bugs.freedesktop.org/show_bug.cgi?id=106874)**
## Description
I don't know where is the root cause of problem. So I decided to report this bug in two places (systemD[github.com] + dbus[bugs.freedesktop.org]).
https://github.com/systemd/systemd/issues/9248
Thanks in advancehttps://gitlab.freedesktop.org/dbus/dbus/-/issues/212API design guidelines give ambiguous advice about coping with old versions2018-10-15T13:22:58ZBugzilla Migration UserAPI design guidelines give ambiguous advice about coping with old versions## Submitted by Simon McVittie
Assigned to **Philip Withnall**
**[Link to original bug (#106862)](https://bugs.freedesktop.org/show_bug.cgi?id=106862)**
## Description
https://dbus.freedesktop.org/doc/dbus-api-design.html#api-vers...## Submitted by Simon McVittie
Assigned to **Philip Withnall**
**[Link to original bug (#106862)](https://bugs.freedesktop.org/show_bug.cgi?id=106862)**
## Description
https://dbus.freedesktop.org/doc/dbus-api-design.html#api-versioning says:
> New API can be added to a D-Bus interface without incrementing the version
> number, as such additions are still backwards-compatible. However, clients
> should gracefully handle the org.freedesktop.DBus.Error.UnknownMethod error
> reply from all D-Bus method calls if they want to run against older versions
> of the service which don’t implement new methods. (This also prevents use of
> generated bindings; any method which a client wants to gracefully fall back
> from should be called using a generic D-Bus method invocation rather than a
> specific generated binding.)
I'm not sure why it says that? Code generated by, for example, gdbus-codegen or (ugh) dbus-binding-tool from a local copy of some API v1.23 should interoperate fine with a service implementing some API v1.0 (assume semantic versioning here). The generated methods will raise UnknownMethod as usual.
The uses of generated bindings that *would* be a problem are those where the generated binding is external to the client, or where the binding is generated from interface definitions that are external to the client. Philip, are those situations the ones you had in mind? I think we should clarify this.
Let's say a client calls methods on a service that implements an API, and ideally it wants to call DoThingsWithOptions() (introduced in com.example.Something1 v1.23), falling back to DoThings() if DoThingsWithOptions() isn't implemented. Assume that service v1.x implements com.example.Something1 v1.x, and assume GDBus (the same considerations would apply to dbus-glib or QtDBus, with appropriate relabelling). There are several ways the client could call the method:
(A) Service ships a library containing gdbus-codegen-generated bindings for
its version of com.example.Something1. Client calls methods from that
library.
- Client needs to be compiled against library v1.23 or later
- Client has a strong dependency on library v1.23 or later at
runtime, unless statically linked (if the library is not present,
the client won't even start)
- Client has a weak dependency on service v1.0 or later at runtime
(if the service is not present, the relevant feature won't work
but the client will still run)
(B) Service ships com.example.Something1.xml in /usr/share/dbus-1/interfaces.
Client runs gdbus-codegen to generate private bindings which are
built into the client.
- Client needs to be compiled against library v1.23 or later
- Client only needs service v1.0 or later at runtime
(C) Client ships a private copy of com.example.Something1.xml and uses
it to generate private bindings which are built into the client.
- No build-time dependency
- Client has a weak dependency on service v1.0 or later at runtime
(D) Client uses g_dbus_connection_call() or equivalent to call at least
DoThingsWithOptions(), and perhaps both methods.
- No build-time dependency
- Client has a weak dependency on service v1.0 or later at runtime
For tightly-coupled components where it's OK for a new client to get a hard dependency on a new service, like xdg-desktop-portal-gtk depending on xdg-desktop-portal, cases (A) or (B) are fine.
For loosely-coupled components where graceful fallbacks and backwards compatibility are needed, I would personally recommend (C) if the interface is of a significant size, or (D) if the interface is small and simple.
Note that it is not OK to expose the generated bindings in case (B) as part of a library, because their API would change unpredictably, depending on the precise version of the service that the client is compiled against. It would be OK to expose the generated bindings in case (C) as part of a library.
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/209[PATCH] bus: Mark service as requiring nss-user-lookup.target2018-10-15T13:24:08ZBugzilla Migration User[PATCH] bus: Mark service as requiring nss-user-lookup.target## Submitted by Jonathan Lebon
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106339)](https://bugs.freedesktop.org/show_bug.cgi?id=106339)**
## Description
Created attachment 139253
[PATCH] bus: Mark service as requi...## Submitted by Jonathan Lebon
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106339)](https://bugs.freedesktop.org/show_bug.cgi?id=106339)**
## Description
Created attachment 139253
[PATCH] bus: Mark service as requiring nss-user-lookup.target
My motivation for this patch is that I'm trying to use sssd on Fedora as a replacement for nss-altfiles (briefly: on Fedora Atomic Host, system users are stored in /usr/lib/passwd to be compatible with ostree's 3-way merge of /etc -- for more info, see [1]). The issue is that there is no clear ordering between the sssd and dbus units at boot time. So if during boot, dbus is started *before* sssd, then it will fail to resolve usernames and block convergence towards multi-user.target.
This patch ensures that dbus is started strictly after we reach the nss-user-lookup.target, which sssd symmetrically marks in its `Before=`. (Obviously, this patch is also useful for other services like sssd which provide name resolution).
[1] https://github.com/pbrezina/authselect/issues/48
~~**Patch 139253**~~, "[PATCH] bus: Mark service as requiring nss-user-lookup.target":
[0001-bus-Mark-service-as-requiring-nss-user-lookup.target.patch](/uploads/fbb47f9180548a99eb0aacf1a50e4867/0001-bus-Mark-service-as-requiring-nss-user-lookup.target.patch)
Version: 1.12https://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/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/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/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/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/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/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/199Fix dbus-send not returning an error exit code in case an error occured and -...2018-10-15T13:28:21ZBugzilla Migration UserFix dbus-send not returning an error exit code in case an error occured and --print-reply is not set## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105380)](https://bugs.freedesktop.org/show_bug.cgi?id=105380)**
## Description## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105380)](https://bugs.freedesktop.org/show_bug.cgi?id=105380)**
## Descriptionhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/197Documentation tutorial2018-10-15T13:29:50ZBugzilla Migration UserDocumentation tutorial## Submitted by Dilian
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104947)](https://bugs.freedesktop.org/show_bug.cgi?id=104947)**
## Description
This is an Introduction to DBus: https://www.freedesktop.org/wiki/In...## Submitted by Dilian
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104947)](https://bugs.freedesktop.org/show_bug.cgi?id=104947)**
## Description
This is an Introduction to DBus: https://www.freedesktop.org/wiki/IntroductionToDBus/
This is a Tutorial to DBus: https://dbus.freedesktop.org/doc/dbus-tutorial.html .
Together they are confusing and repeat each other.
The former
* shall contain a reference to the later,
* In Buses-section, 2nd paragraph, state that DCOP was used in KDE up to version 3
* In the Proxies-section I propose changing the beginning to "Objects on the other end on the bus can be accessed..." to be the opposite of the section in the Objects-section "One end of any exchange on a bus will always be a ... called an onject". So at the end the documentation shall read "one end is object, other end is proxy", except I don't understood things correctly.
* Section 'Signals' first paragraph, third sentence. I propose inserting the work "proxy", so that it reads "Client processes (proxies) can register an interest..." to make clear that a client process is the same as proxy.