[GH-ISSUE #4716] firefox: cannot save files with the File Chooser Portal (dbus)

gitea-mirror commented

2026-05-05 09:25:39 -06:00

Owner

Originally created by @WhyNotHugo on GitHub (Nov 26, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4716

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.

Originally created by @WhyNotHugo on GitHub (Nov 26, 2021). Original GitHub issue: https://github.com/netblue30/firejail/issues/4716 ### 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_ 1. Run firefox 2. Open `about:config` 3. Set `widget.use-xdg-desktop-portal` to `true` 4. Try to save an image from a website with the right-click menu, or saving a page using Ctrl+S 5. 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`](https://git.sr.ht/~whynothugo/dotfiles/tree/1bc83e4d81f94cb958beff20c8f73e72360b9c38/item/sysconfig/etc/firejail/firefox.local) and [`globals.local`](https://git.sr.ht/~whynothugo/dotfiles/tree/1bc83e4d81f94cb958beff20c8f73e72360b9c38/item/sysconfig/etc/firejail/globals.local). ### Checklist - [x] 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** - [x] The program has a profile. (If not, request one in `https://github.com/netblue30/firejail/issues/1139`) - [x] The profile (and redirect profile if exists) hasn't already been fixed [upstream](https://github.com/netblue30/firejail/tree/master/etc). - [x] I have performed a short search for similar issues (to avoid opening a duplicate). - [x] I'm aware of `browser-allow-drm yes`/`browser-disable-u2f no` in `firejail.config` to allow DRM/U2F in browsers.

gitea-mirror

2026-05-05 09:25:39 -06:00

closed this issue
added the
wontfix
label

gitea-mirror commented

2026-05-05 09:25:41 -06:00

Author

Owner

@rusty-snake commented on GitHub (Nov 26, 2021):

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.

@rusty-snake commented on GitHub (Nov 26, 2021): 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.

gitea-mirror commented

2026-05-05 09:25:42 -06:00

Author

Owner

@ghost commented on GitHub (Nov 26, 2021):

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?

@ghost commented on GitHub (Nov 26, 2021): > 5. 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`?

gitea-mirror commented

2026-05-05 09:25:44 -06:00

Author

Owner

@kmk3 commented on GitHub (Nov 26, 2021):

@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).

@kmk3 commented on GitHub (Nov 26, 2021): @rusty-snake commented [on Nov 26](https://github.com/netblue30/firejail/issues/4716#issuecomment-980047177): > 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: ```console $ uname -sro Linux 5.15.2-artix1-1 GNU/Linux ``` @glitsj16 commented [on Nov 26](https://github.com/netblue30/firejail/issues/4716#issuecomment-980077411): > > 5. 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).

gitea-mirror commented

2026-05-05 09:25:45 -06:00

Author

Owner

@ghost commented on GitHub (Nov 26, 2021):

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 :-)

@ghost commented on GitHub (Nov 26, 2021): > 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 :-)

gitea-mirror commented

2026-05-05 09:25:46 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Nov 26, 2021):

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).

https://github.com/netblue30/firejail/issues/4716#issuecomment-980090168 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.

@WhyNotHugo commented on GitHub (Nov 26, 2021): > 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). --- https://github.com/netblue30/firejail/issues/4716#issuecomment-980090168 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.

gitea-mirror commented

2026-05-05 09:25:47 -06:00

Author

Owner

@rusty-snake commented on GitHub (Nov 26, 2021):

@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.

@rusty-snake commented on GitHub (Nov 26, 2021): @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.

gitea-mirror commented

2026-05-05 09:25:47 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Nov 26, 2021):

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.

@WhyNotHugo commented on GitHub (Nov 26, 2021): 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](https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.FileChooser), which, in turn, [uses a fuse mount](https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Documents), so I guess I'd have to whitelist that path too. I'll give that a shot and report back.

gitea-mirror commented

2026-05-05 09:25:48 -06:00

Author

Owner

@rusty-snake commented on GitHub (Nov 26, 2021):

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.

@rusty-snake commented on GitHub (Nov 26, 2021): > 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.

gitea-mirror commented

2026-05-05 09:25:49 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Nov 26, 2021):

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.

@WhyNotHugo commented on GitHub (Nov 26, 2021): 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.

gitea-mirror commented

2026-05-05 09:25:50 -06:00

Author

Owner

@rusty-snake commented on GitHub (Nov 26, 2021):

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?

@rusty-snake commented on GitHub (Nov 26, 2021): 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?

gitea-mirror commented

2026-05-05 09:25:50 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Nov 26, 2021):

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.

@WhyNotHugo commented on GitHub (Nov 26, 2021): > 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.

gitea-mirror commented

2026-05-05 09:25:51 -06:00

Author

Owner

@rusty-snake commented on GitHub (Dec 7, 2021):

🎉 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.

@rusty-snake commented on GitHub (Dec 7, 2021): :tada: I made my non-flatpak fox perform reading through document portal: ```bash 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.

gitea-mirror commented

2026-05-05 09:25:52 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Dec 7, 2021):

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 commented on GitHub (Dec 7, 2021): 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.

gitea-mirror commented

2026-05-05 09:25:53 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Dec 14, 2021):

