So we have a bug where a snap using classic confinement (conjure-up) is causing serious issues on the installed system. The details are here:
In that thread sabdfl suggested that we start confining the configure hook. I think we should think this through, both as an user experience and for how this is going to work technically. The way we build snaps with classic confinement now makes them incompatible with running under confinement. We have a special case for snap install --classic --jailmode but it’s not a general solution, it just makes a simple hello-world work.
The reported problem is not about hooks, but rather about a fundamental property of classic snaps: they are confined in a classic way! In other words, the application has complete access into the host system, which means every time you install a snap with the --classic flag, you need to fully trust the snap author to not screw up your system, exactly like you’d need to trust an author that made a classic .deb or .rpm package available.
Confining hooks will not fix the problem, since the snap as a whole is still able to do whatever it wants. Before we had configure hooks, people were simply running logic in their daemon commands, which is started on installation too.
In fact, changing the confinement rule of configure scripts will create a whole new class of problems, because the hook and the real system will be able to do different things.
The real solution to this problem is to use strict snaps. We know there’s some pain involved in getting pre-built binaries running fine under a strict snap, and I’ve been experimenting with a few ideas that should make most of the appeal of classic snaps go away. I’m hoping we can start working on this soon (and I need your help on that @zyga-snapd).
I would like to close that bug as “Invalid”. This is a bug in the snap.
1 Like
