Ok, so (disregarding the DBus error), you are using xdg-open from the core snap, which is normally what you want because it will allow you to open an external application for the URL in question.
Unfortunately, the xdg-open in the core snap does not handle file:/// URLs. Normally, the non-snappy xdg-open when given a file URL will look at the mime type of the URL you give it and open it with the default application for that mime type. In your case, you give a directory so the file manager is opened.
This is an interesting use case that (at least I) had not considered. @niemeyer and @jamesh, as a thought experiment, let’s consider modifying snapd’s userd to handle file:/// URLs. AFAICT, the expectation of using xdg-open is that the snap would never be given this file again, so it is a one-way action (ie, the snap doesn’t gain access to the file in question, only launches something else on it). An implementation might have userd verify if the specified file is accessible to the snap already (ie, via libapparmor). My main concern is that a malicious snap could exploit bugs in unconfined default mime handlers. For example, there is an exploitable code execution bug in an image library that allows code execution. The malicious snap ships a crafted image then calls xdg-open $SNAP/bad.png, this is in the application’s readable area, so pass that along to the system xdg-open, which opens eog unconfined, which the snap can then control via the code execution bug and break out of confinement. This is precisely what snappy confinement is supposed to address-- any exploitable bugs are supposed to be limited to the snap itself. Part of the problem here is that the user isn’t given a choice to open the file. Limiting this to a directory addresses that but if given the choice, the user could be tricked into opening a crafted file easily enough.
We have some knobs though (that can be used in combination):
- userd could just pass file:/// URLs straight to xdg-open
- userd could check if the file:/// URL is accessible to the snap, if so, pass to xdg-open
- userd could only handle file URLs for directories
- userd could only handle file URLs for directories and could check if the file:/// URL is accessible to the snap, if so, pass to xdg-open
- userd file:/// URLs use a different DBus API that we only allow in transitional interfaces (eg, desktop-legacy and unity7)
- userd file:/// URLs use a different DBUS API that we allow in a separate manually connected interface (or via an interface attribute of desktop-legacy)
- userd would only open file handlers under confinement (eg, another strict mode snap)
I was trying to think through if portals could be of use, but I don’t think so-- the file chooser is about giving access to a file to the application so it can do with it what it wants, it isn’t about launching other applications on the requesting app’s behalf.
If we were going to support this, I’m sorta thinking this is perhaps a combination of ‘2’ and ‘5’. Since the user can be phished, ‘3’ and ‘4’ don’t buy us much. Limiting to what the snap can access (‘2’) seems to have merit. ‘2’ and ‘6’ is possible too: it allows us to mediate the file:/// access via snap declaration and user choice. ‘7’ is interesting to think about, but it allows for the calling snap to exploit bugs in the called snap to exfiltrate data; not to mention, I strongly suspect that people would want to call classic snaps.