<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 17, 2015 at 1:11 PM, Zygmunt Krynicki <span dir="ltr"><<a href="mailto:zygmunt.krynicki@canonical.com" target="_blank">zygmunt.krynicki@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I believe that we'll start with utterly basic types (a file is one<br>
example) and thoroughly document them. From the developers point of<br>
view, the "file" type will carry the "path" attribute. That's all<br>
there is to it.<br>
</blockquote><div><br></div><div>"file" is probably not a great example of a capability type we want to have. Capabilities should be slightly more clear about what their intended use and consequences are. For example, we've been talking about a "serial-port" rather than a "file" with "path=/dev/ttyS0".</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A more sophisticated type can carry many attributes that allow<br>
consumers to actually access the resource it represents but I think<br>
those will need time to flesh out.<br></blockquote><div><br></div><div>Indeed it will take time for them to be polished, but that's what we're working on. There's very little value in replacing apparmor-based policies by something that states permissions at the same level.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Answer to all of those is "later". I think gadget and OS snaps will<br>
cooperate in agreeing what capabilities to create but ultimately now I<br>
just have ideas, not proven design. We'll get there.</blockquote><div><br></div><div>The point of starting the work on capabilities by creating an API that allows us to fiddle with them dynamically is precisely because we want to get the model right for capabilities to come and go arbitrarily with the system reacting properly to those events. As an obvious example, every non-embedded computer these days has a USB port, and those can be plugged in and out at will. That has to be translated into capabilities coming and going too, and nothing should break when that happens.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
</span>There are several reasons for doing it this way:<br>
<br>
1. We already use hooks to communicate with snaps (for the<br>
configuration changes, for example). This is really no different. We<br>
might even use configuration hooks directly (that's one of the ideas I<br>
was holding on to).<br></blockquote><div><br></div><div>That alone would be cargo-culting, so not a great motivator.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. The second reason is that REST API is currently not something you<br>
can directly access. For most intents and purposes it's not "public".<br></blockquote><div><br></div><div>If that's the problem, let's just make it public.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. Lastly I strongly believe that the right IPC system for conveying<br>
most of the snappy <-> application conversation should by DBus but I<br>
don't want to introduce that added complexity yet. We'll explore that<br></blockquote><div><br></div><div>And that's a reason against using hooks, rather than in favor of them.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
area when we need to allow snaps to create capabilities dynamically in<br>
a way we want to support in a long-term.</blockquote><div><br></div><div>We're working on making them dynamic today. That's why we have an API which allows fiddling with them even before they are working at all. If there are problems in the implementation being put in place that restricts that, we need to talk about it.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> The hook can stay there (it<br>
is an optional hook after all) forever when we cross that bridge. I<br>
bet some apps will still prefer the hook simply because of how easy it<br>
is to use compare to any alternatives.<br></blockquote><div><br></div><div>Yes, that's why "hooks", which is a fancy name for an executable in an expected place, is an interesting idea. The model is simple, lightweight, and gives a chance for the snap to react to system events in a very comfortable way, without pretty much any relevant knowledge from the author or restrictions in terms of how they decide to implement that.</div><div><br></div><div>But, that's still just an idea, open to criticism at this point. I'm certainly interested in hearing why that'd be a problem, or why something else would be better for some use cases.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think that when assign hook fails nothing should happen. Snappy will<br>
not really grant you extra permissions. The capability is not assigned<br>
to your application. Sure the configuration file may be broken but<br>
that's true of all the hooks today, right?<br></blockquote><div><br></div><div>How would an application react to an assignment event when it doesn't have the permissions to access the resources assigned?</div><div><br></div><div><br></div></div><div>gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a></div>
</div></div>