I recently came across an app that calls g_app_info_launch_default_for_uri to have the default application open a local file. As expected, confinement prevents this from working. If the snap happens to have the browser-support interface connected with allow-sandbox=true, a known leak in the profile (/var/lib/snapd/desktop/applications/{,*}) means that the snap will see desktop files for other installed snaps, but it will still fail to launch them.
The quick answer to that is, I guess, to patch the app to use xdg-open, and hope that one day in a not-too-distant future the snapd proxy for xdg-open learns how to handle local files, not just https? links.
I wonder whether anything else could be done, in case patching the upstream code is not convenient/feasible? g_app_info_launch_default_for_uri is a public API, it’s probably being used by quite a few apps out there.
Note: this forum software is trying too hard to be clever, it stubbornly refuses any topic title that contains “g_app_info_launch_default_for_uri” because it thinks it’s not a complete sentence. This is annoying, I think the title would have been much more descriptive as “Opening a local file with g_app_info_launch_default_for_uri VS xdg-open”.
Yes, xdg-desktop-portal’s URI opener should handle this. It has specific support for local files, requiring the caller to pass a file descriptor to prove it can read the file to be opened:
Unfortunately, the portal support in GLib/GTK is an all or nothing affair: you can’t easily tell it to use xdg-desktop-portal to open URIs but not for file chooser dialogs. And supporting the file chooser portals requires changes to the way we build the mount namespace for the confined app. We’re getting close, but are not quite there.
Apps using the Snapcraft gnome extension should be opted into portal support by default these days.
That doesn’t really help with the problem @oSoMoN was talking about in this thread though: by making the desktop files in /var/lib/snapd/desktop/applications visible to snaps that plug browser-support, glib will try to launch those applications directly rather than go through portals.
A more effective fix might be to try and clean the XDG_DATA_DIRS environment variable. If /var/lib/snapd/desktop is not in the list, then the browser won’t try to launch them directly.
All things considered, it might be worth having snap-confine reset the variable the same way it does for PATH. Given that a strict confined snap runs with a different mount namespace, there isn’t much it can do with the host system’s value of the variable.
