Integrate snapd-xdg-open into snapd repository

snapd
11

@niemeyer That sounds like a good idea. What about taking a two step approach here:

  1. We integrated snapd-xdg-open as it exists today into the snapd package and ship it as part of the snapd package and removing any further separate packaging with that from the distributions.
  2. We rework how we handle the real problem with the approach you suggested by sending the actual call through snapctl. Another aspect of this we need to think through is how snapd dispatches a snapctl open-link call back into the user session where it is running in a system wide context.

What we need to keep in mind is that we need to migrate existing users away from snapd-xdg-open and its dbus bus name. com.canonical.SafeLauncher. We have a separate xdg-open script for that in the core snap but we don’t know if everyone is using it and not accessing the bus name directly which is allowed by the unity7 interface.

12

It’s not clear why we’d spend time and energy integrating snapd-xdg-open into snapd, asking everybody to change the way its shipped, to then fix the same problem again in a better way and ask everybody to remove it.

Instead, we can invest our time on the final solution, and never have to worry about it again.

13

It’s two folded. Either we change existing users (Ubuntu, Debian) to drop the package for it or we take the additional packaging work for others users (openSUSE, Fedora, Arch) now to package it properly until we have a replacement in place. If we can stop possible users to never package it at all by integrating it now into the snapd then we don’t need them to worry about a possible migration to a newly implemented solution in the end, whenever it is ready. So regardless what we do, we spend time on packaging snapd-xdg-open in one or another way.

14

It’s not two-fold at all. It’s really win-win:

If you fix snapd to not require the package, you don’t even have to touch the package in Ubuntu and Debian. We’ll obviously want to remove it in the next distribution, but the fact it’s sitting on the system won’t hurt anyone. Every other distribution don’t have to worry at all. They’ll get it working out of the box with snapd.

If on the other hand you integrate snapd-xdg-open into the snapd repository, you’ll need to fix the package in Ubuntu and Debian to refer to the new location, and will need do the work to package the software to every single distribution, so that you can then to the above either way!

15

We don’t have to change the existing package in debian to look at a different location for the source. We more or less add a transitional package as we already do for other things (e.g. ubuntu-core-launcher) and it will get replaced on existing installations with the new transitional one. I don’t see this as much work and its already done in the PR linked above.

However, lets take snapd-xdg-open from where it is today and add necessary packages to the different distributions to have a fix for them real soon so we don’t loose existing functionality we have on Ubuntu there and have them as first class citizen. Afterwards we can work torwards a better solution if time and priority permits. I am adding this on my list.

This removes the need for snapd-xdg-open altogether, and the need to increase the burden on package maintainers.

This is not entirely true. As said above we still need to translate the call snapctl issues to snapd back into the user session context which snapd-xdg-open handled before as it was started as part of the user session.

snapd is part of the system context and does not have direct access into the user session to cause there a web link to be opened for example. So in the end we need again something living in the user session which translates the call back from snapd so it ends up in the right session context.

16

My biggest concern about this idea of “merging everything into the snapd repo” is that it’s just going to mask the lack of activity to all of these things. Moving snapd-xdg-open into the snapd repo will not make it better maintained.

The SELinux module was merged into snapd in the hopes that when Snappy developers actually change things, they’d fix the policy at the same time (like they do for AppArmor profiles). That obviously does not happen. Some of this is because it’s not packaged or used anywhere yet, but it’s not particularly hard to add a line for a new executable or delete one when it goes away. Will this get better now that Fedora has snapd builds that work? I don’t know, but I’m not holding my breath. I personally suspect that I will wind up doing everything alone until someone adds SELinux module packaging to the Debian and Ubuntu packages, because then someone else will have to care. With that kind of weight, why should have I bothered to merge it into the snapd repo?

I strongly suspect it’ll be exactly the same for snapd-xdg-open. For the most part, it is for snap-confine. It is almost exclusively worked on by @zyga-snapd alone. There were virtually no maintainability benefits to merging everything into snapd. If anything, it’s now harder to fix things in mainline because now we have to wait for someone to care to review the PR and merge it.

At first, I was for merging snap-confine into snapd, but as I watched the development and interacted with you guys, I became increasingly against it, because the whole process has too much friction and snapd alone is too complex to review. By the time the proposal to merge it came in, I was against it because it became clear to me that it’s not actually going to provide any material benefits. So far, from my point of view, I believe we haven’t gained anything from merging snap-confine into snapd, and if anything, it’s now more difficult to be agile. @zyga-snapd and I made more progress on snap-confine in Fedora when it was separate than when it was merged into snapd.

But frankly, I’m starting to not care one way or the other anymore, since apparently we want to have a monorepo. At least from the Fedora perspective, I’m likely to just maintain each component as subpackages unless there’s a good reason not to. That gives me the flexibility to easily deal with it being broken back out when it becomes unsustainable as a monorepo.

At least specifically in regards to snapd-xdg-open, the namespaces of the services should be changed as part of the merge from com.canonical.* to io.snapcraft.*. It should have happened when it was first put up on GitHub. I did file an issue about it several months ago, and brought it up in person even earlier. The fact nothing happened despite me bringing up twice in a short span of time is damning.

