Socket paths are limited to 107 characters (108 minus string termination) on Linux. See man 7 unix for details, specifically sun_path[108].

This means that the socket path can be at max 107 characters long on Linux. If I give a longer socket path to xdg-dbus-proxy then it doesn't fail to start though. Instead applications that try to use the socket fail as the socket doesn't exist in the expected location.

Please fix xdg-dbus-proxy if the socket path is too long. Note that other Unix systems have an even lower limit: https://unix.stackexchange.com/questions/367008/why-is-socket-path-length-limited-to-a-hundred-chars

Use case: under KDE for an app add an icon to the systray requires that the app be able to own org.kde.StatusNotifierItem-PID-#. To make this work for an app sandboxed by Firejail requires using the .* suffix like so: dbus-user.own org.kde.*. This is giving way too much permission for just the sake of a systray icon.

Proposal: add a * suffix. foo.bar-* would match foo.bar-, foo.bar-baz and foo.bar-baz-quux but not foo.bar, foo.bar.baz or foo.bar.baz.quux. Then Firejail would be able to let a sandboxed app place a systray icon with dbus-user.own org.kde.StatusNotifierItem-*. While not perfect, it would be much less bad than dbus-user.own org.kde.*

Hi there :-)

I was looking at the D-Bus traffic and I noticed that in AuroraOS (which uses xdg-dbus-proxy via firejail) when an application starts up there is a call to ListNames followed by several calls to GetNameOwner and AddMatch -- and this pattern is repeated twice.

After some investigation, I think I know why this happens: whenever a client connects to the xdg-dbus-proxy socket, the proxy makes a ListNames call right after the client has authenticated, and then starts monitoring the services that the client is interested in (according to the filters).

It seems to me, though, that this is not optimal when there are more clients connected to the same proxy (actually in our case the client process is probably just the same one, but it opens different connections -- probably because it's using both Qt and glib implementations of D-Bus, but I haven't investigated this yet), because the filter rules are the same for all clients, so the tracking of the service names should be common, and it could be setup just once.

Please let me know if my current understanding is correct, and what are the options to address this issue; my first thought would be to move this logic to the FlatpakProxy class (including the get_owner_reply and the unique_id_owned_names tables) but I wonder if you are aware of any hidden dragons there.

chrome-extension://bpmcpldpdmajfigpchkicefoigmkfalc/views/app.html

When setting up xdg-dbus-proxy like this:

xdg-dbus-proxy "$DBUS_SESSION_BUS_ADDRESS" "$HOME/dbus" --filter

And running the Jetbrains Toolbox app like this:

DBUS_SESSION_BUS_ADDRESS="unix:path=$HOME/dbus" ./jetbrains-toolbox

dbus-proxy spits out the following message:

** (process:10596): WARNING **: 21:28:17.026: Invalid client serial

And the program hangs for 5-10 minutes before finally picking back up and getting the tray icon to display.

This program uses libayatana-appindicator for its tray icon, but it seems to have awkward behavior regarding this. When it's ran with an invalid DBUS_SESSION_BUS_ADDRESS, the tray icon never appears, but when it's ran against the system bus or a dbus proxy without --filter, the icon appears fine. Running it against the proxy with filtering, but waiting out the timer makes it start up properly and display the tray icon in the end, but it takes a while. All of this is probably a fallback behavior, as there's no StatusNotifier connected to my dbus.

I'm wondering if there's a way to get it to display the tray icon using its fallback GtkStatusIcon functionality, using a dummy proxy to trigger its fallback functionality.

https://github.com/AtomicConductor/conductor_client/blob/master/conductor/tools/update.py

Hi.

Flatpak 1.14.4
Debian GNU/Linux 12 (bookworm)
Wayland

Related: flatpak/flatpak#3386

https://www.intellum.com/privacy-policy

Linux distribution and version

KISS Linux, rolling (source based, close to being LFS)

Flatpak version

1.6.0 and 1.6.1 were both tested

Description of problem

Building Flatpak fails due to dbus-proxy not compiling. This occurs both when using --without-system-dbus-proxy and --with-system-dbus-proxy; in the case of the latter, flatpak/xdg-dbus-proxy fails to compile in the same file.

Here's the text of the error message:

  CC       dbus-proxy/flatpak_dbus_proxy-dbus-proxy.o
dbus-proxy/dbus-proxy.c: In function ‘fd_readall_bytes’:
dbus-proxy/dbus-proxy.c:47:7: error: implicit declaration of function ‘TEMP_FAILURE_RETRY’ [-Werror=implicit-function-declaration]
   47 |   if (TEMP_FAILURE_RETRY (fstat (fd, &stbuf)) != 0)
      |       ^~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[2]: *** [Makefile:4525: dbus-proxy/flatpak_dbus_proxy-dbus-proxy.o] Error 1

When trying to build flatpak/xdg-dbus-proxy, the build fails in about the same spot:

  CC       dbus-proxy.o
