[Feature request]: Portal granting access to files based on type

[janopae]

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Suggestion

I suggest developing a portal that allows sandboxed Flatpak apps to declare access to all files of a certain type on a computer. This might be a list of MIME types, or a list of file extensions. There might be an official lists of broader categories, like "Document files" or "Image files", for easier communication of permissions to the user.

Reasoning and use cases

The secure way for sandboxed apps to access files is to use the file-picker portal, calling it on demand and only gaining access to a small selection of files, passed over by a trusted application (the OS's file picker) to pick the file on the user's behalf.

In some cases however, the file picking portal can't be used.

This is the case if file picking itself is part of the application domain: Some applications implement special file pickers with special features for the file types and use cases the application deals with (like special previewing functionality). Some applications are made for a specific kind of file management, such as photo organisers (like Darktable or DigiKam), music organisers (such as Gnome Music) and many more.

Let alone the tons of legacy apps, using legacy toolkits that don't support the file picker portal yet. These applications are going to stay important for some years, and make a huge chunk of the applications users install using Flatpak.

Those applications currently either

1. request access to the full host file system (insecure)
2. request access to only some directories (this breaks the app [and is also insecure])

Especially 2. should be discouraged, as there is just no causality between a file being in a certain directory and opening it being a legit thing for an app to do. This not only makes this option insecure, but also breaking the app.

Why is it insecure and breaks the app?

Users don't use XDG directories like xdg-music or xdg-images to sort their files by sensitivity – an application granted full permissions to those directories gains a lot of information that it doesn't need to operate. An screenplay editor accessing spreadsheet files in the Documents directory is illegit as a music player accessing an Ardour project in your Music directory.

But an application with access on these directories also doesn't allow things that are totally legit and a core part of the applications purpose – like accessing files on removable drives, or generally outside of the corresponding xdg directories.

If an app can deal with files of a certain type (like images, documents or music), solving the problem by granting access to certain directories would require the user to manually sort all of their files by type, and store them on the same drive.

Any user error in manual file type sorting would lead to the file being inaccessible for apps declaring xdg-* directory permissions, which is not obvious to fix (as the files just don't appear in the file chooser with no indication what's wrong), and might even be hard or impossible to work around – for example if the file is on a USB drive, and there is not enough space left on the drive containing the granted directory.

In general, sorting all their files by file type into xdg-* directories is a practice that we can't expect users to follow. We have tools to separate files by file types, so no need to manually sort them by type, and do awful things like putting a music video in a different directory than the sound files from the same album, only because they have different file types.

There is however a causality between a file's type and an app opening it being legit: Apps can usually only handle certain file types (except general file apps, that deal with things like file transferring, compression etc., but they should either be happy with a general purpose file picker or need access to the full file system anyway). An app opening a file of a type that it doesn't offer to process on the user's behalf is never legit.

Unfortunately, it doesn't work the other way around – the app might still access files it shouldn't. Or do things that it shouldn't with the file that it should open (this can't even be prevented by the file picker portal). But it will still be more secure than the access based on directories, as the permission will be much clearer for a user (no need to think about which directory contains sensitive files – it is much easier to know that you have sensitive spreadsheets somewhere than where they are saved), and much easier to assess whether permissions are fishy.

And it would ensure that all legit file accessing use cases work: An app would never need access to a file of a type it can't process anyway.

[Mikenux]

What are you expecting? A permission like filesystem=home where the user is not asked, or a permission where the user is asked, e.g. at app startup?

We've seen this before on the neighboring files issue (on xdg-desktop-portal), and this means that "flatpak" must have its own file type database, because certain extensions must be assimilated to the correct type. For example, application/x-krita (for extensions .kra and perhaps .krz) should be assimilated to image/krita for communication to users. This also means that flatpak/xdg-desktop-portal developers must accept file type assimilation requests (and validate or invalidate them).

[janopae]

What are you expecting? A permission like filesystem=home where the user is not asked, or a permission where the user is asked, e.g. at app startup?

Though I'm generally a fan of asking before granting permissions, as long as filesystem=home exists, I think this should rather work the same way. If setting this up ist just a little more complicated, developers are encouraged to use filesystem=home (or filesystem=host, as this at least doesn't break access to USB drives) instead.

We've seen this before on the neighboring files issue (on xdg-desktop-portal), and this means that "flatpak" must have its own file type database, because certain extensions must be assimilated to the correct type.

Yes, you're right, that sound rather complicated. Here's the issue you mentioned for reference: flatpak/xdg-desktop-portal#463

But maybe, for the flatpak command line tool, it might be sufficient to communicate MIME types to the user, and graphical applications could care about categories themselves?

Regarding the example

For example, application/x-krita (for extensions .kra and perhaps .krz) should be assimilated to image/krita for communication to users. This also means that flatpak/xdg-desktop-portal developers must accept file type assimilation requests (and validate or invalidate them).

I think, it would be alright to not display this as "This application is going to have access to image files", but rather as "This application is going to have access to Krita files (".kra", ".krz")`, as those files are not "regular" image files.

Maybe we should think about image files in terms of "everything the default image viewer could open", while everything more special is an extra category, probably a custom category.

This still leaves the problem how graphical applications should name these categories, so that you can't create the custom category "Images" to trick users into believing your application has only acceess to image files. Maybe, custom categories could be prefixed and the exact list of MIME types always exposed?

[Mikenux]

Personally, I need type assimilation for my proposal for neighboring files (while it is not approved in any way). For the Krita example, it was indeed for the case of an image viewer. We can also say, for the specific case, "Access to Krita image files". SVG is not a "regular" image file but its type is generally "image".

For the database, I think it is better if all parties agree on types. That said, it is also specific to my neighboring files proposal, as it is more needed (i.e. limiting to one type; the Krita example was given to me as when I proposed this limitation).

This still leaves the problem how graphical applications should name these categories, so that you can't create the custom category "Images" to trick users into believing your application has only acceess to image files. Maybe, custom categories could be prefixed and the exact list of MIME types always exposed?

We can always show details 😉