Snappy capabilities, in baby steps

[Zygmunt Krynicki]

On Fri, Nov 13, 2015 at 6:29 PM, Ted Gould <ted at ubuntu.com> wrote:
> On Fri, 2015-11-13 at 15:02 -0200, Gustavo Niemeyer wrote:
>
> On Fri, Nov 13, 2015 at 2:47 PM, Ted Gould <ted at ubuntu.com> wrote:
>
> So from Zygumnt's thread it sounds like there's going to be a tag cloud
> attached to each snap. I'm guessing that this is going to include kernel,
> gadget and framework snaps. They'll export which tags they support. Will the
> tags be centrally defined or are we hoping for some sort of emergent
> behavior here? How will we handle conflicting tags?
>
>
>
> The terminology in use is that there's a capability name which is a unique
> identifier in its context (e.g. the snap) and there's a capability type
> which defines its meaning. We want to make capability types extensible, but
> they must be centrally approved since there are security concerns associated
> with it.
>
>
> For the cases where versioning is important, how will that be handled. For
> instance being able to support OpenGL could mean standard GL of various
> versions or GLes of various versions. For games which versions the HW can
> support can be very important.
>
>
> The capability type defines what behavior is allowed and expected. There
> will be metadata associated with the capability, so in cases where the
> capabilities are very similar they may end up being defined as a single
> capability type with differing metadata. In other cases, they may be
> different types.
>
>
> So let me see if I understand using the OpenGL example. You'd expect my
> kernel snap to look something like this?
>
> name: teds-cool-kernel
> capabilities:
>   graphics:
>     type: opengl
>     versions: [gl2, gl3, gl4, gles2]
>
> And then the application that required the capability to look like this?
>
> name: teds-super-modern-game
> required-capabilities:
>   graphics:
>     type: opengl
>     versions: [gl4]
>
> Then how would the decision be made whether my game could install on my
> kernel? Where is it defined that there would be an any or all relationship
> with versions?

This example can be handled with several different implementations:

- Application works on an environment (phone) where it can expect
certain things (mir access, minimum level of GPU support) and no
capabilities exist in this picture.
- Application wants a mir capability and gets access to a mir socket
when that is assigned. Application is expected to handle all GL stuff.
- Application wants raw GPU access and bundles mir or anything else
internally. The capability grants permissions to several device nodes
and other magic.

Each of the three variants can be expanded to handle OpenGL "version"
though I would not really treat that as the "version" of a capability
I was thinking about.

> There was a mention of passing metadata, which way will the metadata
> transfer occur? Both? What is the lifecycle and policy for handing that

Capabilities will carry some extra bits of data needed, at the lowest
technical level, to make permission to work, and to communicate
essential facts to the application. If I grant "3rd serial port"
capability to some snap, I expect that the application will be able to
know (by meta-data exchange) that it is now capable and expected to
open /dev/ttyUSB2.

> passing of metadata? Does it require a particular format or is that to be
> decided by the framework and/or application involved in the exchange?

I strongly believe that the meta-data will be defined by each
capability type and will not be a free-for-all key-value store.
Frameworks are out of the picture for now. I'm focusing on simple
device access (typically that translates to permission to open
something and talk to it). More interesting use cases might be
assembled out of those as we progress.

I also think that capabilities for things like networking might be
totally different from what I am currently describing as it's not a
traditional file-based security model and sharing works differently.

> There will be a particular format and protocol for exchanging the data.
> We're not there yet, though.

Yep, we're not there yet.

Best regards
ZK