dbus-proxy.c: In function ‘fd_readall_bytes’:
dbus-proxy.c:73:7: warning: implicit declaration of function ‘TEMP_FAILURE_RETRY’ [-Wimplicit-function-declaration]
   73 |   if (TEMP_FAILURE_RETRY (fstat (fd, &stbuf)) != 0)
      |       ^~~~~~~~~~~~~~~~~~
  CCLD     xdg-dbus-proxy
/usr/lib/gcc/x86_64-pc-linux-musl/9.2.0/../../../../x86_64-pc-linux-musl/bin/ld: dbus-proxy.o: in function `fd_readall_bytes':
/root/.cache/kiss/build-30335/xdg-dbus-proxy/dbus-proxy.c:73: undefined reference to `TEMP_FAILURE_RETRY'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:903: xdg-dbus-proxy] Error 1

Steps to reproduce

Build Flatpak on x86_64-pc-linux-musl, I guess.

Here's what I have as dependencies:

autoconf make
automake make
libtool make
bison make
gettext
libcap
libarchive
libxml2
libsoup
gpgme
libXau
linux-headers
polkit
json-glib
appstream-glib
dbus
bubblewrap

And here's my build script:

#!/bin/sh -e

patch -p0 -N -i musl-macros.patch

autoreconf -fi

./configure --prefix=/usr --disable-seccomp --disable-documentation --disable-gtk-doc --with-system-bubblewrap --without-system-dbus-proxy --enable-sandboxed-triggers
make ${MAKEOPTS}
make install DESTDIR=$1

And here's the contents of musl-macros.patch, which I stole from Void Linux's port of Flatpak:

--- config.h.in.orig
+++ config.h.in
@@ -151,3 +151,12 @@
 
 /* Define to 1 if you need to in order for `stat' and other things to work. */
 #undef _POSIX_SOURCE
+
+#ifndef TEMP_FAILURE_RETRY
+#define TEMP_FAILURE_RETRY(expression) \
+  (__extension__                                                              \
+    ({ long int __result;                                                     \
+       do __result = (long int) (expression);                                 \
+       while (__result == -1L && errno == EINTR);                             \
+       __result; }))
+#endif

Related question: https://unix.stackexchange.com/questions/736453

This is the situation:

• I have NetworkManager running on the host system.
• I have systemd and dbus running in a privileged Docker container.
• I want nmcli in the container to access the NetworkManager on the host system.
• However: I also need to be able to access dbus services within the container as well.

The goal is to have requests for NetworkManager be routed to the parent dbus, and requests for anything else sent to the container dbus.

I've had a look at xdg-dbus-proxy to implement this but am confused: is it possible to use the proxy to implement this? I thought of listening on a different dbus path with the proxy, and forwarding conditionally (the parent dbus is mounted at /run/parent-dbus):

xdg-dbus-proxy \
  unix:path=/run/parent-dbus/system_bus_socket \
  /run/merged-dbus/system_bus_socket \
  --filter --log \
  --talk=org.freedesktop.NetworkManager.* \
  unix:path=/run/dbus/system_bus_socket \
  /run/merged-dbus/system_bus_socket

Then setting in the environment for nmcli:

export DBUS_SYSTEM_BUS_ADDRESS=unix:path=/run/merged-dbus/system_bus_socket

This almost works: if I run the above command as-is, it doesn't work (nmcli says NetworkManager is not running, I assume the requests are being sent to /run/dbus/...). If I change the last argument to xdg-dbus-proxy to something else like /run/other-dbus/system_bus_socket, it works: the proxy forwards the NetworkManager requests to the /run/parent-dbus/..., however, requests that I intended to send to the /run/dbus/... do not get sent there.

This must be because xdg-dbus-proxy overwrites /run/merged-dbus/system_bus_proxy twice instead of "merging" the two together into a single proxy, where anything missing the filters on the first address/path pair is sent to the second one.

It seems like to do what I want, I might have to do some modifications to xdg-dbus-proxy.

Any help / guidance is greatly appreciated. Thanks much.

cc @smcv

If there was an externally manipulatable API in xdg-dbus-proxy to add support for filtering or mock APIs, it would be possible to have, for example, xdg-desktop-portal block access to NetworkManager unless location services were authorised for this app, mimicking the functionality in iOS:

An app linked against iOS 12 or earlier receives a dictionary with pseudo-values. In this case, the SSID is Wi-Fi (or WLAN in the China region), and the BSSID is 00:00:00:00:00:00.

This could also be used to:

• filter responses from Avahi to only show services that the app has declared caring about
• make it impossible to scan or manipulate unpaired devices for bluez
  etc.

#9 made xdg-dbus-proxy bundle a copy of ax_code_coverage.m4 from autoconf-archive. However, since AX_CODE_COVERAGE uses AX_CHECK_GNU_MAKE internally, this means autoreconf fails on xdg-dbus-proxy 0.1.2 if you don't have autoconf-archive installed:

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force 
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /gar/bin/autoconf --force
configure.ac:51: error: possibly undefined macro: AC_MSG_ERROR
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: /gar/bin/autoconf failed with exit status: 1

Adding ax_check_gnu_make.m4 to the bundled files fixes this.

