<div dir="ltr"><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 1, 2017 at 4:37 PM, Howard Cochran <span dir="ltr"><<a href="mailto:howard@badger-technologies.com" target="_blank">howard@badger-technologies.<wbr>com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Wed, Feb 1, 2017 at 12:22 PM, Gustavo Niemeyer<br>
<<a href="mailto:gustavo.niemeyer@canonical.com" target="_blank">gustavo.niemeyer@canonical.co<wbr>m</a>> wrote:<br>
> We'll probably not support completely arbitrary passthrough options as it<br>
> removes our ability to properly map the functionality into the confined<br>
> world.<br>
><br>
> One instructive example is the commands that are already supported. They<br>
> can't be just blindly executed as it might allow the snap to leave their<br>
> confined space.<br>
<br>
</span>This makes sense for certain use cases (such as cloud services built<br>
on snappy core). But another market that Canonical appears to be<br>
targeting for snappy core is embedded systems. In this context, the<br>
device developer is generally more interested in snappy for its<br>
software deployment & updating features than for keeping one service<br>
within the embedded device completely confined from another service on<br>
the same device. Indeed, a great deal of control over service<br>
configuration may be required in order to build a complete embedded<br>
system.<br>
<span class="m_5456293516336924266HOEnZb"><font color="#888888"><br>
-- Howard<br>
</font></span><div class="m_5456293516336924266HOEnZb"><div class="m_5456293516336924266h5"><br>
--<br>
Snapcraft mailing list<br>
<a href="mailto:Snapcraft@lists.snapcraft.io" target="_blank">Snapcraft@lists.snapcraft.io</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/snapcraft" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailm<wbr>an/listinfo/snapcraft</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_5456293516336924266gmail_signature" data-smartmail="gmail_signature"><br>gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a></div>
</div></div>