Shortcut
Hello Flatpak enthusiasts. The up to date information about this challenge is in my comment #5 down below at https://discourse.flathub.org/t/sandboxing-stopped-flathub-apps-have-access-to-all-folders-and-files-outside-their-sandbox-what-could-cause-this-challenge/12244/5
The information below, starting with the “Summary” title is outdated. If there is any conflicting information between my comment #5 and the information down below. The up to date information is in my comment #5.
I keep this outdated information below for records
-– — — — — — — — — — — — — — — —
Summary
Hello Flatpak enthusiasts,
One question down below. We are facing an unusual challenge, on one device, sandboxing fully stopped. The challenge is that all installed Flathub Flatpak sandboxed applications have access to all folders and files outside their sandbox. The needed end result is that those apps should not have access to any folder or file outside their sandbox. Per both the Flatpak global and per Flatpak app configuration.
For the past years, that sandboxing was very successful on that same device. No challenge. Then, for the last few days, all the same sandboxed applications have access to all folders and files outside their sandboxes.
Question: Beside what we already tried, which is listed down below, what could potentially be causing this challenge above?
-– — — — — — — — — — — — — — — —
Details
Below is the same message as above. But with details if you’re interested in those.
-– — — — — — — — — — — — — — — —
Using
• Flatpak: 1.14.10
• Debian: 12 Bookworm
• Type: x86_64
• Display: Wayland
-– — — — — — — — — — — — — — — —
Steps to reproduce
1. Install Flatpak 1.14.10
2. Using Flathub, install apps
3. Sandboxing is successful for months. Sandboxes apps do not have access to any folder or file outside their sandbox. Joy. So no challenge yet.
4. One day, on the same device all the same sandboxed applications have access to all folders and files. Regardless of Flatpak app’s global configuration or per app configuration. Those app should not have access to any file or folder outside their sandbox. That we know of we have not changed anything to the configurations on that device.
5. This challenge can always be reproduced. For all Flatpak apps. But only with the same device. We are not able to reproduce this challenge on any other devices.
6. The needed end result is that, on that device, Flatpak sandboxed apps should not have access to any folders and files outside their sandboxes. Per both the Flatpak global and per app configuration.
By “access to all folders and all files”, I mean this, for exemple:
___ 1. Install this Kwriter Flatpak app from https://flathub.org/en/apps/org.kde.kwrite
___ 2. Using Flatseal from https://flathub.org/en/apps/com.github.tchx84.Flatseal configure the sandboxe access permissions like this:
______ Global:
_________ “Filesystem” group:
____________“filesystem=host” DENIED
____________“filesystem=host-os” DENIED
____________“filesystem=host-etc” DENIED
____________“filesystem=home” DENIED
__________ Kwriter (org.kde.kwrite) app:
____________“Filesystem” group:
_______________“filesystem=host” DENIED
_______________“filesystem=host-os” DENIED
_______________“filesystem=host-etc” DENIED
_______________“filesystem=home” DENIED
____________ “Other file” group:
_______________/home//Documents/
___ 3. Reboot device
___ 4. Using Kwriter try to read or writer a file stored in any folder OUTSIDE Kwriter sandbox. Kwriter has both read and write access to those files and folders. This is the challenge. Why? Because that folder is outside the sandbox:
______ /home//Downloads/test.txt
______ /home//media///test.txt
___ 5. Using Kwriter try to read or writer a file stored in the only folder INSIDE Kwriter sandbox at
______ /home//Documents/test.text
______ Kwriter has access to both reading and writing to this folder above. Which is a success because this folder is inside its sandbox. In other words, the app is ALLOW read and write access to “filesystem=home”. This is the challenge.
___ 6. This challenge above can be reproduce with all Flatpak apps. Not just Kwriter.
-– — — — — — — — — — — — — — — —
What we tried that did not resolved this challenge
• Restarted device
• Double-checked permissions for ALL apps (global). Using:
•___ Flatseal
• Double-checked permissions PER app. Using:
__• Command: flatpak info --show-permissions <APP.NAME>
__• Flatseal
• Installed new Flatpak app. Which was never installed before. Denied its access to any file or folder. That app also has access to all files and folders.
• This challenge can always be reproduced. For all Flatpak apps. But only with one and same device. We are not able to reproduce this challenge on any other devices. Still on that device, sandboxing was successful. But then, somehow stopped. Beside what we already tried, which his listed down below, what could potentially be causing this challenge?
• Searched tickets at [https://github.com/flatpak/flatpak/issues\\\\\\] and Found no result.
• Created a ticket with Flatpak engine. A maintainer replied. The maintainer claimed to not understand that ticket. Then, close that ticket without asking any question at https://github.com/flatpak/flatpak/issues/6667 We are assuming good faith from that maintainer. Maybe my ticket was not clear.
-– — — — — — — — — — — — — — — —
ID
Ignore this line. This is a note to myself: ID_E3T4Z2C4
I would assume that the only issue here is an misunderstanding.
Yes, an Flatpak can gain default access to selected folders by having a filesystem permission set.
However, there is a second system to access user files, which is the FileChooser portal. As a very basic explanation: Over the portal, the application tells the system it wants to open or save a user-selected file. The system then shows the user the file picker, outside of the sandbox or control of the application, to pick the file. Then the system grants the application access to only the selected file.
Now, to the user, this process is transparent. Because the assumption is that a user would want an application to have access to a file they selected.
And since the portal access is granted separately over an secure process, it is not governed by the filesystem permissions. The application will still only be able to have access to the files you have granted it access to.
So, based on my reading of your issue, this should be a non-issue.
But, if you want to confirm the sandbox is really working, here is a quick test you can do:
Run flatpak run --command=bash org.freedesktop.Platform//25.08. The Freedesktop runtime has no permissions whatsoever. So, if you then try to access files from your home using ls or less or any other command inside the sandbox, it should not even able to know about the files.
If that is not the case, then there is an issue. Otherwise, it is likely the misunderstanding mentioned previously.
Hello @CodedOre . My replies are below.
But, if you want to confirm the sandbox is really working, here is a quick test you can do:
Run
flatpak run --command=bash org.freedesktop.Platform//25.08.
Thanks for your suggestion 
. I will try this when I am available. Then post the result here.
Yes, an Flatpak can gain default access to selected folders by having a filesystem permission set.
All global filesystem Flatpak permissions are denied. Same for the app filesystem Flatpak permissions. They are all denied. Detailed configuration about this is in my original post up above. Maybe my original post was not clear about this.
The sentence you quoted was mainly meant as part of the explanation that there are two ways a Flatpak can gain access to files. Maybe that could’ve been worded better.
Also, in your original post you did say you have set a filesystem permission for the application, for the documents folder.
@CodedOre Your information about the Debian file manager Portal helped to narrow down the source of the challenge. Thanks again for that.
We were able to reproduce this challenge 100% of the time. On different devices. With multiple Flatpak apps. Which are not using the Flatpack Portals. Meaning those apps can directly access files outside their sandbox.
Per the apps maintainers’ preference, we are contacting them privately about that potential security vulnerability for their consideration and their decision. Waiting their reply.
EDIT: Within the context of this challenge, synonyms of the Portals resolved challenge are, but not limited to:
- Debian File Manager
- File Manager
- Flatpak Portals
- XDG
Below is the same as above. But with details if you’re interested in those.
For reporting such potential security vulnerability, for stronger security, usually maintainers prefer to be informed privately. So that, if appropriate, they have an opportunity to adapt their security before the vulnerability is public. First, we’re trying this. Then, we will wait for their replies. Next, if appropriate, the maintainer might publish either all or part of their private ticket.
This challenge can only be reproduced when combining those 4 parts:
- Flatpak engine
+ - Runtime(s)
+ - Default permissions of the Flatpak app
+ - Flatpak app
Using the same Flatpak apps, the challenge can’t be reproduced when testing only one part. This is normal. Because, most Flatpak apps combine those 4 parts up above.
Your other suggestion about flatpak run --command=bash org.freedesktop.Platform//25.08 was useful. Thanks again for that. Our test result is that both KDE runtime part or Freedesktop runtime part, when use alone, successfully blocked access to folders and files outside its own sandbox. Per above, all 4 parts are needed to reproduce this challenge.
About the Debian file manager. I learned something new. My updated understanding is that if a Flatpak app uses the Debian file manager to access folders or files. Then, the permissions are controlled by the file manager. Not by Flatpak. In other words, the file manager overrides and cancel the Flatpak permissions.
In my personal experience, with Debian 12, for the past years, the Debian file manager, somehow was not able to override and cancel the Flatpak permissions. This started a few weeks ago. According to XDG contributors, this is normal because the XDG packages, which power part of the Debian file manager, XDG was not yet stable enough to be able to override Flatpak permissions. One of the recent XDG update fixed this.
So the above rules out de Debian file manager has the cause of the challenge.
While at the same time, this rules in the combined 4 parts listed above as potential cause of the challenge.
In other words, we made some progress
Also, in your original post you did say you have set a filesystem permission for the application, for the documents folder.
Yes and no. I hope the following clarifies, per my original post:
- Yes because the Flatpak apps are configured to ALLOW them to access folders and files WITHIN their sandbox.
- No because the Flatpak apps are configured to NOT allow them to access folders and files OUTSIDE their sandbox.
The challenge is with the apps access to denied folders and files located outside their sandbox.
Anyhow, as you know, this challenge can also be reproduced with Flatpak apps that have no filesystem permission. Including, but not limited to, not allow access to Documents folder.
bztd 6
I think it would always be good to provide a dialog box explaining the operation in which permission is granted through this method, at least sometimes, so that users are aware of what they are doing. I have a question I haven’t looked into regarding this method: does the connection to the file or directory close when the application closes? I think I’ve had to kill some processes for that reason, although I’m not sure.
A file chosen over the FileChooser portal stays accessible, even across sessions. The documents portal stores which files has been access given to.
This is done to also allow setups where an application would regularly use the file/folder in question. You can use flatpak documents to see which files an application has access to and flatpak document-unexport to remove the permissions.
So, similar to Ubuntu’s prompting system for snaps?
I’d think that just gives friction. Most user will want to give an application permission to the file if they choose it in the FileChooser. So, such a dialog would likely just quickly clicked through to get to the work they want to do.
The portal works transparently in order to not slow the user, while still maintaining a solid access control to the files.
If you think an prompt before using the FileChooser portal is necessary, feel free to implement your own FileChooser portal backend that does add this dialog.
@Francewhoa I recommend re-reading CodedOre’s answer and analysing how FileChooser portal works in depth, as it seems to me you are calling a security vulnerability something that just isn’t.
bztd 10
The problem with persistence is that it doesn’t let you cleanly remove a removable drive because it’s marked as still in use.
AFAIK that should not be a problem, since the bind-mounts are removed when the sandbox is closed.
Its only the access permission itself that is kept. When the application is started again, the mounts would be restored.
I recommend re-reading CodedOre’s answer and analysing how FileChooser portal works in depth
@barthalion Thanks for your suggestion. Per my previous comment. Two days before your published your suggestion I was up to speed about portals. Also back then, I read this useful documentation at https://docs.flatpak.org/en/latest/desktop-integration.html#portals
The portal resolved part of the challenge. The not yet resolved other part of the challenge is that we were able to reproduce this challenge 100% of the time. On different devices. With multiple Flatpak apps. Which are not using a portal. Including, but not limited to, not using the Debian file manager portal. This is the main remaining challenge. Details in my https://discourse.flathub.org/t/sandboxing-stopped-flathub-apps-have-access-to-all-folders-and-files-outside-their-sandbox-what-could-cause-this-challenge/12244/5
I’m sorry, but I still think you just misinterprete the way the FileChooser portal works and is presented.
Just alone for the fact you call it the “Debian file manager portal”. There is neither a “Debian file manager” nor does it have a portal implementation, due to it being nonexistent.
If you’re unable to reproduce it with the runtime, then Flatpaks sandbox should work as expected.
But, just for the sake of argument, you could test this with an application as well with this command:
$ flatpak run --sandbox --socket=wayland $APP_ID
With the --sandbox argument, all usual permission for an application will be unavailable, as well as all portals.
The Wayland socket is the only thing the application will have access to due to the --socket=wayland argument. If you’re on an X.Org desktop, replace this argument with --socket=x11 instead.
When run with this command, the application will only be able to access the files inside the sandbox. I highly suspect you will not be able to reproduce your issue in that environment.
Dear @CodedOre Thanks for your invitation for discussing the off-topic and resolved challenge about the portals. But I am not interested.
I prefer continuing to wait for the on-topic answers from the maintainers of the affected Flatpak apps. Details about this is in my May 24th, 2026, comment at https://discourse.flathub.org/t/sandboxing-stopped-flathub-apps-have-access-to-all-folders-and-files-outside-their-sandbox-what-could-cause-this-challenge/12244/5
For your convenience, here is an extract from that comment above: “We were able to reproduce this challenge 100% of the time. On different devices. With multiple Flatpak apps. Which are not using the [portals]. Meaning those apps can directly access files outside their sandbox. Per the apps maintainers’ preference, we are contacting them privately about that potential security vulnerability for their consideration and their decision. Waiting their reply.”
The portals are not off-topic to this discussion.
They are an integral part of how file access is securely managed by Flatpak.
But I’m not repeating that explanation again. You seem to have already decided what you want to hear. You don’t seem willing to understand the situation and learn something new.
Well, there is no point trying to explain something to someone who doesn’t want an explanation. So I won’t bother anymore.
There is, to my best understanding, no security issue present based on what you reported. Its is the sandbox, portals and access restriction systems working as designed.