Snappy capability types and attributes

[Gustavo Niemeyer]

On Tue, Nov 17, 2015 at 1:11 PM, Zygmunt Krynicki <
zygmunt.krynicki at canonical.com> wrote:

> I believe that we'll start with utterly basic types (a file is one
> example) and thoroughly document them. From the developers point of
> view, the "file" type will carry the "path" attribute. That's all
> there is to it.
>

"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".

A more sophisticated type can carry many attributes that allow
> consumers to actually access the resource it represents but I think
> those will need time to flesh out.
>

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.


> Answer to all of those is "later". I think gadget and OS snaps will
> cooperate in agreeing what capabilities to create but ultimately now I
> just have ideas, not proven design. We'll get there.


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.


> There are several reasons for doing it this way:
>
> 1. We already use hooks to communicate with snaps (for the
> configuration changes, for example). This is really no different. We
> might even use configuration hooks directly (that's one of the ideas I
> was holding on to).
>

That alone would be cargo-culting, so not a great motivator.


> 2. The second reason is that REST API is currently not something you
> can directly access. For most intents and purposes it's not "public".
>

If that's the problem, let's just make it public.

3. Lastly I strongly believe that the right IPC system for conveying
> most of the snappy <-> application conversation should by DBus but I
> don't want to introduce that added complexity yet. We'll explore that
>

And that's a reason against using hooks, rather than in favor of them.

area when we need to allow snaps to create capabilities dynamically in
> a way we want to support in a long-term.


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.


> The hook can stay there (it
> is an optional hook after all) forever when we cross that bridge. I
> bet some apps will still prefer the hook simply because of how easy it
> is to use compare to any alternatives.
>

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.

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.

I think that when assign hook fails nothing should happen. Snappy will
> not really grant you extra permissions. The capability is not assigned
> to your application. Sure the configuration file may be broken but
> that's true of all the hooks today, right?
>

How would an application react to an assignment event when it doesn't have
the permissions to access the resources assigned?


gustavo @ http://niemeyer.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20151117/d32dc7ef/attachment-0001.html>