<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 17, 2015 at 2:44 PM, Zygmunt Krynicki <span dir="ltr"><<a href="mailto:zygmunt.krynicki@canonical.com" target="_blank">zygmunt.krynicki@canonical.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> This isn't exactly true, though; all you need is something that knows<br>
> how to talk http over a unix socket. e.g.,<br>
<br>
</span>Well, that sudo is something of a security loophole.<br>
<br>
My point was that it's not _meant_ to be accessed by every snap on the<br>
system and we'll probably grant special capability to select<br>
applications to let them actually open that socket to begin with.<br></blockquote><div><br></div><div>The REST API is definitely headed to be usable by any snap in the system, and that was always the plan I was aware of. We don't do that today because we don't have to, and in those cases simplicity wins.</div><div><br></div><div>My point, though (and perhaps John's, if I understand what he's saying), is that if we _wanted_ to open it up to snaps, there are easy paths we can use to do so. We're not doing that with capability events because it feels like a poor experience. So it's a design issue, rather than an implementation one.</div><div><br></div><div>So, why would it be a good idea to use an HTTP-based API, in the first place? What is the experience we want people to _have_ (rather than _not_ have)?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are also security implications. I know go is miles ahead of C in<br>
buffer overflows so it's harder to exploit but I don't know if we've</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
really done any security review of the IPC layer, where the layer<br>
includes parsing parts of the HTTP request and dispatching it to a<br>
correct Command object. If we can crash the system by pushing a big<br>
request across, it's still a DOS attack that you can mount. Ironically<br>
today you can remove a nasty snap with "snappy remove" but when snapd<br>
is itself talking to snappy over a socket (a future I hope we are<br>
going to) then snapd can be kept offline / crashing by one program<br>
that just sends a nasty payload to it all the time.<br></blockquote><div><br></div><div>Can we please get back to designing capabilities?</div><div><br></div><div><br></div></div><div>gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a></div>
</div></div>