Thanks for the tips. I’ll have an experiment.
So on this do we need to tell all users to install snapd-xdg-open prior to installing our snap? Or how do we handle this? It really seems like it should be automatically installed as a dependency of snapd.
In my snap I can use shell.openExternal in my electron app as well as xdg-open neither work until I install the snapd-xdg-open package.
They’re trying to find a solution which will allow opening links without needing to install snapd-xdg-open, until that solution is found, merged into snapd, and released, you’ll need to tell your users to install snapd-xdg-open. Unfortunately, your users can’t do this on any distribution other than Ubuntu; we’re going to have to wait for opening links to be possible on more distributions.
That’s what I understand from having read the thread, anyway.
Until a solution is found, Corebird (an app I’m asking upstream to provide a Snap for) won’t work at all on non-Ubuntu distributions (since you have to be able to open a link in the browser to log in).
Currently, yes. I’ve also had to prepend /usr/local/bin to my PATH for strictly confined Electron apps using shell.openExternal, like this:
command: env PATH=/usr/local/bin:${PATH} ${SNAP}/bin/desktop-launch $SNAP/opt/Example/example
I’m going to work with Electron Builder upstream to automatically take care of the PATH prepending.
1 Like
You’re quite correct. @zyga-snapd is their an effort to land snapd-xdg-open in other distros as a temporary solution?
There’s ongoing work to land it in Fedora. As for Debian / OpenSUSE I don’t know, @morphis may know more.
Exactly that is what this thread is about. I was discussing with @niemeyer higher up in the thread possibilities to get snapd-xdg-open or a replacement into other distributions. Current status is that @niemeyer want snapd-xdg-open being reworked so that it is build directly into snapd and not being landed into any other distribution. I am still waiting for reply from him after this comment.
@niemeyer explicitly requested me to NOT land snapd-xdg-open into Fedora but work on a replacement instead which we’re still discussing here.
I was curious how this could be done and I did some experiment in https://gist.github.com/mvo5/bd980109566c0c74af2c00255bb68712 so that root could figure out the active seat. Some aspects are a bit ugly (like that apparently there is no way to just ask systemd about all processes in a single cgroup and that the script needs to poke into /sys/fs/cgroup instead) but it should generally work. If we want to pursue this path we probably want to a different language than sh as the current outline in the gist is surely is not robust enough.
1 Like
I was thinking about a similar approach before but for me this looks really hacky and relies on a lot things which we may don’t have cross-distribution.
yes, it is definitely a lot less clean than simply shipping a dbus listener like we do now …
@mvo Thanks a lot for putting that in place! That’s pretty small for being impossible. 
@morphis By all means please feel free to improve on the basic idea provided there, and perhaps @robert.ancell and others more familiar than us on those details will have ideas. We’re all for making it cleaner and simpler. The point here is that this may be done once, inside snapd itself, and then have it working everywhere without requiring every single distribution to not only ship that additional daemon but ensure that it’s installed right next to snapd itself so that people can do something as simple as click on a link. That has been proven to not go well already, so I’m not excited to just bang harder on the same broken door.
seeing the proposal i still wonder what is wrong with the current implementation (which works along freedesktop standards already), apart from the fact that we did not package it into snapd in the first place.
to forward such calls into a session using dbus with a listener is a standard. we do not use any daemon but a forwarder service that is only invoked when an xdg-open request comes in on the bus and only then forwards the request to the actual xdg-open service binary. it uses the implemented and established policykit desktop standards for securing the whole operation and generally works well already except for the fact that the listener is not included in the right package today.
fishing for random environment via logind calls and circumventing default security mechanisnms instead does not seem to be a good replacement IMHO. cant we keep the dbus implementation (the listener .service file is minimal) and simply improve the service binary ?
1 Like
@ogra The rationale was presented above a few times already. Simply asking why again, without addressing the points made, means I’d have to just restate what was already said.
This is also not “circumventing security mechanisms”. If you have real security worries about what is being proposed, then please be specific about how this is a security threat in any sense.
polkit is a default mechanism for admins to deny/allow what their users can access on desktops. by completely working around the policy kit and dbus implementations that are freedesktop standards for such things, the mechanism will not work for snaps … i.e. an enterprise admin denying all xdg-open calls for certain urls or whatnot will surely be surprised that snaps will simply ignore such default mechanisms.
i think the fd.o specifications exist for a reason, and i think working around them with a hack will not really serve us well but will again cause complaints about canonical suffering from NIH.
IMHO we should make sure to integrate with existing technologies accepted by all desktops (even openbox obeys to dbus/polkit policies), which the current implementation does already.
At the end of the strawman by mvo provided above, it’s xdg-open itself that is called. If xdg-open doesn’t work for whatever reason, it will not work for snaps either. If it works, it will work for snaps too, and that sounds pretty good.
in the strawman xdg-open is called directly not using dbus and logind/policykit anymore
Yes, when xdg-open is called, what happens is exactly what happens when xdg-open is called. That’s the goal.
well, indeed xdg-open is what is called in the end in either implementation. the question is rather, do we want to be good citizens and integrate with established standards on the way towards this or do we want to hack around all these established mechanisms that all desktops agree on, pass session info around through the system where it does not belong, just to enforce our own very hackish way to achieve the very same.
the result will in either case be that “xdg-open $URL” is executed indeed (once by dbus proper on demand when the request comes in and once directly by passing info around that should most likely not be passed around to non-session services)
Just to answer to the specific part about polkit - our current snapd-xdg-open code does not use polkit, so the mechanism you describe (enterprise admin) would not work today. There could be code added for that of course but its not there today.