Requesting access to known files or directories

[ryanabx]

Currently, the way flatpak handles access to known files and directories is a static permission (--filesystem=*).

In order to move those permissions to dynamic permissions, there should be a way for apps to request access to a specific directory or file(s) on the host system.

Why not the file chooser portal?

There are many use cases where the file chooser portal in its current form doesn't work for what an app needs.

• The file chooser portal asks the user to specify the directory for the application. The ux of this can be iffy especially if an app needs access to a certain very nested folder (i.e. a mod manager asking for access to the game folder for example).

• If the application needs access to multiple folders, they will have to pop up the file chooser portal multiple times to get access to everything.

• The file chooser portal currently does not work when selecting the root folder. This means that file managers that need access to the host's root folder, cannot use the file chooser portal.

[Mikenux]

The rule is still to let the user choose what it gives to an app. Asking for a specific directory with Allow/Deny responses is too restrictive. We can handle this case for the "library" portal.

For example, the minimum would be the use of hints. With a "music" hint, the user will be presented with the options to give the xdg music and to add other locations. Possibly, a "filesystem" might be use and the interface shows the root folder with a warning, and also other folders so the user knows they can choose. What I mean is that the interface can be tweaked, the key thing being the user able to limit access to files.

[ryanabx]

The rule is still to let the user choose what it gives to an app. Asking for a specific directory with Allow/Deny responses is too restrictive. We can handle this case for the "library" portal.

The USB portal requires the sandboxed app to specify ahead of time which usb devices it supports (https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/usb-portal.md#device-filtering). Why can't we do something similar but for directories/files?

The library portal is a step in the right direction, and I like it in general, but I don't believe it does enough. With modifications it definitely could. I don't know if we want to merge use cases here, but I think the app should have some input on what directories show up in the library portal.

For example, the minimum would be the use of hints. With a "music" hint, the user will be presented with the options to give the xdg music and to add other locations. Possibly, a "filesystem" might be use and the interface shows the root folder with a warning, and also other folders so the user knows they can choose. What I mean is that the interface can be tweaked, the key thing being the user able to limit access to files.

This does not fit my suggested use case of a replacement for static filesystem permissions. If a mod manager needs access to ~/.var/app/com.valvesoftware.Steam/data/<MOD_MANAGER_NAME>, it can't request that with a hint. It could ask for the entire home directory, or .var, but that's less secure.

I agree that the user should be able to limit access to files as much as they'd like. I think the middle ground is a system where the app specifies what directories it would like access to, and the user can pick and choose which ones it shares with the app. There could also be a way to add directories to this list, if we wanted that.

[Mikenux]

The USB portal is another case where it is about accessing devices not files. For devices, a specific list can be presented because the user has or not the intent to use a device. For files, even if the app specifies directories, without offering the option to choose another ones, the user choices are still limited (also, we don’t know which directories the app can request), while they should not, at least in the case of a file manager. What I said should be sufficient for the file manager case (note that other restrictions may apply such as read-only access, use of a "write access" portal).

For the case of writing to another directory that belongs to another app, that’s also another case. Relative to sandbox, that’s a prohibited thing as it is not something requested by the other app (e.g, that’s not Steam that requests to have a mod’s files within its files). To write to files belonging to another app, a trust model between apps might be part of the solution. This requires further thinking to handle that nicely. To leave a note on this: we can also wonder what to do when a library (logically, the Steam library should be part of user files, not of the Steam app) has new files that aren’t especially expected by an app that has access to this library.

[ryanabx]

This line from the libraries portal suggestion gives me some confidence that it'll fit my use case:

The locations should be the same as shown in the File Manager but it should be possible to add custom locations.