dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2022-05-13T01:35:52Zhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/70Need to provide standardized way to disable services started by dbus2022-05-13T01:35:52ZBugzilla Migration UserNeed to provide standardized way to disable services started by dbus## Submitted by bas..@..oo.com
Assigned to **D-Bus Maintainers**
**[Link to original bug (#50955)](https://bugs.freedesktop.org/show_bug.cgi?id=50955)**
## Description
Currently there does not appear to be any official, documented...## Submitted by bas..@..oo.com
Assigned to **D-Bus Maintainers**
**[Link to original bug (#50955)](https://bugs.freedesktop.org/show_bug.cgi?id=50955)**
## Description
Currently there does not appear to be any official, documented way to control which services dbus starts at launch. The only methods to disable a service right now are fairly hackish and don't survive a package upgrade/reinstall. These methods are to rename, or remove the .service file (normally located at /usr/share/dbus-1/services). Also, when removing the file, any future frontend for controlling dbus services won't be able to suggest the service for re-enabling, as the .service file is no longer there.
I suggest adding an extra key to the service file 'Enabled=' with possible values 'Yes' or 'No'. The key should be optional and default to Yes if not found, so existing .service files will still work. Obviously dbus needs to be changed to parse this key, and respect its value.
I also suggest an optional key 'Description=' so service providers can describe what the service does. This description could then be read by a possible frontend and shown to users considering disabling a service.
Thanks,
Bas Timmer
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/46use runtime dirs for ~/.dbus autolaunch crap2020-07-28T01:06:38ZBugzilla Migration Useruse runtime dirs for ~/.dbus autolaunch crap## Submitted by wil..@..il.com
Assigned to **D-Bus Maintainers**
**[Link to original bug (#35887)](https://bugs.freedesktop.org/show_bug.cgi?id=35887)**
## Description
Modern systems are using /run for system service sockets and /...## Submitted by wil..@..il.com
Assigned to **D-Bus Maintainers**
**[Link to original bug (#35887)](https://bugs.freedesktop.org/show_bug.cgi?id=35887)**
## Description
Modern systems are using /run for system service sockets and /run/user for user agent sockets. It might be worth considering this for dbus as well.
I suppose this would be something like:
/run/dbus for the system bus
/run/$USER/dbus for the session bus
The latter should probably use the http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html XDG_RUNTIME_DIR.
Version: 1.5https://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/416Change default session bus listen address from tmpdir (abstract) to dir (path...2022-10-05T13:49:01ZSimon McVittieChange default session bus listen address from tmpdir (abstract) to dir (path-based) for better interop with sandboxesOn Linux, there are two categories of `AF_UNIX` socket: abstract and path-based.
Path-based sockets are the same as the `AF_UNIX` sockets on non-Linux platforms like *BSD. They behave a lot like files: sandboxing/container frameworks ca...On Linux, there are two categories of `AF_UNIX` socket: abstract and path-based.
Path-based sockets are the same as the `AF_UNIX` sockets on non-Linux platforms like *BSD. They behave a lot like files: sandboxing/container frameworks can choose to share them, or not, as they wish (just like any other file, including devices, fifos and other pseudo-files). The main down-side of a path-based socket is that it isn't automatically cleaned up when there is no longer a process listening on it, but we already have code to clean up path-based sockets when the dbus-daemon or another `DBusServer` terminates gracefully (and we already rely on that code for non-Linux platforms like *BSD, which don't have abstract sockets at all).
Abstract sockets behave like TCP, but with an arbitrary string instead of an IP address and port. Confusingly, the way they're used in dbus, the arbitrary string looks like a path (but it isn't). If a sandboxed/containerized application shares the network namespace with the host system, then it can access any abstract socket, which is often a potential sandbox escape. Conversely, because the abstract socket doesn't exist at the filesystem level, if a sandboxed/containerized application *doesn't* share the network namespace with the host system, the sandboxing/container framework can't bind-mount it into the container if sharing it is desirable.
This is particularly problematic for the well-known D-Bus session bus: if a sandboxed application can connect to the well-known D-Bus session bus, then that's a sandbox escape. Unfortunately, for historical reasons, our default listening address for a session bus started by `dbus-launch` or `dbus-user-session` is `unix:tmpdir=/tmp` which prefers to use an abstract socket.
On Linux systems with `systemd --user` that configure dbus with `--enable-user-session` (such as Arch, and Debian/Ubuntu with the default `dbus-user-session` package), the session bus listens on a path-based socket and there is usually no problem - unless you run `dbus-launch` or `dbus-run-session` manually.
Similarly, on non-Linux systems, there is no problem, because abstract sockets don't exist.
The systems where this *is* a problem are Linux systems where either a non-systemd init system is in use, or the distro or sysadmin has explicitly disabled the user bus and enabled the traditional per-X11-display session bus (for example removing `dbus-user-bus` and installing `dbus-x11` on Debian/Ubuntu), or the user has explicitly run `dbus-launch` or `dbus-run-session`.
I think we should seriously consider changing the default listening address for the session bus to `unix:dir=/tmp`, which was added in dbus 1.12.x (the oldest supported branch of dbus) and always uses path-based sockets.
If distributions want to do this "early" or in a branch where this change has not been made, they can configure with `--with-dbus-session-bus-listen-address=unix:dir=/tmp`.
/cc @thiago @mcatanzarohttps://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/449The `$XDG_RUNTIME_DIR/bus` fallback2023-10-24T11:14:02ZHugoThe `$XDG_RUNTIME_DIR/bus` fallbackI've noticed that some implementations (including the on in this repository) use `$XDG_RUNTIME_DIR/bus` as a fallback when `$DBUS_SESSION_BUS_ADDRESS` is unset. I don't see this mentioned in the D-Bus specification, but having a well-kno...I've noticed that some implementations (including the on in this repository) use `$XDG_RUNTIME_DIR/bus` as a fallback when `$DBUS_SESSION_BUS_ADDRESS` is unset. I don't see this mentioned in the D-Bus specification, but having a well-known fallback like this is very convenient.
I think it might be a good idea to add a note on this fallback to [the relevant section of the dbus spec](https://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-types) and make it part of the standard.https://gitlab.freedesktop.org/dbus/dbus/-/issues/3501.14 release2022-02-28T20:39:35ZMarkus Teich1.14 releaseAre there plans or an ETA for the 1.14 release yet?Are there plans or an ETA for the 1.14 release yet?https://gitlab.freedesktop.org/dbus/dbus/-/issues/337systemd and dbus sometimes disagree about whether the system bus connection h...2021-07-07T08:15:24ZIain Lanesystemd and dbus sometimes disagree about whether the system bus connection has authenticatedThis is related to, possibly the same as, https://github.com/systemd/systemd/issues/15316 and the LP bug is https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1871538. I'm not confident we aren't observing two issues though. Here I'll t...This is related to, possibly the same as, https://github.com/systemd/systemd/issues/15316 and the LP bug is https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1871538. I'm not confident we aren't observing two issues though. Here I'll talk about "Connection has not authenticated soon enough, closing it" which we're most recently observing with Azure instances running Ubuntu 21.04.
In these logs I'm using systemd 248.3-1ubuntu1 and dbus-daemon 1.12.20-2ubuntu1 compiled with verbose messages and running with `DBUS_VERBOSE=1`, but we managed to reproduce without. Actually adding `DBUS_VERBOSE=1` seems to make the issue a bit easier to hit, so maybe it's a race which is easier to lose under load.
What happens is that "sometimes" on boot all Type=dbus services have failed to start (resp. the other case: when dist-upgrading, all running Type=dbus service units lose their bus connection and get torn down).
In the logs when this has happened I can observe the following:
```
laney@dev> egrep "(bus-api-system|soon enough|Connection terminated)" journal-sorted.log
Jun 17 09:23:59.399376 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state UNSET → OPENING
Jun 17 09:23:59.399391 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: sd-bus: starting bus bus-api-system by connecting to /run/dbus/system_bus_socket...
Jun 17 09:23:59.399429 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state OPENING → AUTHENTICATING
Jun 17 09:23:59.808194 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state AUTHENTICATING → HELLO
Jun 17 09:24:09.255136 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state HELLO → RUNNING
Jun 17 09:25:06.580618 alan-hirsute-base-jzwgzzozgdyqauuqajbr dbus-daemon[610]: [system] Connection has not authenticated soon enough, closing it (auth_timeout=30000ms, elapsed: 53691ms)
Jun 17 09:25:09.221680 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state RUNNING → CLOSING
Jun 17 09:25:09.221741 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: polkit.service: Unexpected error response from GetNameOwner(): Connection terminated
Jun 17 09:25:09.221799 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state CLOSING → CLOSED
# here it starts working AFAICS
Jun 17 09:26:14.221908 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state UNSET → OPENING
Jun 17 09:26:14.221921 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: sd-bus: starting bus bus-api-system by connecting to /run/dbus/system_bus_socket...
Jun 17 09:26:14.221978 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state OPENING → AUTHENTICATING
Jun 17 09:26:14.229261 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state AUTHENTICATING → HELLO
Jun 17 09:26:14.245763 alan-hirsute-base-jzwgzzozgdyqauuqajbr systemd[1]: Bus bus-api-system: changing state HELLO → RUNNING
```
[I've attached the full log here.](/uploads/bbc13facc5f01ba6f76d8b71824a3060/journal-sorted.log.xz) I can't see from the super verbose dbus-daemon logging whether systemd is wrong when it thinks it authenticated or not. Maybe a maintainer could peruse and advise if this seems to be systemd or dbus having a problem?
(I've had to re-sort the attached log by the way; while dbus-daemon and systemd's messages were correctly ordered with respect to themselves, they were interleaved wrong in the journal output, although it seems to have correct timestamps, so not sure what that's about really.)https://gitlab.freedesktop.org/dbus/dbus/-/issues/325feature request : adding meson build system2022-07-14T10:58:23Zvtorrifeature request : adding meson build systemHello
i would like to know if you (the devs) are considering adding a meson build system.
thank youHello
i would like to know if you (the devs) are considering adding a meson build system.
thank youhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/301dbus-monitor gets disconnected by dbus-broker for trying to send a message2022-10-11T11:45:12ZWill Thompsondbus-monitor gets disconnected by dbus-broker for trying to send a messageWhile smoke-testing Bustle on a Fedora 32 computer I noticed that `dbus-monitor` sometimes gets abruptly disconnected from the bus. I found the following in the journal:
```
May 20 23:26:09 gelf dbus-broker[2628]: Monitor :1.311 is bein...While smoke-testing Bustle on a Fedora 32 computer I noticed that `dbus-monitor` sometimes gets abruptly disconnected from the bus. I found the following in the journal:
```
May 20 23:26:09 gelf dbus-broker[2628]: Monitor :1.311 is being disconnected as it attempted to send a message.
```
Sure enough, strace confirms that it's trying to send a message:
```
$ strace -e write=3 dbus-monitor --pcap >ohno.pcap
...
sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\2\1\1\0\0\0\0\3\0\0\0\30\0\0\0\6\1s\0\6\0\0\0:1.322\0\0"..., iov_len=40}, {iov_base="", iov_len=0}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 40
* 40 bytes in buffer 0
| 00000 6c 02 01 01 00 00 00 00 03 00 00 00 18 00 00 00 l............... |
| 00010 06 01 73 00 06 00 00 00 3a 31 2e 33 32 32 00 00 ..s.....:1.322.. |
| 00020 05 01 75 00 12 00 00 00 ..u..... |
```
Deserializing this with `GDBusMessage` gives:
```
Type: method-return
Flags: no-reply-expected
Version: 0
Serial: 3
Headers:
reply-serial -> uint32 18
destination -> ':1.322'
Body: ()
UNIX File Descriptors:
(none)
```
Rather suspiciously, the last few messages in the pcap file are:
1. AddMatch from :1.322 to org.freedesktop.DBus, serial 17
2. org.freedesktop.DBus responding to that method call
3. org.freedesktop.DBus responding to the invisible call with serial 18
4. org.freedesktop.DBus.Local.Disconnected
That's as far as I got. :(https://gitlab.freedesktop.org/dbus/dbus/-/issues/265Autotools build fails with Makefile:1083: *** missing separator. Stop2020-02-20T13:15:57ZRalf HabackerAutotools build fails with Makefile:1083: *** missing separator. StopAfter applying the patch mentioned at #261 the build fails with
```
Makefile:1083: *** missing separator. Stop
```
The reason is an unexpanded variable:
```
Makefile
1082: # Add rules for code-coverage testing, as defined by AX_CODE...After applying the patch mentioned at #261 the build fails with
```
Makefile:1083: *** missing separator. Stop
```
The reason is an unexpanded variable:
```
Makefile
1082: # Add rules for code-coverage testing, as defined by AX_CODE_COVERAGE
1083: @CODE_COVERAGE_RULES@
```
[_log.txt](/uploads/488bdc63e81384c59afd283bd9a02377/_log.txt)https://gitlab.freedesktop.org/dbus/dbus/-/issues/249autoconf fails with autoconf-archive v2019.01.062022-05-27T03:01:41ZMichael Gilbertautoconf fails with autoconf-archive v2019.01.06Running autoreconf in the dbus source tree with autoconf-archive v2019.01.06 installed produces the following error:
```
***** autoconf *****
***** PWD: /var/tmp/portage/sys-apps/dbus-1.12.12/work/dbus-1.12.12
***** autoconf --force
co...Running autoreconf in the dbus source tree with autoconf-archive v2019.01.06 installed produces the following error:
```
***** autoconf *****
***** PWD: /var/tmp/portage/sys-apps/dbus-1.12.12/work/dbus-1.12.12
***** autoconf --force
configure:18977: error: Unexpanded AX_ macro found. Please install GNU autoconf-archive
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
```
It looks like it is catching a shell variable named AX_CHECK_GNU_MAKE_HEADLINE from ax_check_gnu_make.m4.
http://git.savannah.nongnu.org/cgit/autoconf-archive.git/tree/m4/ax_check_gnu_make.m4?h=v2019.01.06#n83
Downstream bug report: https://bugs.gentoo.org/674830https://gitlab.freedesktop.org/dbus/dbus/-/issues/195libdbus client should try "AUTH EXTERNAL\r\n" first?2022-11-21T15:11:13ZBugzilla Migration Userlibdbus client should try "AUTH EXTERNAL\r\n" first?## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104589)](https://bugs.freedesktop.org/show_bug.cgi?id=104589)**
## Description
While documenting how the EXTERNAL auth mechanism works (on ...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104589)](https://bugs.freedesktop.org/show_bug.cgi?id=104589)**
## Description
While documenting how the EXTERNAL auth mechanism works (on Bug #104224), I found out that dbus-daemon has in fact always supported the empty string as an authorization identity. This means "I am whoever the kernel says I am", which is the behaviour we actually want.
This is clearly superior to what all practical D-Bus clients currently do, which is to send getuid() or geteuid(), so something like "I am uid 1000, please ask the kernel for confirmation". In particular, if the client is in a non-init uid namespace on Linux, then the uid it gets from geteuid() might not match what the dbus-daemon in the init namespace thinks its effective uid is.
One complication is that this will break interoperability with D-Bus server implementations whose authors didn't know this was meant to work (notably GDBus).https://gitlab.freedesktop.org/dbus/dbus/-/issues/179Add message ordering guarantees to the D-Bus specification2024-03-15T12:40:58ZBugzilla Migration UserAdd message ordering guarantees to the D-Bus specification## Submitted by Philip Withnall
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101563)](https://bugs.freedesktop.org/show_bug.cgi?id=101563)**
## Description
The specification doesn’t actually state what ordering guar...## Submitted by Philip Withnall
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101563)](https://bugs.freedesktop.org/show_bug.cgi?id=101563)**
## Description
The specification doesn’t actually state what ordering guarantees it provides about messages. Currently, dbus-daemon guarantees that all peers will see messages from connection C in the order that they were received by the daemon from peer C (if they are to see those messages at all). (This phrasing might be wrong and needs clarification.)
Given that plenty of bits of software depend on those ordering guarantees, and that we would consider any message bus implementation which *doesn’t* provide them to be wrong, it’s probably appropriate to add them to the spec.
Version: git masterhttps://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/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/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/5021.14.10: test suite fails in run-test unit2024-03-13T04:08:43ZTomasz Kłoczko1.14.10: test suite fails in run-test unitLooks like something is wrong and test suite fails in one unit
```
+ /usr/bin/make -O -j48 V=1 VERBOSE=1 check -j1
+ Xvfb :42 -nolisten tcp -auth /dev/null
Making check in dbus
make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/d...Looks like something is wrong and test suite fails in one unit
```
+ /usr/bin/make -O -j48 V=1 VERBOSE=1 check -j1
+ Xvfb :42 -nolisten tcp -auth /dev/null
Making check in dbus
make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/dbus-dbus-1.14.10/dbus'
/usr/bin/make check-am
[..]
make[4]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/dbus-dbus-1.14.10/test'
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/dbus-dbus-1.14.10/test'
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/dbus-dbus-1.14.10/test'
Making check in name-test
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/dbus-dbus-1.14.10/test/name-test'
/usr/bin/make check-TESTS
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/dbus-dbus-1.14.10/test/name-test'
make[4]: Entering directory '/home/tkloczko/rpmbuild/BUILD/dbus-dbus-1.14.10/test/name-test'
FAIL: run-test.sh 1 test-autolaunch
PASS: run-test-systemserver.sh 1 test-expected-echo-fail --print-reply --dest=org.freedesktop.DBus.TestSuiteEchoService /org/freedesktop/TestSuite org.freedesktop.TestSuite.Echo string:hi (Saw "DBus.Error" in output as expected)
[..]
=================================================
dbus 1.14.10: test/name-test/test-suite.log
=================================================
# TOTAL: 217
# PASS: 216
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: run-test
==============
1..1
*** Failed to autolaunch session bus: /home/tkloczko/rpmbuild/BUILD/dbus-dbus-1.14.10/tools/dbus-launch terminated abnormally with the following error: Autolaunch error: X11 initialization failed.
# running test test-autolaunch
# exit status 1
not ok 1 test-autolaunch
FAIL: run-test.sh 1 test-autolaunch
============================================================================
Testsuite summary for dbus 1.14.10
============================================================================
# TOTAL: 217
# PASS: 216
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
See test/name-test/test-suite.log
Please report to https://gitlab.freedesktop.org/dbus/dbus/issues
============================================================================
```
Please let me know if you need more details.https://gitlab.freedesktop.org/dbus/dbus/-/issues/501spec: unneccessary requirement in [message-protocol-marshaling-object-path]2024-03-13T08:42:07ZMarc Mutzspec: unneccessary requirement in [message-protocol-marshaling-object-path]In [message-protocol-marshaling-object-path], if no slash-separated element may be an empty string as per the preceding bullet point, unless it's the root (/) as per the following bullet point, then it already follows that consecutive sl...In [message-protocol-marshaling-object-path], if no slash-separated element may be an empty string as per the preceding bullet point, unless it's the root (/) as per the following bullet point, then it already follows that consecutive slashes cannot happen. There's no need to spell this out.https://gitlab.freedesktop.org/dbus/dbus/-/issues/500support for type signed 8-bit integer2024-02-23T18:34:33ZSimon Gleissnersupport for type signed 8-bit integer## Is your feature request related to a problem? Please describe.
I am currently designing a C++ framework for remote procedure calls. It consists of 2 parts:
- a frontend, based on standard C++ types (e.g. int32_t, std::string, std::ve...## Is your feature request related to a problem? Please describe.
I am currently designing a C++ framework for remote procedure calls. It consists of 2 parts:
- a frontend, based on standard C++ types (e.g. int32_t, std::string, std::vector<>, std::tuple<>, std::variant<>, etc.)
- a backend, for transport or protocol generation, which shall be configurable (D-Bus, ASN.1, JSON, XML, etc.).
It is clear that backends may not support all frontend data types. One example here is D-Bus, as there is no signed 8-bit integer defined (see: https://dbus.freedesktop.org/doc/dbus-specification.html#basic-types ).
The current solution is to throw a compile-time assertion when int8_t is used as a type with D-Bus. Internal/hidden casting to another type would not be type-safe.
## Describe the solution you'd like
D-Bus support for signed 8-bit integer. I do understand that this would mean an ABI extension, so I consider this ticket to be a long-term change for v2.
## Describe alternatives you've considered
- Forbid usage of int8_t when using the library with D-Bus.
- I have asked at [StackOverflow](https://stackoverflow.com/questions/76994493/d-bus-type-safe-usage-of-signed-8-bit-integers) half a year ago, if someone might know an alternative, but without success.
## Additional context
There are several reserved types in the D-Bus specification (e.g. a 'maybe' type, which seems to match C++ std::optional<>). Perhaps it's time for a makeover after about 20 years.