[RFC] A "scoped storage"-like portal

refi64 commented 5 years ago

The rationale

The file chooser portal is great, but currently it doesn't allow opening directories. Of course this is intentional, since that would open up quite the potential security hole.

However, this also means two things:

If an application needs some storage access, it needs all storage access. Say I'm writing an email client that needs to be able to save all attachment to a folder, now the email client will need full, unmonitored filesystem access, either:
- Access to just some xdg directories, e.g. xdg-download. Problem: if a user wants to save to e.g. Documents, they either need to save to downloads then move the files, or manually add access to xdg-documents. There's no UI indication for this.
- Access to the entirety of filesystem=home. This may be a more viable option for e.g. OSS apps built from source, but it also means that if there were some security issue in the client, an attacker would have access to things like my gpg and ssh keys...but all I wanted was to flexible save groups of attachments.
Even if the above is resolved, not being able to use the native file chooser means that users of platforms other than what corresponds to the app (e.g. a GNOME user with a KDE app, or a KDE user with a GNOME app) will get the app framework's file dialog instead of the system's native file dialog.

There are some other similar problems, like VLC needed full filesystem access to be able to work with playlists and the like (even though it may be reading files from the internet and therefore should be constrained somehow).

Scoped storage

Android had a similar issue, and the solution they took inspired this post: scoped storage. Scoped storage and the Storage Access Framework are a lot like portals, but there's a bit of extra behavior that makes them more flexible. Consider the following scenarios:

An app like GNOME Music needs to have access to the location(s) where the user has stored music.

On launch, Music calls into the portal, passing a flag to signify that persistent access is required, and the portal will open a dialog where the user can select what directories to give the app access to. The app can also give a "suggested directory" from a pre-defined list (e.g. the app could suggest an XDG directory, in the case of Music, xdg-music). This would presumably also be accessible through Preferences for later access.

Upon selecting a directory here, there would be a warning that the application is gaining full access to the directory. Since this goes through the document portal, it could also add some other safety behavior, e.g. hide dotfiles by default unless the user selects otherwise, or show a bigger warning if the user tries to select something like home.

Now, Music has access to the given locations. If the user ever needs to change or revoke access, they can easily. However, because it's more restrained, if the user downloads something like a malicious music file, it can't access anything outside of what's already allowed without setting off alarms. Presumably, there would also be an API to get the list of directories and their corresponding document portal locations, so that Music can bridge what's picked up from Tracker with the portal-mounted locations.

(Side note: off the top of my head it would be really cool if there were somehow a portal that integrates into search frameworks like Tracker and Baloo but that would be a far bigger step.)
An app like VLC may have to load files outside of what's been selected.

If the user opens something like a playlist, VLC will show a dialog saying the locations that it needs read-only access to, and it will ask the portal to open up a directory chooser, except this isn't really required to be persistent. The portal will ask the user whether they want the access to be permanent or temporary, and now VLC has the needed access without compromising other areas of the filesystem.
A batch video rendering app needs to select an output directory. It will follow a similar flow as above, except it will be requesting read-write access.

The summarized API

So with all that laid out, here's how I imagine the API might look:

org.freedesktop.portal.Storage

OpenPersistentStorageAccessList(
  IN s parent_window  # same as usual
  IN a{sv} options
    # valid options:
      hints as (e.g. ['xdg-music', 'xdg-download'])
      rw-default b (e.g. true / false, default false)
  OUT o handle
)

GetPersistentStorageAccessList(
  OUT a(ss)  # list of pairs (host path, document portal path)
)

OpenDirectory(
  IN s parent_window  # same as usual
  IN reason s
  IN a{sv} options
    # valid options:
      rw b (e.g. true/false, default false)
  OUT o handle
)

Closing notes

Of course the specifics are all up for debate, but I just thought this would be a helpful addition to the current system, since it would make permissions a lot less coarse overall.

TingPing commented 5 years ago

The file chooser portal is great, but currently it doesn't allow opening directories. Of course this is intentional, since that would open up quite the potential security hole.

Its not intentional; Its a hard problem.

Anyway this discussion belongs on xdg-desktop-portal.

matthiasclasen commented 4 years ago

How is this different from just plugging a hole for XDG_MUSIC ?

TingPing commented 4 years ago

That it is dynamic and chosen by the user not the packager.

@alexlarsson and I discussed alternatives at GUADEC. For example having everything written to a private directory and then exposing them to the host, rather than the reverse.

refi64 commented 4 years ago

Pretty much, that way you have a sort of bridge between opening directories and having controlled access.

On Tue, Sep 17, 2019, 9:40 PM Patrick notifications@github.com wrote:

That it is dynamic and chosen by the user not the packager.

@alexlarsson https://github.com/alexlarsson and I discussed alternatives at GUADEC. For example having everything written to a private directory and then exposing them to the host, rather than the reverse.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/flatpak/xdg-desktop-portal/issues/334?email_source=notifications&email_token=AAM4YSOCRAZY3UPQ3LIDFPDQKGILTA5CNFSM4HREMIA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD66TKRY#issuecomment-532493639, or mute the thread https://github.com/notifications/unsubscribe-auth/AAM4YSOIQL3CQIMW2H7I7RDQKGILTANCNFSM4HREMIAQ .

matthiasclasen commented 4 years ago

I don't understand the description. You say the app calls into an api after it is launched - so that is just a portal ? Why is it important that it is called at launch ? And it doesn't explain how the application gets access. Your api sketch sounds like you just want to put directories into the document store after all, which, as is well-known, is problematic.

refi64 commented 4 years ago

You say the app calls into an api after it is launched - so that is just a portal ? Why is it important that it is called at launch ?

That was just an example for a music app, which would presumably need to know what music directories are available to show the user.

Your api sketch sounds like you just want to put directories into the document store after all, which, as is well-known, is problematic.

...touche on that, I guess maybe this could also bind mount into a directory visible by the Flatpak or similar?

Mikenux commented 1 year ago

Linked issue: https://github.com/flatpak/xdg-desktop-portal/issues/133

Telling the user that a folder or files will be permanently accessible by an application seems make sense, assuming the access to the selected folders/files is temporary. However, this means revisiting the fact that apps retain access to all files they have open, even after they are closed.

Mikenux commented 11 months ago

The case of VLC belongs to neighboring files.

To warn about permanent access, it would be better to warn about it directly in the file chooser.

For hidden dotfiles, it would be best not to access them unless there is a reason.

Presumably, there would also be an API to get the list of directories and their corresponding document portal locations, so that Music can bridge what's picked up from Tracker with the portal-mounted locations.

Maybe open another issue explaining better what is expected?

I'm wondering if it's possible here to only have read-only access and write access for specific cases, or if I should consider that for https://github.com/flatpak/xdg-desktop-portal/issues/808?

flatpak / xdg-desktop-portal