firefox: cannot save files with the File Chooser Portal (dbus) #4716

WhyNotHugo · 2021-11-26T15:00:20Z

Description

I've set the Firefox setting widget.use-xdg-desktop-portal to true, so that it uses the File Chooser Portal.

When saving a file, the file is not persisted to disk.

Steps to Reproduce

Steps to reproduce the behavior

Run firefox
Open about:config
Set widget.use-xdg-desktop-portal to true
Try to save an image from a website with the right-click menu, or saving a page using Ctrl+S
Save the file to someplace like ~/tmp/, but NOT to a whitelisted path.

Expected behavior

File should be saved.

Actual behavior

File isn't saved.

Behavior without a profile

It works. It also works with Firefox's flatpak.

I mostly tested the Flatpak since the native Firefox has permissions to write there anyway, whereas the Flatpak does not. This makes me suspect it's a firejail profile issue and not Firefox itself misusing the portal.

Additional context

I'm very new to firejail (jumped to using it yesterday), so hope I haven't missed anything obvious.

Environment

➜ uname -sro
Linux 5.15.2-arch1-1 GNU/Linux

➜ firejail --version
firejail version 0.9.66

Compile time support:
	- always force nonewprivs support is disabled
	- AppArmor support is enabled
	- AppImage support is enabled
	- chroot support is enabled
	- D-BUS proxy support is enabled
	- file and directory whitelisting support is enabled
	- file transfer support is enabled
	- firetunnel support is enabled
	- networking support is enabled
	- output logging is enabled
	- overlayfs support is disabled
	- private-home support is enabled
	- private-cache and tmpfs as user enabled
	- SELinux support is disabled
	- user namespace support is enabled
	- X11 sandboxing support is enabled

firefox.local and globals.local.

Checklist

The issues is caused by firejail (i.e. running the program by path (e.g. /usr/bin/vlc) "fixes" it).
I can reproduce the issue without custom modifications (e.g. globals.local). TODO
The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
The profile (and redirect profile if exists) hasn't already been fixed upstream.
I have performed a short search for similar issues (to avoid opening a duplicate).
I'm aware of browser-allow-drm yes/browser-disable-u2f no in firejail.config to allow DRM/U2F in browsers.

The text was updated successfully, but these errors were encountered:

rusty-snake · 2021-11-26T15:08:58Z

Which DE (or better which portal implementation+version) do you use? Some implementation dislike noroot. Does ignore noroot work?

Linux 5.15.2-arch1-1 GNU/Linux

Quite obvious. The distro and version is more interesting.

glitsj16 · 2021-11-26T16:02:04Z

Save the file to someplace like ~/tmp/, but NOT to a whitelisted path.

I'm a bit confused. Our Firefox profile is designed as a 'whitelist' profile. This implies that access is blocked to all paths that are not explicitly whitelisted, like ~/tmp. So IMO this is expected behavior. Can you save files in ~/tmp if you add a whitelist ${HOME}/tmp to your firefox.local?

kmk3 · 2021-11-26T16:15:05Z

@rusty-snake commented on Nov 26:

Which DE (or better which portal implementation+version) do you use? Some
implementation dislike noroot. Does ignore noroot work?

Linux 5.15.2-arch1-1 GNU/Linux

Quite obvious. The distro and version is more interesting.

AFAIK "-arch" is what Arch Linux uses.

On Artix:

$ uname -sro
Linux 5.15.2-artix1-1 GNU/Linux

@glitsj16 commented on Nov 26:

Save the file to someplace like ~/tmp/, but NOT to a whitelisted path.

I'm a bit confused. Our Firefox profile is designed as a 'whitelist' profile.
This implies that access is blocked to all paths that are not explicitly
whitelisted, like ~/tmp. So IMO this is expected behavior. Can you save files
in ~/tmp if you add a whitelist ${HOME}/tmp to your firefox.local?

I think the intent here is to make the file portal work so that the user can
save files anywhere regardless of the whitelist (i.e.: bypass the sandbox
through dbus).

glitsj16 · 2021-11-26T16:30:09Z

I think the intent here is to make the file portal work so that the user can
save files anywhere regardless of the whitelist (i.e.: bypass the sandbox
through dbus).

@kmk3 Thanks for explaining. I'm not at all familiar with (the inner workings of) these portals, and don't have any of the xdg-desktop-portal{,-*} packages installed on my Arch Linux boxes. More stuff to experiment with :-)

WhyNotHugo · 2021-11-26T16:46:49Z

Which DE (or better which portal implementation+version) do you use? Some implementation dislike noroot.