17

It will once we have CI enabled for Fedora. Then if you change things that break something in SELinux you don’t get to land it. SELinux is complicated and not everyone in the team runs Fedora (I suspect only two/three developers actively use it). Merging it was a step in the right direction because at least now we are one step closer to enabling CI. Working and understandable CI across several packages is harder to build and use. Inside one package / repository it is really easier.

18

Believe me that if you wanted to hack on snap-confine and ensure that it really works it is far easier because we didn’t have to maintain two sets of tests. Really, go and try it. Make a change and run all of snapd test suite. It’s a very reasonable assurance things work. We were burned by the two repositories in the past and the only reason it was a separate repository is because snap-confine was derived from ubuntu-core-launcher or something like that.

19

Folks, let’s please stop discussing and arguing about snapd-xdg-open. This is dead and should not be added to other distributions @morphis.

Let’s fix the real problem, now.

20

To add my two cents (which is not worth a lot), I would love to see this fixed regardless of the way in which that is done. My only concern is that as the developer I certainly don’t want to implement something special in order to handle snaps. If I am using xdg-open in my electron app, I would want to ensure I don’t have to rewrite how that works to specifically accommodate Snaps. I’m not sure that would be a problem, just telling you my only concern regarding how this is implemented.

21

The xdg-open binary will stay as is and will still allow you to do what it currently does. What we want to change is below xdg-open. So in a best case no application ever notice that we changed the backend implementation of this :slight_smile:

1 Like
22

To follow up on this, I am working on two electron apps and have been going around Github looking at others that can be snapped up and submitted tothe store. (I also have been helping some bigger companies get on the band wagon).

I think this should be moved to a top priority to ensure that those looking to move these critical apps find that all their features are well supported upon landing.

1 Like
23

Just to make things clear: snapd-xdg-open exists on Ubuntu 16.04 and 14.04 already today and gives you the functionality we’re talking about here out of the box. @niemeyer asked me to not take snapd-xdg-open further to other distributions (Fedora, openSUSE, …) until we reworked the basic design. Nevertheless, as we don’t have snapd officially on these distributions yet this can be considered a bug for them we will fix in the near future. For your electron apps it should be possible out-of-the-box today to ask via xdg-open (which is a standard Linux desktop thing and nothing we invented) to open webpages in the system default webbrowser. If that doesn’t work we have a bug.

1 Like
24

the bug is that we can not easily add a hard dependency to snapd for it (people running apt-get upgrade instead of dist-upgrade get dependency errors, we get bugs …) which means that derivatives/flavours that do not seed it explicitly do not get snapd-xdg-open currently.
the plan was initially to simply include snapd-xdg-open in the snapd package to overcome this issue.

25

@niemeyer I am thinking about this now for some time. Let me summarize where we are and what my thoughts on this are so far:

As of today xdg-open calls dbus-send today which sends a call to snapd-xdg-open which runs in the context of the session of the user executing xdg-open. If root calls xdg-open the dbus-send call will go nowhere as root doesn’t have a dbus session bus. snapd-xdg-open calls g_app_info_launch_default_for_uri which only makes sense in the context of a user session. It uses the MIME database to find the right application to execute for a given URI.

Your proposal is now to add a subcommand to snapctl which will handle a given link. This fine so far. However, if snapctl is called from the context of a user session we loose all user session information once the REST API call arrives at snapd. We then have no further way to translate the call back to the calling user-session. As the call to g_app_info_launch_default_for_uri needs to be initiated from within a user session and in the unconfined area we can’t do this from within snapd.

To solve this problem we need something running inside the user session which we can pass the link a snap gives to snapctl open-link to. Until now this was snapd-xdg-open. If we don’t want this to be named snapd-xdg-open anymore we could invent something like snapd --user which runs inside a user session (started by upstart on 16.04 or systemd --user on other distributions). snapd --user would then keep a connection to snapd to receive further instructions like an open-link command from snapctl which it then would pass this over to either the real xdg-open binary on the host or g_app_info_launch_default_for_uri. With this we still need something we can use inside snapd to identify a snapd --user instance from a snapctl call.

26

Actually we don’t need to have snapctl talking with the systemd snapd it could also talk with the session snapd --user instance directly over dbus or a socket.

27

@morphis I haven’t searched yet, but I’d be extremely surprised if a process with complete access to the whole system has no way to open a link in a browser.

28

The problem here is not the level of access to the system, it is how it is mapped into the right user session. I am not sure if a crappy su - $USER will suffice this use case.

29

Still, the point is that you have the whole machine at hand. There ought to be a very simple way to make this work.

30

As explained above, what all system services like NetworkManager/connman (e.g. requesting passwords, opening a website for captive portals), BlueZ (e.g. PIN/passcode, authorization or per user media playback control) are doing is: They delegate the actual “OpenBrowser” action to an agent running as part of the user session. This agent then has the responsibility to process the received action as needed and open a web browser for example. In Ubuntu or gnome this for example is done by nm-applet for NetworkManager or the bluetooth applet for BlueZ.

I don’t see yet how snapd can do this differently.