Synchrorep need classic confinement

Synchrorep need classic confinement in order to install a nautilus extension.

The requirements are understood in that classic is needed to install a nautilus extension, but it is possible for snapd to be extended to install nautilus extensions and for them to run under confinement.

@sebk69 - what is the standard packaging for a nautilus extension?

@pedronis - this seems like a candidate for classic, though it is a new use case. Can you comment?

Nautilus extensions typically reside in /usr/share/ in a directory name something like nautilus-foo or foo-nautilus. Similarly that can also be installed in ~/.local/share/

@pedronis can you please take a look at @jdstrand’s question above?

@jdstrand @alexmurray in general I wonder if snaps are a good choice to package extensions to non-confined software if it means they need to be classic to work at all in that role

@pedronis - this is a good question - we also have a similar request over in Yaru dartk theme toggle review request - in both cases we have software that wishes to make itself available (as a plugin/extension etc) to existing software installed on the host system - so classic is the only possible solution we have to this problem - and I agree that this does not really fit with the snap model. In particular the way these applications on the host system support plugins as files within a well-known location makes this hard to support with snaps.

The most similar thing that I am aware of which we have tried to support like this is GNOME Shell Search Providers - but in this case we are exposing a D-Bus interface and allowing snaps to use that interface to register themselves as providers - so for the case of these plugin type applications we would either need to provide something similar (ie a well known D-Bus or other API which snaps could plug and then use to register themselves - and this might in the background create the appropriate plugin file on disk etc for the host application). However I can see this having it’s own issues around API stability etc between the host application and the plugins which we then create via this proxy interface.

So in summary I tend to agree we can’t really support this use-case well with snaps as it currently stands, however even given this I am not sure that classic confinement is an appropriate solution due to the large amount of unexpected authority which this grants.

I generally agree with @alexmurray’s assessment since, today, a snap must be classic so that it can drop its files into the ‘plugin location’ on the host (since that location is typically in /usr and outside of the snap’s runtime environment). snapd could be adjusted to supported this, like we do with desktop files: the snap declares something and snapd puts that something in the right place on behalf of the snap. While this methodology allows the snap runtime hurdle to be overcome, now we must consider the security of what was just done as well as how it affects the stability of the system.

In the particular case of a gnome-shell extension (note, syncrorep is a nautilus extension, not a gnome-shell extension), the extension is now running with full user session privileges in process with the shell and therefore unconfined. Considering this, the snap may as well be unconfined because the end result cannot be confined until the GNOME desktop is extended to fork/exec a new process to launch the snap under confinement (considering the design and direction of the GNOME desktop, I don’t think this will be possible). Furthermore, there is no guarantee that the extension would be expected to work on all the GNOME desktops that snapd might be running on. GNOME extensions are known to be very much GNOME version dependent and a misbehaving extension can cause all sorts of problems on the user’s desktop (though GNOME has improved in this regard AIUI, the point still stands). Since by design snapd doesn’t allow for a snap to depend on a version of a host system component, it is this last point that I think makes shipping GNOME extensions generally unsuitable for shipping as a snap.

That said, the yaru dark theme toggle extension seems relatively simple and unlikely to break the system on its own, but I don’t know that to be the case. I also don’t know how desktop-version-dependent it is. All other points stand.

My understanding of nautilus extensions like synchrorep is they operate differently than GNOME in that nautilus runs them out of process. It may be possible for snapd to be extended to take the nautilus extension that is declared in the snap.yaml, create a shell wrapper on the fly that calls out to the snap’s nautilus extension code under confinement, then puts that wrapper into the right place (all without any modifications to nautilus itself). AIUI (please correct me) is that nautilus extensions are not typically distributed via package management, and that instead they are more normally installed per-user in $HOME. This might be because admins don’t want nautilus extensions installed system wide. If this is the case, we may not want to put the effort into supporting nautilus extensions since the larger community prefers users to install them in $HOME.

In the case of GNOME search providers that @alexmurray mentioned, my understanding was that the desktop team was going to adjust GNOME to run the search providers under snap confinement along with extending snapd to put the providers in the proper location. I’m unfamiliar with the GNOME search provider APIs, but at the very least, a crashing search provider shouldn’t affect the stability of the desktop.

For context, another example is man pages. We said that we would not extend snapd to install man pages until man was hardened against arbitrary input, which has happened and now man supports both seccomp and apparmor confinement (on Debian-derived distros). Untrusted man pages can be installed on the system with the understanding that the man command is running under confinement, the pages won’t affect the stability of the system and they aren’t expected to break cross-distro.