I'm using swaywm, and using the xdg-desktop-portal-gtk as a file picker portal.

Does ignore noroot work?

Adding ignore noroot to firefox.local did not make it work.

Quite obvious. The distro and version is more interesting.

Sorry for not being clearer, it's Arch (rolling release).

#4716 (comment) is correct, my intent is to use the portal to allow reading / writing files outside whitelisted locations. For reference, I can open a file in ~/tmp, but writing does not work.

rusty-snake · 2021-11-26T17:17:04Z

@WhyNotHugo are you sure widget.use-xdg-desktop-portal is supposed to work (=read/write is performed via portal)? I tested firejail --private --net=none --noprofile /usr/bin/firefox --no-remote (+flip pref on about:config) and bwrap --dev-bind / / --tmpfs $HOME/Downloads --tmpfs $HOME/.mozilla /usr/bin/firefox --new-instance, and it can neither read nor write through portals.

WhyNotHugo · 2021-11-26T18:35:57Z

Yeah, apparently reading doesn't work either -- I can pick a file, but it's not read correctly.

Sorry, it seems I tested this wrong a bit. The file chooser portal actually exposes the file via the document portal, which, in turn, uses a fuse mount, so I guess I'd have to whitelist that path too.

I'll give that a shot and report back.

rusty-snake · 2021-11-26T18:39:29Z

so I guess I'd have to whitelist that path too.

I don't think so. firejail --private --net=none --noprofile /usr/bin/firefox --no-remote allows this path, my guess is more that firefox did not implemented IO via portal. The widget.use-xdg-desktop-portal bugs (at bugzilla) only talk about native vs. custom file-chooser.

WhyNotHugo · 2021-11-26T19:13:21Z

I'm experimenting with Firefox in Flatpak too, to understand what's implemented and what isn't.

With widget.use-xdg-desktop-portal set to false, I cannot read any files from ~/tmp, nor does it show up in the file picker (as expected).

With widget.use-xdg-desktop-portal set to true, I can open a file in ~/tmp, and the path that firefox shows in the URL bar is file:///run/user/1000/doc/320b8f7f/wallhaven-pkw6y3.jpg, leading me to think that the reading did happen via the portals.

rusty-snake · 2021-11-26T19:23:09Z

Maybe the flatpak as a special patch which isn't in firefox yet? Or these code paths are only used if you run inside flatpak?

WhyNotHugo · 2021-11-26T19:26:25Z

Maybe the flatpak as a special patch which isn't in firefox yet? Or these code paths are only used if you run inside flatpak?

I believe there are no special patches, but at this point, I think it's best to report this on the Firefox side just to make sure there's nothing else necessary on their side.

Thanks for the guidance thus far.

rusty-snake · 2021-12-07T08:46:25Z

🎉 I made my non-flatpak fox perform reading through document portal:

bwrap --ro-bind /usr /usr --symlink usr/bin /bin --symlink usr/lib /lib --symlink usr/lib64 /lib64 --symlink usr/sbin /sbin --ro-bind /etc /etc --ro-bind /var /var --ro-bind /run /run --dir /tmp --dev-bind /dev /dev --ro-bind /sys /sys --bind /proc /proc --dir $HOME --bind $XDG_RUNTIME_DIR $XDG_RUNTIME_DIR --ro-bind-data 3 /.flatpak-info /usr/bin/firefox --no-remote 3<<EOF     
[Application]
name=org.mozilla.firefox
EOF

Portals look for/at /proc/{PID}/root/.flatpak-info.

Writing still doesn't work.

WhyNotHugo · 2021-12-07T09:46:52Z

This example doesn't work for me. I set widget.use-xdg-desktop-portal=true, and Firefox uses the File Chooser portal, but fails to open files (apparently, it gets back the original file paths and not the document-portal paths).

Also tried adding --setenv GTK_USE_PORTAL 1, but no luck either.

WhyNotHugo · 2021-12-14T22:54:52Z

The portal handles flatpake'd applications different from native ones. See flatpak/xdg-desktop-portal#680 (comment)

So I guess for this to work, a portal needs to be spawn in a specific way. I'll follow up as I learn more, but it's possible that a firejail-specific-portal-launcher is needed (or something similar; kinda like how xdg-dbus-portal is integrated).

This probably isn't as simple as I original expected, but I still think it's worth it since it allows further restricting how much access applications have, and this applies to a lot of other things other than Firefox.

rusty-snake · 2021-12-15T08:35:30Z

The portal handles flatpake'd applications different from native ones.

Yes, I know, that's why I did

