@jamesh Can you have a look at this one?
So, the common theme of those two apps is Qt.
I tried installing the keepassxc snap, and its file chooser appears to be the fallback Qt one. In contrast, Qt apps outside of the sandbox show the familiar GTK file chooser. This seems to be due to the libqgtk3.so plugin from the qt5-gtk-platformtheme package, which doesn’t appear to be bundled with the keepassxc snap. It is possible that adding qt5-gtk-platformtheme to `stage-packages might help.
I don’t know if this would be enough to get the GTK file chooser to show mounted volumes though: that probably requires access to /etc/fstab (which requires the mount_observe snap interface), or talking to some gvfs daemon.
I think the best long term plan though would be to get snaps to work with xdg-desktop-portal: having the file chooser out of process as a trusted helper means it should look identical to what unconfined apps use, and can even adapt to the user’s chosen desktop (i.e. GTK file chooser on GNOME/Unity, Qt file chooser on KDE).
1 Like
@jamesh But what’s the actual reason they not seeing /media, when reportedly the application can see it without using the file chooser? That’s the piece that seems odd.
@apol Do you have ideas here?
@niemeyer: the app can browse to /media and open files just fine:
@v1kn was asking why there weren’t convenient links on the left hand side for the mounted volumes. I had assumed that the file chooser might be able to populate that panel if it had access to the /etc/fstab, but that doesn’t seem to be the case when I install the snap in devmode.
For reference, here is what the file chooser looks like if I download a matching copy of qt5-gtk-platformtheme and run the executable from the snap manually with:
QT_PLUGIN_PATH=$PWD/usr/lib/x86_64-linux-gnu/qt5/plugins:/snap/keepassxc/current/usr/lib/x86_64-linux-gnu/qt5/plugins LD_LIBRARY_PATH=/snap/keepassxc/current/usr/lib/x86_64-linux-gnu/ /snap/keepassxc/current/usr/bin/keepassxc
(that’s weird: the screenshot I just took has different icons and highlight colour than what I see on my screen. No idea what’s causing that).
Including the GTK platform theme plugin in the snap would make the file chooser look like this, but it still might not populate with mounted volumes for the reasons listed above.
Nope, I was asking about /media access.
In my case, the app is not able to browse to /media
Okay. I just reinstalled the keepassxc snap to make sure I wasn’t in devmode and connected up the removable-media interface.
I can reproduce what you see with a (mostly) empty root directory:
This seems to be down to the AppArmor profile not letting the process list the root directory, so it only displays folders it knows it exists. If I type /media/james into the “File name” box though, I can navigate to the removable volumes:
So again, this could be addressed by loosening up the AppArmor confinement so the file picker can drill down to the removable volumes, but we’d need to think carefully about whether that is desirable: it may reveal more information about the system than we want.
I know I must sound like a broken record bringing up portals here, but they really should help here. By moving the file picker out of process to an unconfined trusted helper, many of these problems go away. Since it is unconfined, it won’t get stuck trying to list the root directory. And since the portal is responsible for making the document available to the confined app, it would make it possible for an app like keepassxc to run without either the home or removable-media interfaces and still be able to open files in those locations.
You are correct, this does indeed work. Naturally very few users would figure this out though 
Portals is the most correct answer. When we have portals support we have the opportunity to do LD_PRELOAD to make file dialogs from the major toolkits use the portals file chooser.
However in this particular case, we can do better. There are a few directories that are not allowed now:
- /home
- /
- /media
Giving read access to each of the above is a minor information leak. For /home and /media, it is leaking the users on the system. However, the default profile alread allows access to /etc/passwd and getent, so the information is already available to the snap. ‘/’ is a minor information leak at best. Often times denials on ‘/’ indicate applications are doing the wrong thing and starting at ‘/’ and descending down into /usr/lib/…/foo/bar. In this case, it would make sense to go from /home/foo -> /home -> / -> /media -> /media/foo -> /media/foo/content (though I would argue for a smarter file chooser here since that UX is terrible-- you have to know things are in /media/foo/content to begin with), so I think allowing ‘/’ in the removable-media interface makes sense. I’ll make these adjustments.
UPDATE: I would also add /media to removable-media and /home and ‘/’ to the default
It is hard for a confined file chooser to do much better than letting the user manually navigate from their home directory to /media. To show a list of mounted volumes, you’re probably going to need one of the following:
- read access to
/etc/fstaband/or/proc/self/mounts - ability to talk to
udisks2on the system bus - ability to talk to gvfs on the session bus
All three represent potential information leaks. So providing the ability to list the directories in between these two areas of the file system is probably the simplest intermediate solution.
As for the longer term solution using portals, there’s no need for LD_PRELOAD hacks. GTK has built in support for portals, and there is a Qt platform plugin that does the same for Qt/KDE apps. I suspect we might be able to handle most of this through the desktop-* snapcraft parts.
1 Like
https://github.com/snapcore/snapd/pull/4097 has a fix for /home, / and /media. I’ve requested it for 2.29.
That’s good news, when is 2.29 scheduled to land?
I can say that the 2.29 core snap is available in the beta channel.
2 Likes
I have pretty same issue, but I have no success with direct path access (since dialog have no such ability). Anyway, I have all my root directories available.
My hdd mounted as
/data and have proper rights (my user is owner), but this directory is not listed and I can’t access it in deadbeef player and gimp. I tried symlink some hdd directory to my home, to snap home, but it is still not listed. Any help?
Here is my ll output:
$ ll /
total 112
drwxr-xr-x 25 root root 4096 мая 3 15:24 ./
drwxr-xr-x 25 root root 4096 мая 3 15:24 ../
drwxr-xr-x 2 root root 4096 апр 27 21:55 bin/
drwxr-xr-x 4 root root 4096 апр 27 18:48 boot/
drwxrwxr-x 2 root root 4096 апр 27 18:00 cdrom/
drwxr-xr-x 11 broomrider broomrider 4096 апр 27 16:52 data/
drwxr-xr-x 20 root root 4380 мая 3 15:31 dev/
drwxr-xr-x 138 root root 12288 мая 3 15:07 etc/
drwxr-xr-x 3 root root 4096 апр 27 18:00 home/
lrwxrwxrwx 1 root root 33 апр 27 18:00 initrd.img -> boot/initrd.img-4.15.0-20-generic
lrwxrwxrwx 1 root root 33 апр 27 17:58 initrd.img.old -> boot/initrd.img-4.15.0-20-generic
drwxr-xr-x 22 root root 4096 апр 27 20:57 lib/
drwxr-xr-x 2 root root 4096 апр 26 21:17 lib64/
drwx------ 2 root root 16384 апр 27 17:57 lost+found/
drwxr-xr-x 2 root root 4096 апр 26 21:24 media/
drwxr-xr-x 2 root root 4096 апр 26 21:17 mnt/
drwxr-xr-x 3 root root 4096 апр 27 19:47 opt/
dr-xr-xr-x 245 root root 0 апр 28 18:38 proc/
drwx------ 5 root root 4096 апр 27 20:47 root/
drwxr-xr-x 32 root root 1060 мая 3 15:13 run/
drwxr-xr-x 2 root root 12288 апр 27 21:55 sbin/
drwxr-xr-x 7 root root 4096 мая 3 14:41 snap/
drwxr-xr-x 2 root root 4096 апр 26 21:17 srv/
dr-xr-xr-x 13 root root 0 мая 3 14:44 sys/
drwxrwxrwt 19 root root 4096 мая 3 15:57 tmp/
drwxr-xr-x 10 root root 4096 апр 26 21:17 usr/
drwxr-xr-x 14 root root 4096 апр 26 21:31 var/
lrwxrwxrwx 1 root root 30 апр 27 18:00 vmlinuz -> boot/vmlinuz-4.15.0-20-generic
To be able to access removable media you need to let it mount under /media. If it’s elsewhere then the confinement rules won’t match and so you’ll be prevented from accessing it.
That sounds sad, because even if I move my mounted hdd to /media, what will be with /tmp, since many apps use this directory. I have problem with gimp snap: after I made screenshot I select “open in gimp” and gimp says, that “no such file”, because it is somewhere in /tmp
/tmp is a special case. snapd will create a unique non-shared temporary folder and mount it to what the application will see as /tmp. This means each snap gets it’s own isolated version of /tmp.
I mean share files between apps via /tmp. Anyway, thanks for clarification
Note that by design snaps are not allowed to interfere with each other in any way by default, which includes sharing files in shared directories. Snaps can highly coordinate via the content interface or loosely coordinate using something like the home interface, eg, a browser might download to ~/Downloads which something like the gimp could open.