It is possible that a certain application is both useful in functioning in strict and classic confinement, for example:
Text editors are both useful in editing user’s own documents, as well as configuration files in system paths
File system utilities like junk file cleaner(BleachBit), which are useful in cleaning both user and system-wide files
Using strict confinement will make these applications lose unignorable amount of functionality while granting classic makes them unavailable to the Ubuntu Core (a.k.a. non-classic) systems.
I hereby propose a new confinement mode hybrid (could be any other names that makes more sense), that make a snap announce that it is both workable in strict and classic confinement mode. When a user installs a snap snapd runs it in strict mode by default, but the user can pass the --classic flag to the snap install/snap refresh commands to make the snap operate in classic confinement.
The classic confinement vetting process still apply, a snap can only be published in hybrid mode in the Snap Store after vetting
It is very challenging to technically make a snap that would be compatible with strict and classic confinement at the same time. I would argue that it is impossible at the extreme due to the fact that strictly confined snap cannot read /snap/core/* but classically confined snap must use /snap/core/* dynamic linker.
I second the desire to have better experience for text editors and IDEs but expanding the use of classic confinement is not the way forward.
personally, I refuse to make any snap “classic”. I believe that if it cannot be made strict then that’s a bug that needs fixing and not something that should be waved away with a magic wand named “classic”.
There is one legitimate use case for classic: wanting to observe the initial mount namespace. This, however, may soon disappear as well, as classic snaps will be wrapped in specialized mount namespaces as well, to support instances.
Unfortunately no. It will not be a complete mount namespace and it will not allow layouts.
I will explain the rationale and details about this when I begin the work for real. For now the short answer is that it is just a minimal mount namespace, bidirectionally shared with the initial mount namespace, for the sole purpose of supporting instances of snaps using classic confinement.