bwrap … --ro-bind-data 3 /.flatpak-info … 3<<EOF     
[Application]
name=org.mozilla.firefox
EOF

above.

WhyNotHugo · 2021-12-16T17:23:55Z

Yeah, but the portal doesn't run inside the sandbox, so it won't detect that file.

Or am I missing something?

rusty-snake · 2021-12-16T18:22:29Z

Yeah, but the portal doesn't run inside the sandbox, so it won't detect that file.

Do they for flatpak? (rhetorical question)

Or am I missing something?

AFAIK portals look at /proc/PID/root/.flatpak-info.

WhyNotHugo · 2021-12-20T18:56:16Z

You're very right, I'd misinterpreted both your message and the one in the linked issue.

I ran chromium via flatpak, and opened file:///. It includes additional information that I the portal relies on:

[Application]
name=org.chromium.Chromium
runtime=runtime/org.freedesktop.Platform/x86_64/21.08

[Instance]
instance-id=535920758
instance-path=/home/hugo/.var/app/org.chromium.Chromium
app-path=/var/lib/flatpak/app/org.chromium.Chromium/x86_64/stable/b5cdf307caeee0bafeef91a270d0275c5e090b7ae4e8b36bb3ba1e09d5aad6be/files
app-commit=b5cdf307caeee0bafeef91a270d0275c5e090b7ae4e8b36bb3ba1e09d5aad6be
app-extensions=org.chromium.Chromium.Codecs=305ed74b5afde01cef9d26b9723d5acb2f47561b55c30f79063a7dea9b62742d;org.chromium.Chromium.Locale=8536d50082de1b2bede1236e8b4c834025f3a7463d0dc19a94dc5a7c26630718
runtime-path=/var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/21.08/940b0728d1b7d18b9d3f557ae44e7c37b27febcb04f93a7cc0ebb886ba2cfa37/files
runtime-commit=940b0728d1b7d18b9d3f557ae44e7c37b27febcb04f93a7cc0ebb886ba2cfa37
runtime-extensions=org.freedesktop.Platform.GL.default=031dc8a64a8fc1ed5819295270af05241a8982b0e0a48cd6f53fd69704cbb437;org.freedesktop.Platform.Locale=e351675710d3a6b6675db60e8d3cf496f700c3c9704a3c09f97448847bc89cc3;org.gtk.Gtk3theme.Arc-Dark=e048bba59ea07a84bb3f9c092dcab6adf45b4f626224983ab553ee19ae67f1a3;org.gtk.Gtk3theme.Arc-Darker=37974c74afc5b4d77104015a13318422c331dfa023790cd64b90b1b15271f472;org.freedesktop.Platform.VAAPI.Intel=0b5fc0c4a2e7930ccff2d6d4389296e64ed6d4067910a76a9f31461485574eec;org.freedesktop.Platform.openh264=73f998362a6fc0d57e0c7e83e928d32b0ec14d10d0d94291033976bdcecc6b6b
branch=stable
arch=x86_64
flatpak-version=1.12.2
session-bus-proxy=true
system-bus-proxy=true

[Context]
shared=network;ipc;
sockets=x11;wayland;pulseaudio;cups;
devices=all;
filesystems=!home;xdg-download;/run/.heim_org.h5l.kcm-socket;

[Session Bus Policy]
org.gnome.SessionManager=talk
org.freedesktop.Notifications=talk
org.mpris.MediaPlayer2.chromium.*=own
org.freedesktop.secrets=talk
org.freedesktop.FileManager1=talk

[Environment]
ALSA_CONFIG_PATH=/usr/share/alsa/alsa-flatpak.conf
GI_TYPELIB_PATH=/app/lib/girepository-1.0
GST_PLUGIN_SYSTEM_PATH=/app/lib/gstreamer-1.0:/usr/lib/extensions/gstreamer-1.0:/usr/lib/x86_64-linux-gnu/gstreamer-1.0
XDG_DATA_DIRS=/app/share:/usr/share:/usr/share/runtime/share:/run/host/user-share:/run/host/share
LD_LIBRARY_PATH=/app/chromium/nonfree-codecs/lib
ALSA_CONFIG_DIR=/usr/share/alsa
GTK_PATH=/app/lib/gtkmodules

WhyNotHugo · 2021-12-20T18:59:26Z

The portal seems to use this to read additional metadata from Flatpak: https://github.com/flatpak/xdg-desktop-portal/blob/0c3d8fddc4afbe06c5bb6fdde02b35a6d97e6f7d/src/xdp-utils.c#L1838

