Real directory name not accessible from file opened via document portal

[chergert]

Currently, when accessing documents via the document portal we're provided with a file in the format of /run/user/1000/doc/abcdef/filename.txt. This is fine and a nice way to implement things using a FUSE mount to ensure access.

However, it's very problematic for applications like text editors. We want to provide information to the user about what file was accessed (including the path). We also want to allow the user to open a file browser or terminal where that file exists. Both of these things are impossible currently unless we grant access to $HOME or get lucky with access like xdg-documents or something like that.

I know it's a bit extra work, even for applications, but perhaps we could add a new G_FILE_ATTRIBUTE_STANDARD_DIRNAME that could grab an extended attribute from the FUSE driver.

My main argument is that I don't think there is value to obscuring a directory path from the application even if that is not how they access it. As a user, browsing to a directory and selecting a file certainly doesn't convey to me that the application wouldn't know where that file was (even if it accesses it via another path). It feels very much like an implementation detail due to how FUSE works, and if so, it would be nice to find a workaround for applications to exist with stronger sandboxing even for this use case.

[hadess]

We also want to allow the user to open a file browser or terminal where that file exists.

The OpenDirectory portal does just that:

Asks to open the directory containing a local file in the file browser.

I'm not sure why the application needs to know what the name of the directory the file is in is.

[hadess]

Also, adding a G_FILE_ATTRIBUTE_STANDARD_DIRNAME attribute won't fix the terminal use case either.

[chergert]

I'm not sure why the application needs to know what the name of the directory the file is in is.

Because in a text editor it's helpful to give context to the user as you might have multiple files with the same name in different directories.

For example, Makefile.

[hadess]

So, this use case: #463 ?

Sorry misread that. But it still doesn't fix it for gio/tests/meson.build vs. tests/meson.build (as I've seen happen).

[chergert]

Additionally, it's nice to open a new GtkFileChooserNative in the same location as the focused file. If you can't actually get that location, you always end up at $HOME or Recent or something annoying like that.

[hadess]

Additionally, it's nice to open a new GtkFileChooserNative in the same location as the focused file. If you can't actually get that location, you always end up at $HOME or Recent or something annoying like that.

I've filed this as #477

[sophie-h]

Both of these things are impossible currently unless we grant access to $HOME

I'm struggling with the same issue for Pika Backup. However, I'm not sure if the portal is supposed to give me the correct path with --filesystem=host? Text Editor seems to be able to show the correct path inside the user's home while using GtkFileChooserNative inside flatpak. However, I cannot reproduce this behavior.

Can someone update me what's the exact status of this issue?

[chergert]

I'm struggling with the same issue for Pika Backup. However, I'm not sure if the portal is supposed to give me the correct path with --filesystem=host? Text Editor seems to be able to show the correct path inside the user's home while using GtkFileChooserNative inside flatpak. However, I cannot reproduce this behavior.

Text Editor can show the correct path because while we use GtkFileChooserNative, we don't use the document portal FUSE because the logic in Flatpak knows we can access it by the real path (due to how it scans for symlinks and having set --filesystem=host).

However, you can see where this breaks by opening Nautilus and browsing to somewhere like /etc and opening a file. In Text Editor it will show as /run/user/1000/... because the /etc path isn't available to the Flatpak container.

[sophie-h]

I didn't get the correct filename because of some strange issue with my build system.

Maybe worth adding to the portal docs that the returned path is not always in /run/.

[septatrix]

My naive first guess would have been that all application simply access files through an overlayfs or similar and that paths (once given the permission) would be accessed at the original URL as it is currently done when using e.g. --filesystem=xdg-download. This evidently is not the case (and according to @smvc in flatpak/flatpak#4543 (comment) changing this would break other features - not sure what exactly would be affected though).

I would also like to add the problem in which this affects me. For me the problems first showed up once org.telegram.desktop locked down permissions even further by removing xdg-download and going full in on portals. Currently there are still a few issues on their side (like telegramdesktop/tdesktop#25390) but in general I think this is something other apps are likely to do in the future. Now, when opening downloaded files from the app I obviously land in some /run folder which is annoying. However, the more annoying part is, that this also clash with opening downloaded files when the handler is another flatpak application (which obviously does not have access to the same /run directory). Opening e.g. an xlsx file instead only shows an empty page. (Actually the usual handler should be Libreoffice but I guess that does not get discovered from inside the Flatpak?) Regardless, the user experience is bad and there is no workaround.

[fastrizwaan]

This bug is still present with ro access. --filesystem=host works, but --filesystem=host:ro or --filesystem=home:ro causes this bug with freedesktop sdk 22.08.
flatpak/flatpak#5413