dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2018-10-15T13:22:58Zhttps://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/210Containers (#171): Last chance to change instance ID from 'o' to 'x'2023-10-20T12:35:46ZBugzilla Migration UserContainers (#171): Last chance to change instance ID from 'o' to 'x'One of the review comments on implementations of #171 that led to that issue stalling indefinitely was that some reviewers would prefer the container instance ID to be an opaque integer, probably `dbus_uint64_t` (`x`), rather than an obj...One of the review comments on implementations of #171 that led to that issue stalling indefinitely was that some reviewers would prefer the container instance ID to be an opaque integer, probably `dbus_uint64_t` (`x`), rather than an object path.
See https://bugs.freedesktop.org/show_bug.cgi?id=106712 for the original discussion of this in a somewhat readable form (comments that were copied into this automatically-imported issue are not very readable).
We are constrained by some of the original implementation of Containers having been released in dbus 1.14.x. That version includes:
* `DBUS_HEADER_FIELD_CONTAINER_INSTANCE`, with value 10
* `dbus_bool_t dbus_message_set_container_instance(DBusMessage *, const char *)`
* `const char *dbus_message_get_container_instance (DBusMessage *)`
* The `const char *` in those C functions is documented as being an object path
So if we are going to convert the object path into an integer, we need to figure out a way to deprecate those and introduce an integer replacement.
We also should not make this change unless we have serious plans to introduce the ability to match signals against integers (#478).
@smcv is not particularly interested in this change, and so will not be working on it. If someone else wants this change, this is their chance to step forward to implement it.
## Deadline
If there is no substantial movement on this by the end of September 2023, then @smcv intends to reject this change and keep the container instance ID being an object path.
## Dependencies
@smcv will not accept this change unless someone (presumably someone who wanted this) steps forward to implement #478. It does not necessarily need to be finished before making this change.
/cc @dvdhrm @desrthttps://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/208[PATCH] Fix is_valid_section_name always returning true2019-04-17T12:38:26ZBugzilla Migration User[PATCH] Fix is_valid_section_name always returning true## Submitted by Albert Astals Cid
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106183)](https://bugs.freedesktop.org/show_bug.cgi?id=106183)**
## Description
Created attachment 138992
The said patch
The if conditio...## Submitted by Albert Astals Cid
Assigned to **D-Bus Maintainers**
**[Link to original bug (#106183)](https://bugs.freedesktop.org/show_bug.cgi?id=106183)**
## Description
Created attachment 138992
The said patch
The if condition was
if (!((*name >= 'A' && *name <= 'Z') || (*name >= 'a' || *name <= 'z') ||
*name == '\n' || *name == '\t'))
which translates to
if ((!(*name >= 'A' && *name <= 'Z') && !(*name >= 'a' || *name <= 'z') &&
*name != '\n' && *name != '\t'))
which translates to
if (((*name < 'A' || *name > 'Z') && (*name < 'a' && *name > 'z') &&
*name != '\n' && *name != '\t'))
which will always be false since name can't be both smaller than a and bigger than z
Found by gcc
**Patch 138992**, "The said patch":
[0001-Fix-is_valid_section_name-always-returning-true.patch](/uploads/89d1fee6d582ab258d87d9281cfb561c/0001-Fix-is_valid_section_name-always-returning-true.patch)
Version: git masterhttps://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/200Do CI builds on MSVC using Appveyor or similar2023-08-14T19:00:11ZBugzilla Migration UserDo CI builds on MSVC using Appveyor or similar## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105521)](https://bugs.freedesktop.org/show_bug.cgi?id=105521)**
## Description
We regularly test that dbus builds successfully as a native ...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105521)](https://bugs.freedesktop.org/show_bug.cgi?id=105521)**
## Description
We regularly test that dbus builds successfully as a native build on Linux, and as a cross-compiled mingw64 build for Windows, by pointing Travis-CI to dbus' semi-official Github mirror. We don't do the same for MSVC builds, which makes it hard to be confident that we haven't broken them.
Appveyor seems to be a Windows equivalent of Travis-CI. I've tried to set up a build there for dbus, but so far it isn't working.
Work in progress (probably doesn't work yet): https://github.com/smcv/dbus/commits/appveyor
I don't really know what I'm doing (I've never set up an Appveyor build before) and trial-and-error is rather slower than on Travis-CI, so if someone has used it before, I'd appreciate a fixed version of the build.
Version: git masterhttps://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/198Stop using selinux_set_mapping() function2021-12-17T13:42:06ZBugzilla Migration UserStop using selinux_set_mapping() function## Submitted by Laurent Bigonville
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105330)](https://bugs.freedesktop.org/show_bug.cgi?id=105330)**
## Description
Hi,
ATM, when selinux_set_mapping() fails due to an inc...## Submitted by Laurent Bigonville
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105330)](https://bugs.freedesktop.org/show_bug.cgi?id=105330)**
## Description
Hi,
ATM, when selinux_set_mapping() fails due to an incomplete policy (or no policy at all) dbus-daemon exits even in permissive mode.
This is a bit a problem for people that are developing their policy or for people that need to recover their machines after a miss configuration as dbus-daemon is part of the boot and login process via logind.
I'm actually wondering if that call is needed at all these days. As we could use, I think, avc_context_to_sid(), string_to_security_class() and string_to_av_perm() to get the needed info.
An other solution would be to use selinux_check_access() instead of avc_has_perm() (selinux_check_access() uses avc_has_perm() internally and the function mentioned above internally), the problem is that way we cannot use the cache, I think again, and we might have a performance hit.
selinux_set_mapping() was introduced by:
commit ba088208bc0c35ca418a097a8482c4a7705f4a43
Author: osmond sun <osmond.sun@gmail.com>
Date: Wed Nov 6 00:53:18 2013 +0800
selinux: Use selinux_set_mapping() to avoid hardcoded constants for policy
Previous to the introduction of selinux_set_mapping(), DBus pulled
constants generated from the system's policy at build time. But this
means it's impossible to replace the system policy without rebuilding
userspace components.
This patch maps from arbitrary class/perm indices used by D-Bus and
the policy values and handles all the translation at runtime on
avc_has_perm() calls.
Bug: https://bugs.freedesktop.org/attachment.cgi?id=88719
Reviewed-By: Colin Walters <walters@verbum.org>
Tested-By: Colin Walters <walters@verbum.org>
Version: git masterhttps://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.https://gitlab.freedesktop.org/dbus/dbus/-/issues/196Expose group list from SO_PEERGROUPS in GetConnectionCredentials()2020-01-23T15:16:14ZBugzilla Migration UserExpose group list from SO_PEERGROUPS in GetConnectionCredentials()## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104657)](https://bugs.freedesktop.org/show_bug.cgi?id=104657)**
## Description
+++ This bug was initially created as a clone of Bug #103737...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104657)](https://bugs.freedesktop.org/show_bug.cgi?id=104657)**
## Description
+++ This bug was initially created as a clone of Bug #103737 +++
Recent Linux kernels (4.13+) allow for getting a list of auxiliary groups of a socket peer in a race-free way using the SO_PEERGROUPS getsockopt option. Bug #103737 tracks the use of that option in dbus.
If anyone (maybe polkit?) cares about this information, we could add UnixGroupIDs (ARRAY of UINT32) to GetConnectionCredentials().
If we do, then I think its semantics should be that this field is only present when we can discover the other process' complete list of groups, such as on Linux 4.13+ with SO_PEERGROUPS. On platforms where we can only find the primary group ID (like older Linux with SO_PEERCRED) I don't think we should expose any group information at all, because that's needlessly confusing.
I also don't think the bus API should expose the group list that we get from getgrouplist(), to give callers that care about it a way to distinguish between true facts ("the peer definitely had exactly these groups at the time the connection was established") and conjecture ("the peer has uid 1000 so we think it probably has all the groups that uid 1000 would have if they logged in"). If the caller wants to use the same best-guess via getgrouplist() that older/non-Linux dbus-daemon does, then they can implement that themselves.
Version: git master
### Depends on
* [Bug 103737](https://bugs.freedesktop.org/show_bug.cgi?id=103737)https://gitlab.freedesktop.org/dbus/dbus/-/issues/194Document best practices for usernames in <policy>2018-10-15T13:31:33ZBugzilla Migration UserDocument best practices for usernames in <policy>## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104586)](https://bugs.freedesktop.org/show_bug.cgi?id=104586)**
## Description
Because some NSS mechanisms require network access, and some...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104586)](https://bugs.freedesktop.org/show_bug.cgi?id=104586)**
## Description
Because some NSS mechanisms require network access, and some network access mechanisms like NetworkManager require D-Bus, usernames in the `<policy>` for the dbus-daemon must be resolvable during boot prior to network access becoming available. In practice, this means they must be local (for example nss_files, nss_db, or even nss_systemd's special cases for the root and nobody users).
(In reply to Tom Gundersen on Bug #104224)
> As such, no dbus-based NSS resolution is possible. This is ok
> because we assume any user/group names used in the configuration files are
> given statically in /etc/passwd and friends, rather than resolved over
> something like LDAP (local policy referencing remote users sounds very
> strange). This is not at all obvious, and it is probably something we should
> document better. I'd even propose to add this to the spec if we all agreed.
dbus-daemon's XML configuration language is not (currently) in the scope of the spec, but I'd welcome patches to dbus-daemon(1) that said this.
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/193Add build information for Android platforms2018-10-16T13:19:17ZBugzilla Migration UserAdd build information for Android platforms## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104022)](https://bugs.freedesktop.org/show_bug.cgi?id=104022)**
## Description
DBus for android is required to build several KD...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104022)](https://bugs.freedesktop.org/show_bug.cgi?id=104022)**
## Description
DBus for android is required to build several KDE Frameworks package
on KDE CI system (see
https://phabricator.kde.org/R857:da6f5208d5e087870af2b3d0eeb83941fca500d2
for a list) and there are no related build information.https://gitlab.freedesktop.org/dbus/dbus/-/issues/192Do something about test/data/*-messages/*.message2018-10-15T13:39:44ZBugzilla Migration UserDo something about test/data/*-messages/*.message## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#103758)](https://bugs.freedesktop.org/show_bug.cgi?id=103758)**
## Description
dbus-message-builder was a domain-specific language for buil...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#103758)](https://bugs.freedesktop.org/show_bug.cgi?id=103758)**
## Description
dbus-message-builder was a domain-specific language for building D-Bus message blobs. It was introduced in 2003, and deleted in early 2005 when the type system was rewritten to be fully recursive. (See https://bugs.freedesktop.org/show_bug.cgi?id=103601#c28 for VCS archaeology)
These tests have been diagnosed as "skipped" since the commit that also deleted dbus-message-builder.[ch]:
commit 9d21554dd3b560952cd5aa607c4ec07898c0b260
Author: Havoc Pennington <hp@redhat.com>
Date: 2005-01-23 06:10:07 +0000
2005-01-23 Havoc Pennington <hp@redhat.com>
* dbus/dbus-message-factory.c, dbus/dbus-message-util.c:
get this all working, not many tests in the framework yet though
but even before that, the message builder language was disabled by:
+ if (FALSE) /* Message builder disabled, probably permanently,
+ * I want to do it another way
which was part of this mega-commit:
commit 9c3d566e95c9080f6040c64531b0ccae22bd5d74
Author: Havoc Pennington <hp@redhat.com>
Date: 2005-01-15 07:15:38 +0000
2005-01-15 Havoc Pennington <hp@redhat.com>
* Land the new message args API and type system.
This patch is huge [...]
As a result of the type system having changed, the specific content of these files is probably no longer useful. However, the general concept of loading message blobs with known content and asserting that they do something sensible is potentially a valuable one, so maybe we should rescue some test coverage from them?
If we want a DSL for writing messages, here is a straw-man:
message in xxd format, with comment lines introduced by #
(xxd format is: "%08x: " offset, followed by up to 32 columns of hex
with a space after each group of 4 digits, optionally followed by a
double space and an ignored text-dump of the content)
VALID or INVALID
if VALID, some sort of encoding of the intended message content
(GVariant text serialization?)
if INVALID, the error code we expect to see
Unfortunately it would not really be OK for the "embedded tests" to link GLib for the GVariant text syntax. However, we could do something like this:
* in embedded tests
* load each valid message (optionally with the crazy OOM-simulation),
assert success or OOM
* load each invalid message, assert the expected error code
* in GLib'y modular tests
* load each valid message, assert expected content
I am not going to have time to work on this any time soon, but I'd review patches.
Until this happens, it might make sense to drop the unused code and data files, leaving this bug open - they haven't actually been used since 2005, and it would be trivial to get them back from git history for inspiration.
Version: git master