Snappy capability types and attributes

[Zygmunt Krynicki]

On Tue, Nov 17, 2015 at 3:45 PM, Ted Gould <ted at ubuntu.com> wrote:
>
> 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.

Yes, types will be a part of a long-lasting, supported API "contract"
between all three users. I suspect that we'll spend a lot of time
designing types themselves to model what actual computers contain in a
useful and meaningful way.

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

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

> 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?

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.

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

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).
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".
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
area when we need to allow snaps to create capabilities dynamically in
a way we want to support in a long-term. 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.

The REST API I proposed is a part of the implementation. It will be
needed to implement the mechanics of some of this but it is not
something we've agreed to let application use yet.

Perhaps I'm missing something. Is there an example where an untrusted
application uses the REST API directly?

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

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?

I agree about the need of the "what are my caps" API but I'm not sure
how that would work yet.

> 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-socket
> $ snappy assign-cap serial-debug-2 say-yes-or-no-over-serial-port no-socket

It does, though I didn't explore that fully yet. The
$SNAP_CAP_SLOT_NAME was exactly that. My example was deliberately
simple so that I could ignore that aspect for now.

> Shouldn't be hard to add, but just to ensure it gets into the structures and
> definitions early.

Ack.

Thank you for the feedback. I hope my answers clear up some of the
aspects. I know that much of this still only lives in my mind and a
large aspect won't be implemented anytime soon but I think it is
important to keep the discussion open and rolling along.

:-)

Best regards
ZK