Hello Guys,
During my last submission PR I was not even allowed to keep a very mild –in my humble opinion–
- –filesystem=xdg-documents/myapp:create
in the yaml manifest.
I felt overly shredded to pieces.
This reduces the app user friendliness.
So my kind question to you is
How much permissions is too much?
I hope you will help me understand better.
Thanks a lot!
Since this was posted in the Discourse as a general question, I give an general answer first.
In an ideal world, we would have no filesystem permission.
You may ask why.
As I can see it, there are generally two main types of how an application interacts with the filesystem.
The first is data that the application stores itself without user input. That would be configuration, save states, cache, etc…
For 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.
For 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.
For 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.
A filesystem permission would break this separation, which is why permissions like xdg-data or xdg-config are usually not permitted.
The second use is for data the user can manually organize.
Now, 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.
Users 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.
But 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.
For this reason, an application should only be granted access to the files the user actually wanted the application to use, instead of broad permissions.
Unfortunately, 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.
To 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.
In 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.
There 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.
And 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.
But such exceptions to the rule should be carefully evaluated. And new applications should consider an UX design that fits with using portals.
So, in short:
The 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.
Now, a note specific to your submission:
As 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.
The 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.
GNOME 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.
For 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.
Ah ok. Got it
I am now leaning on the possibility that the xfce-specific implementation of desktop portal might be different.
I do however seem to have these installed:
xdg-desktop-portal-1.20.3
xdg-desktop-portal-gnome-48.0
xdg-desktop-portal-gtk-1.15.3
xdg-user-dirs-0.18
xdg-user-dirs-gtk-0.14
xdg-utils-1.2.1-r9
But still there is the case where a user needs to access ~/.var residing files– that possibly the app saved them there– using the normal file manager.be it thunar or nautilus or dolphin etc. In that case the facilitation of the app to have a dedicated folder and only one in a more prominent location would be very welcome. I mean still devs can use copy-path dialogs to be pasted in a file manager but that is a bit awkward.
In any case thank you for taking the time to reply to me with such detail and clarity.
I really appreciate it.
Thanks again.
If you need to guide the user to the internal application folder, you could also use the OpenURI portal (or xdg-open) to open said folder in the users file manager.
That was very informative - thank you.
But what about the case of an app that searches files.
You point it at a directory, and it searches all subdirectories for files meeting some criteria.
Can that be accomplished with current portals and such?
It should be possible with the FileChooser portal. You can use it to request access to a folder.
As long as everything required is inside the requested folder, it should work without filesystem permissions.
I coulda sworn I’ve tried that before.
Well, I’ll give it another try. Thanks much ! I’d like to do things properly.
This topic was automatically closed after 4 days. New replies are no longer allowed.