{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreidupsfjxncbtlxx44ydcnbygra7xztzznqgqkuj52bzamokc5eq7u",
"uri": "at://did:plc:yrn4rbgwenb6lfhhzjegbtnc/app.bsky.feed.post/3mmoaj5awwp22"
},
"path": "/t/sandboxing-stopped-flathub-apps-have-access-to-all-folders-and-files-outside-their-sandbox-what-could-cause-this-challenge/12244#post_5",
"publishedAt": "2026-05-24T18:40:11.000Z",
"site": "https://discourse.flathub.org",
"tags": [
"@CodedOre"
],
"textContent": "@CodedOre Your information about the Debian file manager helped to narrow down the source of the challenge. Thanks again for that.\n\nWe were able to reproduce this challenge 100% of the time. On different devices. With multiple Flatpak apps. Which are **not** using the Debian file manager. Meaning those apps can directly access files **outside** their sandbox.\n\nPer the apps maintainers’ preference, we are contacting them privately about that potential security vulnerability for their consideration and their decision. Waiting their reply.\n\n* * *\n\nBelow is the same as above. But with details if you’re interested in those.\n\nFor 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.\n\nThis challenge can only be reproduced when combining those 4 parts:\n\n 1. Flatpak engine\n+\n 2. Runtime(s)\n+\n 3. Default permissions of the Flatpak app\n+\n 4. Flatpak app\n\n\n\nUsing 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.\n\nYour 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.\n\n* * *\n\nAbout 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.\n\nIn 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.\n\nSo the above rules out de Debian file manager has the cause of the challenge.\n\nWhile at the same time, this rules in the combined 4 parts listed above as potential cause of the challenge.\n\nIn other words, we made some progress\n\n* * *\n\n> Also, in your original post you did say you have set a filesystem permission for the application, for the documents folder.\n\nYes and no. I hope the following clarifies, per my original post:\n\n * Yes because the Flatpak apps are configured to ALLOW them to access folders and files WITHIN their sandbox.\n * No because the Flatpak apps are configured to NOT allow them to access folders and files OUTSIDE their sandbox.\n\n\n\nThe challenge is with the apps access to denied folders and files located outside their sandbox.\n\nAnyhow, 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.",
"title": "Sandboxing stopped: Flathub apps have access to all folders and files outside their sandbox. What could cause this challenge?"
}