Proposal: `hybrid` confinement mode

snapd
1

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.

NOTE:

  • The classic confinement vetting process still apply, a snap can only be published in hybrid mode in the Snap Store after vetting
1 Like
2

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

1 Like
3

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
4

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

5

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
6

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
7

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
8

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

9

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.