It would often be useful for dbus services to reliably know which app they are talking to. For example, the keychain service on iOS only allows access to a secret for the app that created that secret. As far as I know, this is currently not possible on linux/dbus because there is no reliable way to identify apps (whatever that might be exactly). A service could use GetConnectionUnixProcessID and then check /proc/{pid}/exe, but that often ends up being bash or python, which is not really useful.

A way something like this could be implemented is that the service acquires a separate name for each app, e.g. org.freedesktop.Secret.MyApp and then we could use xdg-dbus-proxy to remap that name to org.freedesktop.Secret within the sandbox. Of course this would still require changes in the services, but not to the dbus interface specs.

For syntax, I imaging something like this:

xdg-dbus-proxy unix:path=/run/usr/1000/bus /run/usr/1000/bus-proxy --filter \
  --talk=org.freedesktop.Secret.MyApp:org.freedesktop.Secret

Maybe this approach could also be used to solve issues like #15 and #18.

I could try to work on the implementation. But before I get into that I wanted to check if you interested at all?

On systemd/systemd#16610, @refi64 writes:

sd-bus sends the BEGIN command right along with AUTH EXTERNAL, rather than using it to acknowledge an OK. I found this because it confuses Flatpak's xdg-dbus-proxy, which generally expects BEGIN to be sent after the auth is complete.

sd-bus does this pipelining deliberately to reduce round-trips, and @poettering considers it to be an xdg-dbus-proxy bug that it gets confused by pipelining the SASL handshake.

It is not at all clear to me that the D-Bus Specification ever intended to allow pipelining the SASL handshake, and its current wording can be interpreted as forbidding pipelining the SASL handshake, but it does work in practice against the major server implementations (the reference libdbus, GDBus and sd-bus). Ideally xdg-dbus-proxy should only process as much text as it is ready to deal with (in practice this means only the next line), and defer the rest until its next return to the main loop.

#20 might be related to this.

I'm trying to use xdg-dbus-proxy with systemd socket based activation.

That is, systemd creates the socket early during startup, but will initialise the proxy only after receiving the first connection to it.

Currently it is possible to specify a file path via PATH:

xdg-dbus-proxy unix:path="$XDG_RUNTIME_DIR/bus" /path/to/where/the/proxy/listens

In order to do socket activation, the proxy would need to listen on a file descriptor:

xdg-dbus-proxy unix:path="$XDG_RUNTIME_DIR/bus" fd:3

Regrettably, passing simply fd:3 creates a file socket named fd:3. Would it be possible to also support listening of file descriptors for this kind of usage?

Trying to build release 0.1.2 against musl c-library 1.2.0:

dbus-proxy.c: In function 'fd_readall_bytes':
dbus-proxy.c:73:7: warning: implicit declaration of function 'TEMP_FAILURE_RETRY' [-Wimplicit-function-declaration]
   73 |   if (TEMP_FAILURE_RETRY (fstat (fd, &stbuf)) != 0)
      |       ^~~~~~~~~~~~~~~~~~

The above is glibc specific. Perhaps you could #define it in code if not defined, or just add own macro to do the same. This would improve portability for non-glibc systems such as musl c-library.

The same problem occurs elsewhere:
containers/bubblewrap#239
ostreedev/ostree#731
flatpak/flatpak#618

A possible workaround:
https://github.com/gentoo/musl/blob/7b3334e4407979463f645e0e390a409d0da8ed4d/sys-apps/xdg-dbus-proxy/files/xdg-dbus-proxy-0.1.2-missing-TEMP_FAILURE_RETRY.patch

First let me say that I don't know if this is feasible because I lack enough knowledge of D-Bus to be able to say so.

StatusNotifierItem registered by applications uses the PID followed by a number (usually handle incrementally by the app) to define the name of the StatusNotifierItem to register, per the spec.
Unfortunately it doesn't map well with Flatpak applications since they are PID-namespaced and their PID is often a single low digit, so the names will likely clash quite often on system using a lot of Flatpak applications with tray.
Adding to that the need of owning the whole org.kde.* namespace to be able to do so, it seems like a rather bad situation.

Would it be possible to rename StatusNotifierItem objects on the fly when they are created, keep a mapping and forward the requests/responses on this object accordingly ? We could just use the PID of the dbus-proxy itself for example, or something like that.

Or any other idea to improve this situation ?

Thanks.

tdesktop uses dbus for its IPC. Whenever it needs to create a webview, it spawns a child process that initializes webkit2gtk (Qt initializes gtk as well, so if they initialize different gtk versions (qt may initialize gtk2 while tdesktop initializes gtk3), the process will crash, so it's going on in a separate process), then main process calls methods and subscribes to signals on service of the child process. Child process checks for connection ID to be equal to parent process connection ID when it gets a request to a method, signals have parent connection ID as destination as well. The check in method calls works just fine, but signals don't go to the destination in flatpak for some reason :(. I think xdg-dbus-proxy is the cause of this weird behavior, IPC works just fine if I run the package with --socket=session-bus.