Firefox is getting access to home

I have manually disconnected :home slot from firefox but firefox still can access to home. When I try to access home through firefox, first it gives an error message which shows permission denied but thereafter it gives access to home folder with different dialog box.The dialog box,which shows permission denied, is native to snap.Another dialog box,which gives the access, is native to kde.

I don’t know what is causing this. Can it be the distro I’m using?

Os- Manjaro(KDE) Kernel-5.6.x Firefox- 75.0-3 Snapd-2.44.3

From the sound of it, the KDE-style dialog is running out of process and provided by xdg-desktop-portal-kde. Through this system, Firefox is given access to only the file you choose rather than your whole home directory.

As an example, try selecting “Open File…” from Firefox’s menu and choose a text file in your home directory. Now look at the URL bar: it will probably read something like file:///run/user/NNNN/doc/... rather than the real path of the file.

Here’s a summary of what is happening:

  1. Firefox issues a D-Bus method call to the xdg-desktop-portal service asking to open a file.
  2. xdg-desktop-portal checks what desktop it is running on via $XDG_CURRENT_DESKTOP, and asks the appropriate UI backend to display a file chooser.
  3. In your case,xdg-desktop-portal-kde shows a the file chooser and returns the chosen file name to xdg-desktop-portal.
  4. xdg-desktop-portal then makes a D-Bus call to xdg-document-portal, asking it to make the chosen file available to Firefox.
  5. xdg-document-portal implements a FUSE file system that proxies access to files on the host system. It makes the chosen file available in a location Firefox can read, and returns the proxy file path back to xdg-desktop-portal.
  6. xdg-desktop-portal passes this file path back to Firefox.

While this might seem like a round-about way of doing things, it is (mostly) transparent to the user. The confined app appears to be able to read any file the user can, but in reality can only read the files it has been granted access to through a file chooser it doesn’t control.

Does that help allay your doubts?

1 Like

I was under impression if I have disconnected home slot then no way firefox could access home folder.That’s why I was a bit shaken.I thought,“most likely sandbox ain’t working properly”.

Now, firefox is making call to xdg-portal through d-bus, or something else. If it is d-bus, then
disconnecting d-bus slot should prevent that. Here’s my “firefox connections” .
I don’t see any dbus plug. How can I disconnect it?

If you want to see what snapd’s sandbox for Firefox allows, run the following command:

snap run --shell firefox

This will drop you into a shell running inside Firefox’s sandbox. With the home interface disconnected, you should be able to verify that you can’t read or write arbitrary files in your home directory.

Access to xdg-desktop-portal is granted through the desktop interface, which you won’t be able to disconnect without breaking Firefox. Is there any particular reason you want to disable this access?

i doubt manjaro has all security kernel features enabled/available by default … see:

snap debug confinement


snap debug sandbox-features

tbh, I don’t see any particular reason to give access to xdg-portal either. I get the point that the file is in FUSE mount but I’m not sure whether the triggering factor is dependent on user input or not. My problem is file still can be read.


snap debug sandbox-features

wow, that has improved a lot :slight_smile: so yeah, this is definitely supposed to be fully confined, sorry for the noise.

1 Like

It is dependent on user input: the file chooser is running in a different process outside of the sandbox. The confined application only receives the document portal file path for the file the user chose.

Note that this isn’t the only service xdg-desktop-portal provides. With portal support enabled, Firefox will use it to open URLs with schemes it can’t handle (e.g. Zoom conference links, Steam game links, Slack conversations, etc), and to open associated applications for files you download.

It also includes a number of other APIs intended to make certain unsafe APIs usable from confinement. For example:

  • create print jobs without being able to see or delete other app’s print jobs, enumerate printers and their settings, etc.
  • take screenshots without providing access to gnome-shell’s D-Bus API that can be used to overwrite arbitrary files.
  • post desktop notifications without being able to impersonate other applications (this one is not yet working for Snaps).

These are the kind of things that are difficult or impossible to secure at a granular level with AppArmor or seccomp rules.


To put it another way: the snap itself cannot drive the portal to give access to arbitrary files. The snap may only use the portals DBus APIs to present a dialog that then requires the user to finish the action (eg, by choosing a file from the portals file dialog). The snap is unable to see, use or drive that dialog without the user.

1 Like