daemon ordering
Gustavo Niemeyer
gustavo at niemeyer.net
Wed Feb 1 19:02:02 UTC 2017
Such embedded devices are still computers on the network. We'll all be much
better off if they are running their applications confined and secured.
That said, we understand that it takes some time and effort until most
software is properly confined, which is why we support snaps with classic
and devmode confinement.
Even there, though, we're keen to ensure that the general model supports a
comfortable migration towards proper confinement, as that's where we'll all
want to be in the end, so we shouldn't just go loose and implement features
that we know will break confinement unnecessarily.
On Wed, Feb 1, 2017 at 4:37 PM, Howard Cochran <howard at badger-technologies.
com> wrote:
> On Wed, Feb 1, 2017 at 12:22 PM, Gustavo Niemeyer
> <gustavo.niemeyer at canonical.com> wrote:
> > We'll probably not support completely arbitrary passthrough options as it
> > removes our ability to properly map the functionality into the confined
> > world.
> >
> > One instructive example is the commands that are already supported. They
> > can't be just blindly executed as it might allow the snap to leave their
> > confined space.
>
> This makes sense for certain use cases (such as cloud services built
> on snappy core). But another market that Canonical appears to be
> targeting for snappy core is embedded systems. In this context, the
> device developer is generally more interested in snappy for its
> software deployment & updating features than for keeping one service
> within the embedded device completely confined from another service on
> the same device. Indeed, a great deal of control over service
> configuration may be required in order to build a complete embedded
> system.
>
> -- Howard
>
> --
> Snapcraft mailing list
> Snapcraft at lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/snapcraft
>
--
gustavo @ http://niemeyer.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20170201/e0901737/attachment.html>
More information about the Snapcraft
mailing list