The portal handles flatpake'd applications different from native ones. See https://github.com/flatpak/xdg-desktop-portal/issues/680#issuecomment-992895749

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.

@WhyNotHugo commented on GitHub (Dec 14, 2021): The portal handles flatpake'd applications different from native ones. See https://github.com/flatpak/xdg-desktop-portal/issues/680#issuecomment-992895749 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.

gitea-mirror commented

2026-05-05 09:25:53 -06:00

Author

Owner

@rusty-snake commented on GitHub (Dec 15, 2021):

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.

@rusty-snake commented on GitHub (Dec 15, 2021): > The portal handles flatpake'd applications different from native ones. Yes, I know, that's why I did ```bash bwrap … --ro-bind-data 3 /.flatpak-info … 3<<EOF [Application] name=org.mozilla.firefox EOF ``` above.

gitea-mirror commented

2026-05-05 09:25:53 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Dec 16, 2021):

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

Or am I missing something?

@WhyNotHugo commented on GitHub (Dec 16, 2021): Yeah, but the portal doesn't run inside the sandbox, so it won't detect that file. Or am I missing something?

gitea-mirror commented

2026-05-05 09:25:54 -06:00

Author

Owner

@rusty-snake commented on GitHub (Dec 16, 2021):

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.

@rusty-snake commented on GitHub (Dec 16, 2021): > 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`.

gitea-mirror commented

2026-05-05 09:25:54 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Dec 20, 2021):

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 commented on GitHub (Dec 20, 2021): 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: ```dosini [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 ```

gitea-mirror commented

2026-05-05 09:25:55 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Dec 20, 2021):

The portal seems to use this to read additional metadata from Flatpak: 0c3d8fddc4/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.

@WhyNotHugo commented on GitHub (Dec 20, 2021): 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.

gitea-mirror commented

2026-05-05 09:25:55 -06:00

Author

Owner

@rusty-snake commented on GitHub (Oct 30, 2022):

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

Closing for now.

@rusty-snake commented on GitHub (Oct 30, 2022): Unless someone wants to bring firejail support into x-d-p this will be wontfix. Closing for now.

gitea-mirror commented

2026-05-05 09:25:55 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Nov 3, 2022):

I do believe a potential fix is possible; I've outlined an idea in https://github.com/netblue30/firejail/discussions/5318

@WhyNotHugo commented on GitHub (Nov 3, 2022): I do believe a potential fix is possible; I've outlined an idea in https://github.com/netblue30/firejail/discussions/5318

gitea-mirror commented

2026-05-05 09:25:56 -06:00

Author

Owner

@rusty-snake commented on GitHub (Nov 3, 2022):

In which comment?

@rusty-snake commented on GitHub (Nov 3, 2022): In which comment?

gitea-mirror referenced this issue

2026-05-05 10:21:37 -06:00

[PR #2764] [MERGED] Fix youtube video in totem #4518

Rows
Columns

[GH-ISSUE #4716] firefox: cannot save files with the File Chooser Portal (dbus) #2764

Description

Steps to Reproduce

Expected behavior

Actual behavior

Behavior without a profile

Additional context

Environment

Checklist