Can't get applications to use portals via xdg-dbus-proxy

[PhysicsIsAwesome]

Hi @StandingPadAnimations,

I try to get my bubblewrap sandboxes to work with portals via xdg-dbus-proxy and found your great blog post about it.

Despite following the instructions and adding the "/.flatpak-info" file, I was not able to get applications to use portals with the applications I have tested so far (kate, kwrite, joplin). I can open the file picker, but it only shows files from inside the sandbox, so it either does not use the dbus-proxy at all or something else is wrong. Are the instructions in your blog post and your scripts in this repo still working for you or is there something which needs to be adjusted?

[StandingPadAnimations]

(Not sure why GitHub isn't sending my email replies)

Hey there,

It's been a while since I've run something with a sandboxing script (moved back to FireFox between then and now). Unfortunately, my Vivaldi script seems to not work with Vivaldi anymore, though I can try to see where I can help.

Firstly, is the .flatpak-info file in both the sandboxes for dbus-proxy and the main process? dbus-proxy is what ultimately will do the actual request, and thus needs to identify itself as "part of " (of course not an actual flatpak, since we're effectively pretending to be one)

I would also check to see if those programs require additional environment variables to use portals in the first place. I know GTK commonly does that.

Let me know if there's still issues!

[PhysicsIsAwesome]

Thank you for your reply. After reading https://sloonz.github.io/posts/sandboxing-2 I finally got it to work by running xdg-dbus-proxy directly on the host without bubblewrap. Then, even an empty /.flatpak-info file is enough. I don't know why it does not work inside bubblewrap, I even copied flatpak's bubblewrap parameters without any success.

[StandingPadAnimations]

@PhysicsIsAwesome Just curious, what did your script previously look like with xdg-dbus-proxy sandboxed? Maybe the bus wasn't properly shared between xdg-dbus-proxy and the application?

[DCsunset]

Hi @StandingPadAnimations, I'm also trying to make FileChooser work in bubblewrap sandboxes found your post.

However, if I run xdg-dbus-proxy in a bubblewrap container and add the file /.flatpak-info, it prints some errors when trying to open a file:

C34: -> org.freedesktop.portal.Desktop call org.freedesktop.portal.FileChooser.OpenFile at /org/freedesktop/portal/desktop
B2238: <- :1.982 return error org.freedesktop.DBus.Error.AccessDenied from C34

Instead, if I don't add the /.flatpak-info to the xdp-dbus-proxy container, I can open the file chooser dialog successfully, but the actually application couldn't open the selected file because the path is from the host and inaccessible to the container.

I also followed the post mentioned by @PhysicsIsAwesome and the result is the same: i can open the file chooser but the the application is unable to read the file because the path is not accessible from the app container.

Did you encounter the same issues before? Any ideas and suggestions are appreciated!

[StandingPadAnimations]

As mentioned before, I don't use the sandboxing scripts anymore, but when I did, portals worked as expected. Can you post your script so I can see what it looks like?

[DCsunset]

Thanks for you reply.

For xdg-dbus-proxy (leaving out binary full path for readability):

bwrap \
  --bind /run /run \
  --bind /nix /nix \
  --ro-bind /tmp/empty /.flatpak-info \
  --new-session \
  --clearenv \
  xdg-dbus-proxy $DBUS_SESSION_BUS_ADDRESS $XDG_RUNTIME_DIR/xdg-dbus-proxy/app.sock --filter --log \
  --talk=org.freedesktop.portal.* \
  --call="org.freedesktop.portal.Desktop=org.freedesktop.portal.Settings.Read@/org/freedesktop/portal/desktop" \
  --broadcast="org.freedesktop.portal.Desktop=org.freedesktop.portal.Settings.SettingChanged@/org/freedesktop/portal/desktop"

For app:

bwrap \
  --bind /nix /nix \
  --proc /proc \
  --unshare-pid \
  --dev /dev \
  --ro-bind /tmp/empty /.flatpak-info \
  --bind $XDG_RUNTIME_DIR/xdg-dbus-proxy/app.sock $XDG_RUNTIME_DIR/bus \
  --bind <sandbox_dir> $HOME \
  <app>

This results in the previous errors. I'm using empty file here according to the other post. I've also tried a non-empty one in your post but still doesn't work.

[StandingPadAnimations]

Ah, I see the issue, you need to include --bind "$XDG_RUNTIME_DIR" "$XDG_RUNTIME_DIR" for xdg-dbus-proxy. Otherwise, xdg-dbus-proxy isn't creating the bus on the host system, just the sandbox.

You also need to have a .flatpak-info file in both sandboxes (with same content), so that it's clear to xdg-dbus-proxy what program it's running on behalf of.

sandboxing-scripts/vivaldi

Lines 27 to 44 in b2072b6

	--ro-bind-data 3 "/.flatpak-info" \
	--die-with-parent \
	-- \
	xdg-dbus-proxy \
	"$DBUS_SESSION_BUS_ADDRESS" \
	"$APP_FOLDER/bus" \
	--filter \
	--log \
	--talk="org.freedesktop.portal.Documents" \
	--talk="org.freedesktop.portal.Flatpak" \
	--talk="org.freedesktop.portal.Desktop" \
	--talk="org.freedesktop.portal.Notifications" \
	--talk="org.freedesktop.portal.FileChooser" \
	--call="org.freedesktop.portal.Desktop=org.freedesktop.portal.Settings.Read@/org/freedesktop/portal/desktop" \
	--broadcast="org.freedesktop.portal.Desktop=org.freedesktop.portal.Settings.SettingChanged@/org/freedesktop/portal/desktop" 3<<EOF
	[Application]
	name=$APP_NAME
	EOF

sandboxing-scripts/vivaldi

Lines 79 to 88 in b2072b6

	--ro-bind-data 3 "/.flatpak-info" \
	--setenv XCURSOR_PATH "/run/host/user-share/icons:/run/host/share/icons:$HOME/.icons" \
	--setenv GTK_USE_PORTAL 1 \
	--cap-drop ALL \
	-- \
	/usr/bin/vivaldi-stable --enable-features=UseOzonePlatform --ozone-platform=wayland --ignore-gpu-blocklist --enable-zero-copy "${@}" \
	3<<EOF
	[Application]
	name=$APP_NAME
	EOF

[DCsunset]

@StandingPadAnimations I did mount the whole /run directory for xdg-dbus-proxy for simplicity. So it can access the dbus without problem.

Besides, .flatpak-info was mounted to the container already by --ro-bind. I tried both with and without content but the result was the same.