Class confinement for Python snaps

[Barry Warsaw]

On Mar 10, 2017, at 04:02 PM, Sergio Schvezov wrote:

>Any reaosn you are moving from devmode to classic? The progression should be
>classic->devmode->strict

A couple of reasons.  Probably the most problematic one is that /tmp inside
the snap is not the same as /tmp outside the snap, and we have a bunch of
crufty workarounds to fail early (when possible) if those directories are used
to communicate information across the boundaries.

ubuntu-image builds core images.  People like to put their extra snaps, or
their models in /tmp, or write the resulting images to /tmp.  All of that
works with the u-i deb but doesn't work with the u-i snap.   I *think* we've
identified most of the places where this happens, so we can issue an error and
exit, but it's an unfortunate asymmetry between the snap and the deb.  (And
I'm not 100% sure we've identified all the cases; and it makes the code more
complicated, etc.)

>It is however unfortunate that classic confined snaps can make it to the
>stable channel while devmode ones cannot

That's another limitation I was hoping to eliminate with the switch to
classic.  Currently we use edge as our "beta" release channel, then we do any
manual QA against that, and promote to beta for our blessed release.  I'd
love to be able to push the blessed version to stable, since it's way more
discoverable.

>, maybe we need an alias for devmode (which would be as secure as classic
>confinment but with the common root as root) as in some cases it is an
>improvement over classic (not needing to deal with libraries and installable
>on Ubuntu Core).

Isn't classic supposed to be a more or less replacement for traditional debs?
I probably misunderstand its purpose but our thinking was that we could bundle
it up as a classic snap as a possible, eventual, replacement for SRUing the
debs back to X and Y (and soon, Z also).  I didn't realize that classic is
viewed as the first stepping stone to strict confinement.

Cheers,
-Barry