File Picker portal brings up dialog, but the selected file is empty

[StandingPadAnimations]

When attempting to use portals directly (i.e. outside of Flatpak), I get the following issue:

2023-08-20.14-42-08.mp4

Where the file picker portal brings up the file picker dialog, but when selecting a file, services will complain it's "empty". As part of debugging, I checked $XDG_RUNTIME_DIR/doc and found no folder for the program I'm sandboxing.

Here's the script I'm using to run the portals and sandbox:

#! /usr/bin/bash

APP_FOLDER="$XDG_RUNTIME_DIR/app/net.vivaldi.Vivaldi"
mkdir -p "$APP_FOLDER"

if [ -z "$DBUS_SESSION_BUS_ADDRESS" ]; then
  export DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus"
fi

xdg-dbus-proxy \
  "$DBUS_SESSION_BUS_ADDRESS" \
  "$APP_FOLDER/bus" \
  --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" &

sleep 0.1

bwrap \
    --unshare-all \
    --share-net \
    --symlink /usr/lib /lib \
    --symlink /usr/lib64 /lib64 \
    --symlink /usr/bin /bin \
    --symlink /usr/bin /sbin \
    --ro-bind /usr/lib /usr/lib \
    --ro-bind /usr/lib64 /usr/lib64 \
    --ro-bind /usr/bin /usr/bin \
    --ro-bind /etc /etc \
    --ro-bind /usr/share /usr/share \
    --ro-bind /opt/vivaldi /opt/vivaldi \
    --dev /dev \
    --dev-bind /dev/dri /dev/dri \
    --proc /proc \
    --ro-bind /sys/dev/char /sys/dev/char \
    --ro-bind /sys/devices /sys/devices \
    --ro-bind /run/dbus /run/dbus \
    --dir "$XDG_RUNTIME_DIR" \
    --chmod 0700 "$XDG_RUNTIME_DIR" \
    --ro-bind "$XDG_RUNTIME_DIR/wayland-1" "$XDG_RUNTIME_DIR/wayland-1" \
    --ro-bind "$XDG_RUNTIME_DIR/pipewire-0" "$XDG_RUNTIME_DIR/pipewire-0" \
    --ro-bind "$XDG_RUNTIME_DIR/pulse" "$XDG_RUNTIME_DIR/pulse" \
    --ro-bind "$APP_FOLDER/bus" "$XDG_RUNTIME_DIR/bus" \
    --bind "$XDG_RUNTIME_DIR/doc" "$XDG_RUNTIME_DIR/doc" \
    --bind-try "$XDG_RUNTIME_DIR/app/org.keepassxc.KeePassXC/org.keepassxc.KeePassXC.BrowserServer" "$XDG_RUNTIME_DIR/app/org.keepassxc.KeePassXC/org.keepassxc.KeePassXC.BrowserServer" \
    --tmpfs /tmp \
    --dir "$HOME"/.cache \
    --bind "$HOME"/.config/vivaldi "$HOME"/.config/vivaldi \
    --bind "$HOME"/VivaldiDownloads "$HOME"/Downloads \
    --ro-bind "$HOME"/.icons "$HOME"/.icons \
    --setenv XCURSOR_PATH "/run/host/user-share/icons:/run/host/share/icons:$HOME/.icons" \
    --new-session \
    --die-with-parent \
    /usr/bin/vivaldi-stable --enable-features=UseOzonePlatform --ozone-platform=wayland "${@}"

[rusty-snake]

You do not use a sandbox that is supported by xdp (flatapk or snap) and therefore xdp assumes your program is allowed to access this path because it assumes it is an "normal", unsandboxed host program.

Very unfortunate situation right now that xdp has only support for these two and not for a generic one (via some kind of plugin or api mechanism). So if you use firejail/bubblejail/plain bubblewrap/crablock you can not benefit from the documents portal (and other portals have a "is allowed anyway" logic too).

There's a hacky workaround by pretending to be a flatpak. You can place a minimal /.flatpak-info inside your sandbox. See netblue30/firejail#4716 (comment).

[StandingPadAnimations]

Still doesn't work on my end

[StandingPadAnimations]

Strangely enough, 2 things seem to happen when trying to workaround this issue:

• 2 bwrap processes are created (if ran with --unshare-all, with only one having .flatpak-info
• 1 process runs (without --unshare-all), but .flatpak-info is nowhere to be found in /proc/{PID}/root

I wonder if it's possible to patch xdh to always return the document path regardless

[rusty-snake]

More precisely, there are two processes if you run with --unshare-pid (and without --as-pid-1) because bwrap places itself as pid-1 in a new pid-namespace by default to reap zombies.

[StandingPadAnimations]

Even with --as-pid-1, .flatpak-info can't be found in /proc/{PID}/root. Vivaldi reports its existence, but I doubt xdh can find it

[rusty-snake]

Idk in for which pid xdp search but it could as be that the portal looks at the pid of the dbus-proxy.

[StandingPadAnimations]

So if I manually copy the file to /proc/{PID}/root, it works

Interesting workaround

Sidenote: if I copy it to my root directory as .flatpak-info, well things start getting funny with my desktop

[StandingPadAnimations]

I figured out the issue, it was this:

--ro-bind "$APP_FOLDER/bus" "$XDG_RUNTIME_DIR/bus"

I have no idea why that prevented the root folder of proc from representing the sandboxed environment, but I'll close this now

[smcv]

If you're using xdg-dbus-proxy, then the message bus is receiving a D-Bus connection from xdg-dbus-proxy, not directly from the sandboxed app itself. This means that when xdg-desktop-portal asks the message bus "who sent this message?", the message bus tells it the process ID of xdg-dbus-proxy.

Flatpak puts /.flatpak-info in the filesystem root of both xdg-dbus-proxy and the actual sandboxed app, so that the xdg-dbus-proxy can be identified as being run on behalf of the sandboxed app. If you are faking a Flatpak app then you will need to do the same.

More generally, if you are reinventing Flatpak, it will be necessary to solve many of the same problems that Flatpak has done.

[StandingPadAnimations]

Thanks for the info! I'm aiming to sandbox native programs while taking advantage of portals and whatnot (since some native programs don't have Flatpak versions)