Why is classic confinement a thing? Isn't it better to have a snap with all permissions granted?

Sorry to ask an abstract question, but still, here it is. As you know, classic confinement is very popular option currently. So, you cannot forbid anything to such a snap.

Why is classic confinement a thing? How much harder is to build a confined snap asking for all the possible permissions than it is to build a classic snap? In the first case we at least can revoke some of those permissions.

Outside the permissions system, a big difference with classic confinement is that classic snaps run in the host mount namespace; which means, they don’t see anything differently regarding your filesystem than the host does. This is what gives a large amount of advantages (e.g, ability to access any arbitrary location, run arbitrary files, etc); and also disadvantages, the ability for incompatible libraries to influence the program for instance. Some programs might work fine in a strict environment and struggle in a classic environment, because of the differences in relying on $LD_LIBRARY_PATH vs runpath, or lacking in niceities such as Snap layouts.

Strict snaps run in the mount namespace provided by their base snap, which means that even on Fedora for example, the snap would see itself as running in an Ubuntu environment that looks consistent across arbitrary distributions.

Even running a strict snap in devmode, where all the sandboxing is turned off; has no effect on the mount namespace and this is a huge difference from a packaging/development perspective.

Overall, if the objective is just “ignore the sandbox”, then classic confinement might look easier, but you open yourself up to completely new problems in exchange, mostly involving ABI and standard assumptions on file paths, that means that classic confinement isn’t as simple as being “easy-mode”.

3 Likes