search

flatpak / xdg-desktop-portal

Desktop integration portal
https://flatpak.github.io/xdg-desktop-portal/
GNU Lesser General Public License v2.1
568 stars 187 forks source link

Directory access request portal #663

Open Taiko2k opened 2 years ago

Taiko2k commented 2 years ago

I have a music player application where I really want permanent absolute r/w access to a given directory tree. (Typically when the user drag and drops their music library folder). But having default filesystem=host is overkill.

Basically I'm suggesting the following workflow:

  1. User specifies/opens/drag'n'drops a folder.
  2. A UI is shown to the user X app requests access to Y path Y/N?
  3. Effectively a filesystem=path permission is granted and applied immediately. (Is this technically possible?)

For me there really is no substitute for full access since the application provides file management like features. I imagine other apps could also benifit from this.

Currently to work around this issue I have my application direct the user to install flatseal in order to grant access, but that's not a great user experience.

vchernin commented 2 years ago

So this is meant for apps wanting to be a file manager? I am not sure whether it makes sense to have a portal for this. Should there be portals that give massive access to the host?

Maybe instead FileChooser could gain a restoration mechanism similar to what ScreenCast just got?

Taiko2k commented 2 years ago

My app wants to opperate like a file manager but only specific directory trees. I imagine pure file managers would want filesystem=host.

The document portal works fine for applications that work on single files, I don't think that should be changed. But its insufficient for applications that work on folders. There's some crossover with #463 here but what I'm looking for really is filesystem= like functionality.

I imagine this could be useful for apps like IDEs, video editors etc that want to open project folders from external locations.

As I'm imagining it, app developers would have to code for this portal specifically.

Maybe access to this portal could be hidden behind its own permission to limit further discourage its use. But still provide an alternative to full host access.

ghost commented 2 years ago

The document portal does support directories. Try specifying an app ID with -a and a directory path in flatpak document-export and see for yourself. File choosers support it already too.

hadess commented 2 years ago

The document portal does support directories. Try specifying an app ID with -a and a directory path in flatpak document-export and see for yourself. File choosers support it already too.

Indeed, I added that for rhythmbox, and that's what it uses to get access to a "library" directory. You just need to use the correct GTK file chooser to use it.

Taiko2k commented 2 years ago

My application only uses drag and drop, so using a file picker would require modifying the design of my app. (Looking at the docs, d&d seems to be handled by the FileTransfer portal which says it doesn't support directories.)

In any case I'd also strongly prefer that the file paths are not rewritten, as these are shown to the user.

hsitter commented 2 years ago

I believe there is a core use case here. If you drag a directory from your unconfined file manager, then you should also be able to drop it on any app regardless of sandboxing state. Think dragging a directory into VLC to play the entire thing. Currently that isn't possible because FileTransfer AddFiles explicitly doesn't support directories.

smcv commented 2 years ago

Effectively a filesystem=path permission is granted and applied immediately. (Is this technically possible?)

Sorry, no, this is not technically possible, unless Flatpak was changed to mount initially-empty FUSE filesystems covering all non-sandbox-accessible, non-sandbox-overridden directories inside the sandbox, just in case the app is later given permission to access a directory on the host, at which time the FUSE filesystem would have to make it appear inside the sandbox. (Basically overlayfs-like behaviour in user-space, but with all paths except those that are covered by permissions initially invisible, and some sort of IPC for the portal to ask it to make paths appear, dynamically, when permission is granted.)

I don't think anyone is particularly keen to write that FUSE filesystem, which would be both security-sensitive and performance-sensitive.

In any case I'd also strongly prefer that the file paths are not rewritten

Sorry, this is not technically possible without using a FUSE filesystem as above.

Mart-Bogdan commented 1 year ago

I completely support this Issue.

And also, as I understed the problem, why file chooser is not so good. This access to directory should persist across application restarts.

So you slect directory with your media library once, and then being able to listen that music all the time.

GeorgesStavracas commented 11 months ago

This is not much different from using the FileChooser portal's OpenFile method, with the directory option set to true.

Mikenux commented 11 months ago

@GeorgesStavracas: You added the "need more info" tag, but what type of info is missing?

GeorgesStavracas commented 11 months ago

A clearer understanding on how this request differs from using the FileChooser portal's OpenFile method with the directory option set to true, and why that would be a sensible thing worth supporting (i.e. what are the alternatives, and why they're not suitable?)

Mikenux commented 11 months ago

Sorry, but which part of this request need understanding?

The first part is having the FileTransfer portal supporting folders. This is https://github.com/flatpak/xdg-desktop-portal/issues/911. On this, I don't think this needs understanding as the only alternative for this is, like you said, the file chooser. But if drag and drop is available for files, why not for folders?

The second part is about having file paths to offer some file manager features.

The third part is having permanent access to the dropped folders ("libraries").

12people commented 8 months ago

I have similar use-case, just for getting persistent access (i.e. access that persists across restarts) to a specific file.

I'm working on a todo app that follows the Todo.txt spec — keeping the todo list inside a single text file, which can also be read and written to by other apps. As such, I need persistent access to this one todo.txt file.

hfiguiere commented 8 months ago

The first part is having the FileTransfer portal supporting folders.

This has actually been fixed.

theotheroracle commented 1 month ago

the biggest issue i've run into is that access to a folder doesnt persist after reboot, so many apps simply get full home directory access by default or need modification of permissions through flat seal and it's really suboptimal .

hfiguiere commented 1 month ago

the biggest issue i've run into is that access to a folder doesn't persist after reboot,

That's probably because the folder in question hasn't left the sandbox. I suspect said application doesn't use the file portal, and wrote the folder in location not exposed by a --filesystem. This is the intended behaviour.

Mikenux commented 1 month ago

@hfiguiere: I used Amberol (which supports DND and session restore), and it does not restore dropped files or folders. Just log out and log back into the user session. Files and folders added via the file manager are restorable.