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/
@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 dark 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.
1 Like
I looked into this today. Extending nautilus can be done in one of two ways:
- nautilus scripts (typically installed in ~/.local/share/nautilus/scripts). These are executed by nautilus.
- nautilus extensions (often installed in /usr/lib/@{multiarch}/nautilus/extensions-). These are .so files that run within the context of nautilus itself
Scripts could be handled via personal-files immediately, but they would execute outside of confinement unless the developer used ‘snap run’ within the script that was installed in the nautilus scripts directory. Instead, the script should be declared to snapd in some manner, then userd could write out a wrapper in the nautilus scripts directory that calls snap run (or an appropriate system wide directory via snapd). Nautilus scripts can therefore be relatively easily supported as strict mode snaps.
Since, nautilus extensions are .so files that run within the context of nautilus, they are similar to GNOME shell extensions in that the extension must work with a supported nautilus extension version and provide sandbox escape since they run outside of confinement (note, GNOME shell extensions are not supported and not candidates for classic). I suspect that the extension version is less of a problem since it only seems to be tied to the nautilus major version, but examining a running nautilus with an extension installed via deb (nautilus-gtkhash) shows that, indeed, nautilus loads the extension into its address space and doesn’t use any sort of a fork/exec’d helper, etc that we could leverage to run the extension under strict confinement. There is an open issue in gitlab for shipping nautilus extensions as flatpaks: https://gitlab.gnome.org/GNOME/nautilus/issues/476, but there is no movement. Snapd and flatpak would require similar mechanisms from nautilus for shipping as snaps or flatpks, so the first steps would be for interested parties to participate in that issue and create a solution that works for both flatpak and snapd.
@pedronis and I discussed this issue in Vancouver and came to the conclusion that so long as there was a path forward to strict confinement, nautilus extensions could be temporarily shipped as snaps with classic confinement. While there is a path forward for nautilus scripts, there is not for nautilus extensions and as such nautilus extensions are not candidates for classic at this time since nautilus itself needs to be rearchitected to support launching extensions under a different security context.
The revision of synchrorep in the store is doesn’t ship anything except the snap scaffolding (ie, the synchrorep binary is not shipped in the snap), but I did look at https://sourceforge.net/projects/synchrorep/ (1.5.5) and see that synchrorep is a nautilus extension, not a nautilus script and therefore not a candidate for classic.