{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidrqwnzsgyl7u5hpljembsnj4zhfbafpaac63uftao7q3fis7vbeu",
    "uri": "at://did:plc:yrn4rbgwenb6lfhhzjegbtnc/app.bsky.feed.post/3mgw2c45bbhk2"
  },
  "path": "/t/how-much-filesystem-permissions-are-too-much/11847#post_2",
  "publishedAt": "2026-03-12T21:38:24.000Z",
  "site": "https://discourse.flathub.org",
  "tags": [
    "discussion in the PR",
    "Xfce for Thunar",
    "documentation"
  ],
  "textContent": "Since this was posted in the Discourse as a general question, I give an general answer first.\n\n* * *\n\nIn an ideal world, we would have no filesystem permission.\n\nYou may ask why.\n\nAs I can see it, there are generally two main types of how an application interacts with the filesystem.\n\nThe first is data that the application stores itself without user input. That would be configuration, save states, cache, etc…\nFor these types of data, we have standard locations to store them in, as specified in the XDG base directory specification. This specification also defines environment variables to override them if the need arises.\nFor Flatpak, such a need existst: It wants to separate the application data from the system. This ensures applications can’t affect the system itself. Keep in mind a Flatpak application might run with newer libraries than the system. It also allows that data can be easily removed when the application is uninstalled.\nFor this reason, Flatpak gives each application its own folder, located under `~/.var/app/$APP_ID`, and provides overrides for the standard locations to point into that application folder.\nA filesystem permission would break this separation, which is why permissions like `xdg-data` or `xdg-config` are usually not permitted.\n\nThe second use is for data the user can manually organize.\nNow, no user uses a filesystem in the same way. Some meticulously organize their files with deep folder structures. Some just throw every file onto the desktop and still somehow find the files they need. Some store files on external or network drives.\nUsers will pick whatever suits their needs best when it comes to where to store their data. Therefore, applications should be flexible enough to allow users to choose from where the files come.\nBut granting software unlimited access to the whole filesystem can be dangerous. It doesn’t even have to be malicious. It could just be a bug that suddenly results in an application deleting data it wasn’t supposed to.\nFor this reason, an application should only be granted access to the files the user actually wanted the application to use, instead of broad permissions.\n\nUnfortunately, for a long time the applications itself provided the file chooser in their own process. Inside a Flatpak, this would lead to applications only seeing their own sandbox. Partly because of this early Flatpak apps had large filesystem permissions to allow the file chooser to work.\nTo solve this, the FileChooser portal was introduced. With it, the application no longer provides a file chooser. It simply asks the system that it needs a file. The system then provides the file chooser dialog to the user and grants the application access to the file the user chose.\nIn many cases, if an application uses portals, it should not need any filesystem permissions. The user can freely choose where they store their files, and the application can request the access it needs over an secure process.\n\nThere are unfortunately still exception to this. Using the portals requires active changes to the code to utilize them. Most modern toolkits like GTK or Qt do support them now, but it can require effort to change an large codebase of an old app.\nAnd there are cases which require more files than the one the user explicitly requested. Think for example a HTML file which may have a reference to a separate stylesheet file. Designing a good portal for these which balance security and usability is still an open issue.\n\nBut such exceptions to the rule should be carefully evaluated. And new applications should consider an UX design that fits with using portals.\n\nSo, in short:\nThe ideal amount of filesystem permissions should be none. Applications should respect the standards to store internal data and respect user choice over their file organization by using the portal for user data.\n\n* * *\n\nNow, a note specific to your submission:\n\nAs far as I could tell from my quick test run, your application should be able to utilize the FileChooser portal. And it does on my system. So it should be able to do its tasks just fine, even without a filesystem permissions.\n\nThe issues you’ve shown in the discussion in the PR seemed to me more that on your system, the application failed to call the FileChooser portal, falling back to the internal one. This could be due to no portal implementation being active on the system to show the file chooser on the system.\n\nGNOME and KDE have their own portal implementations and should work in most cases. Some of the smaller desktops have not at the moment. Some have an interest in providing their own file chooser, such as Xfce for Thunar, but haven’t completed that yet.\n\nFor these, `xdg-desktop-portal-gtk` provides a simple file chooser implementation to use in the meantime. If installed and configured to be used (see the documentation for this), it should provide it.",
  "title": "How much filesystem permissions are too much?"
}