Snappy capability types and attributes

Ted Gould ted at
Tue Nov 17 14:45:37 UTC 2015

Thanks for the update Zygmunt, it fills in a lot of holes for me, and I
hope for others as well.
On Tue, 2015-11-17 at 14:55 +0100, Zygmunt Krynicki wrote:
> More and more bits are landing so I've started exploring a simple
> scenario. An application that need to access a device that is
> normally
> 1) not known at compile time 2) not accessible to confined snaps.
I think that I can infer from the rest of the text, but I want to
double check, you'd expect the type to be known at the package build
time, just not the configuration of that.
I'm concerned about the types because that will be the difficult part
from the developer experience perspective. How they get a list of types
and what the properties are so that we can generate reasonable errors
if they misuse them.
> Let's use some hypothetical command line extension to snappy to create
> and assign a capability
> $ snappy create-cap serial-debug "Debug serial port" serial-port path=/dev/ttyS0
> Here the create-capability is the new command. "serial-debug" is the
> *name*, "Debug serial port" is the *label* and "serial-port" is the
> type. What follows after is a set of key=value pairs that define
> attributes. Here we just say that the "path" attribute should have the
> value "/dev/ttyS0".

It seems like this would be done by the gadget snap on most devices,
no? So is there associated YAML that the gadget snap would have for
configuring the board layout? Do you expect it to be adjustable by
device owners or only those with a "developer mode" gadget snap?
> What happens here is partially obvious, partially open to discussion.
> At a fundamental level, snappy needs to remember this fact, adjust the
> security system and notify the application *somehow*. The way this can
> happen is open to discussion. Right now I'd like to try the most
> basic, easy-to-use method that can be safely extended over time. I'd
> like to add a new hook, "assign" (and unassign later, for parity).

I'm still against the hook. It seems to me that you're trying to use
exec() as a form of IPC when we already have a better one implemented,
REST. Marshalling variables through the environment is well understood,
but also very tired.
> The application (or a wrapper) would read the config file mentioned
> above to know which serial port to open. The unassign hook could
> simply remove the file based on the same information.

On place where hooks fail is if the config file needs to be
regenerated, please also provide a mechanism to "query my current
capabilities" so that I can check on them and rebuild the config file.
Also, it seems like your proposal doesn't take into account multiple
sockets on the application side. For instance, if my application was
"say yes or no over serial" I might want to hook up one serial port to
one socket and another to a different. Something like:
$ snappy assign-cap serial-debug-1 say-yes-or-no-over-serial-port yes
$ snappy assign-cap serial-debug-2 say-yes-or-no-over-serial-port no
-socketShouldn't be hard to add, but just to ensure it gets into the structures and definitions early.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the snappy-devel mailing list