I’ve got a browser snap and a chat app installed. While chatting to a friend in the chat app, I wanted to share a photo I have of them, to make a funny point. Something I might do casually, quickly and easily.
I just used the snapped browser to visit my online cloud photo provider to download a copy of the photo to my PC so I might share it to the chat app. I clicked the ‘Download photo’ button as anyone might. The photo is in
/home/alan/snap/<browser>/current/Downloads/ as a png.
I opened the chat app, and clicked the icon to attach a photo to my hilarious commentary, and attempted to navigate to
/home/alan/snap on my way to
/home/alan/snap/<browser> and beyond.
I get this.
Where do I go from here?
This is a specific case, but I can imagine a number of instances where I might share files from one application to another. However the moment is lost, and I actually don’t know how to get this file from application A to application B without some hoops being jumped here. How do we overcome this usability problem?
This is a known issue. ~/snap (and /snap and /var/snap) is not readable by snaps so they cannot enumerate snaps on the system. While currently we don’t plug all information leaks, this property is something we would like to preserve in the general case.
That said, you’re right, it is a usability issue. Snaps today that plugs ‘home’ (which it sounds like your chat snap does) typically will
cd $(getent passwd "$USER" | cut -d ':' -f 6) so that the file dialog isn’t way down in the snap’s $HOME. To me, it is a usability issue in the snap to have to navigate from ~/snap/foo/revision/ up and out, regardless of if ~/snap is readable…
One thing we might consider is that
home is already a transitional interface, and while we don’t want to add more info leaks to the general system, perhaps if plugging ‘home’ we could allow reading ~/snap. @niemeyer and @mvo, thoughts?
Yes, that sounds sensible, considering that the home for these snaps is actually under ~/snap. We should probably preserve the rule that home does not allow reading hidden (dot something) files under the snap’s directory, though.
That’s quite messy and continues the flawed narrative that private information is always stored in hidden files and all hidden files are private.
Would it be better for a snap to explicitly offer a file or directory for access to other snaps? The “home” plugin could permit consumption of those files and only those files.
imho a snap should be able to (only) launch a trusty snap (eg. a file manager) with classic confinement that can be used to offer the files to the calling snap… or the snap should receive an external file only with drag and drop.
I believe that for graphical apps this will be achieved through XDG portals where much of the magic happens under the hood, with the help of standardised “open file” APIs. For applications outside of GTK/Qt toolkits this will not work unless each app is patched to understand the new concepts.
Yes, it’s not ideal… it’s simple and unsafe, which is the situation we are in for a very long time. With snaps we have several nice ways to ensure that over time we transition towards cleaner and safer interfaces, but we cannot ignore the fact we have a volume of legacy applications and we still want them to work. That’s why we have the home interface, which by the way you can easily disconnect if you’d like to take that access away from any particular snap.
Yes. I certainly didn’t mean to imply anything else.
Added this to the list for the next batch of policy updates.
This is committed to master. We’re working to also get it into 2.31.