Proposal: `hybrid` confinement mode

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
1 Like

See my reply to your nano-strict request. Which has an additional possible option (using tracks).

1 Like

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.

1 Like

Isn’t that problem solvable via explicitly allow access to the paths that matters?

For the linker yes but the scope of complexity is only growing from there.

It’s challenging to produce a correctly made snap that uses classic confinement. Mixing that with strict and interfaces is only more complex.

1 Like

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”.

1 Like

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.

1 Like

this will be nice as having a mount namespace should allow layouts to work with classic, correct?

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.