It behaves differently with Flatpak vs non-Flatpak applications, and won't expose its regular functionality to applications that are not Flatpaks, even if they're sandboxed.

At this point, I suspect writing a new portal is more feasible than trying to leverage that one.

rusty-snake · 2022-10-30T16:49:33Z

Unless someone wants to bring firejail support into x-d-p this will be wontfix.

Closing for now.

WhyNotHugo · 2022-11-03T17:51:40Z

I do believe a potential fix is possible; I've outlined an idea in #5318

rusty-snake · 2022-11-03T18:19:28Z

In which comment?

WhyNotHugo mentioned this issue Dec 13, 2021

File chooser portal isn't using the document portal flatpak/xdg-desktop-portal#680

Closed

WhyNotHugo mentioned this issue Dec 27, 2021

Drag and dropping files into sandboxed applications swaywm/sway#6460

Closed

rusty-snake mentioned this issue Jul 12, 2022

google-chrome: real home is accessible with --private= (dbus) #5246

Closed

7 tasks

rusty-snake mentioned this issue Aug 6, 2022

Add electronapps-common.profile #5297

Closed

rusty-snake added the wontfix This will not be worked on label Oct 30, 2022

rusty-snake closed this as not planned Won't fix, can't repro, duplicate, stale Oct 30, 2022

rusty-snake mentioned this issue Aug 20, 2023

File Picker portal brings up dialog, but the selected file is empty flatpak/xdg-desktop-portal#1076

Closed

kmk3 changed the title ~~Firefox can't save files with the File Chooser Portal~~ firefox: cannot save files with the File Chooser Portal (dbus) Sep 4, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

firefox: cannot save files with the File Chooser Portal (dbus) #4716

firefox: cannot save files with the File Chooser Portal (dbus) #4716

WhyNotHugo commented Nov 26, 2021 •

edited

Loading

rusty-snake commented Nov 26, 2021 •

edited

Loading

glitsj16 commented Nov 26, 2021

kmk3 commented Nov 26, 2021

glitsj16 commented Nov 26, 2021

WhyNotHugo commented Nov 26, 2021

rusty-snake commented Nov 26, 2021

WhyNotHugo commented Nov 26, 2021

rusty-snake commented Nov 26, 2021

WhyNotHugo commented Nov 26, 2021

rusty-snake commented Nov 26, 2021

WhyNotHugo commented Nov 26, 2021

rusty-snake commented Dec 7, 2021

WhyNotHugo commented Dec 7, 2021

WhyNotHugo commented Dec 14, 2021

rusty-snake commented Dec 15, 2021

WhyNotHugo commented Dec 16, 2021

rusty-snake commented Dec 16, 2021

WhyNotHugo commented Dec 20, 2021

WhyNotHugo commented Dec 20, 2021 •

edited

Loading

rusty-snake commented Oct 30, 2022

WhyNotHugo commented Nov 3, 2022

rusty-snake commented Nov 3, 2022

firefox: cannot save files with the File Chooser Portal (dbus) #4716

firefox: cannot save files with the File Chooser Portal (dbus) #4716

Comments

WhyNotHugo commented Nov 26, 2021 • edited Loading

Description

Steps to Reproduce

Expected behavior

Actual behavior

Behavior without a profile

Additional context

Environment

Checklist

rusty-snake commented Nov 26, 2021 • edited Loading

glitsj16 commented Nov 26, 2021

kmk3 commented Nov 26, 2021

glitsj16 commented Nov 26, 2021

WhyNotHugo commented Nov 26, 2021

rusty-snake commented Nov 26, 2021

WhyNotHugo commented Nov 26, 2021

rusty-snake commented Nov 26, 2021

WhyNotHugo commented Nov 26, 2021

rusty-snake commented Nov 26, 2021

WhyNotHugo commented Nov 26, 2021

rusty-snake commented Dec 7, 2021

WhyNotHugo commented Dec 7, 2021

WhyNotHugo commented Dec 14, 2021

rusty-snake commented Dec 15, 2021

WhyNotHugo commented Dec 16, 2021

rusty-snake commented Dec 16, 2021

WhyNotHugo commented Dec 20, 2021

WhyNotHugo commented Dec 20, 2021 • edited Loading

rusty-snake commented Oct 30, 2022

WhyNotHugo commented Nov 3, 2022

rusty-snake commented Nov 3, 2022

WhyNotHugo commented Nov 26, 2021 •

edited

Loading

rusty-snake commented Nov 26, 2021 •

edited

Loading

WhyNotHugo commented Dec 20, 2021 •

edited

Loading