<div dir="ltr">Hi Zygmunt,<div><br></div><div>I have a few comments, but let's please discuss this over a call with more bandwidth.</div><div> <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 17, 2015 at 11:55 AM, 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">Hey<br>
<br>
More and more bits are landing so I've started exploring a simple<br>
scenario. An application that need to access a device that is normally<br>
1) not known at compile time 2) not accessible to confined snaps.<br>
<br>
For the purpose of this idea, we'll try to write a simple program that<br>
opens a serial ports and keeps saying "yes". The program has one piece<br>
of configuration, the path of the serial port to open. For now I'll<br>
silently ignore this. I have a very neat idea on how to address this<br>
but let's take one step at a time.<br>
<br>
The application ships without any custom security policy. Nothing<br>
fancy is needed. For now the fact that this application can consume a<br>
capability will not be modeled on the application developer side.<br>
Again, baby steps.<br>
<br>
The user installs the application and tries to run it. For now it will<br>
just say that it is not configured since it does not know which serial<br>
port to open. Now the magic starts to happen.<br>
<br>
Let's use some hypothetical command line extension to snappy to create<br>
and assign a capability<br>
<br>
$ snappy create-cap serial-debug "Debug serial port" serial-port path=/dev/ttyS0<br>
<br>
Here the create-capability is the new command. "serial-debug" is the<br>
*name*, "Debug serial port" is the *label* and "serial-port" is the<br>
type. What follows after is a set of key=value pairs that define<br>
attributes. Here we just say that the "path" attribute should have the<br>
value "/dev/ttyS0".<br>
<br>
Let's take a small detour now. The idea of types is to combine the<br>
concepts across developers , system builders and end-users. A system<br>
builder will do the hard work to ensure that the "Debug serial port"<br>
capability is pre-created on a system they build. A developer will do<br>
the hard work to ensure that they can correctly use any capability of<br>
type "serial-port". A user will do the easy task of giving the "Debug<br>
serial port" capability to the snap they've just installed.<br>
<br>
Attributes allow capabilities to convey information across the three<br>
users. The developer will know how to access the serial port at<br>
runtime. The system builder needs to put correct information there.<br>
The user, in this example, won't have to care about this. There are<br>
interesting ideas that I have on how the users _can_ benefit from<br>
attributes but for now, let's not go there.<br>
<br>
So now we have our shiny new capability. Let's assign it to our<br>
"say-yes-over-serial-port" snap.<br>
<br>
$ snappy assign-cap serial-debug say-yes-over-serial-port<br>
<br>
What happens here is partially obvious, partially open to discussion.<br>
At a fundamental level, snappy needs to remember this fact, adjust the<br>
security system and notify the application *somehow*. The way this can<br>
happen is open to discussion. Right now I'd like to try the most<br>
basic, easy-to-use method that can be safely extended over time. I'd<br>
like to add a new hook, "assign" (and unassign later, for parity).<br>
<br>
This hook would be written by the application developer (something I<br>
expect snapcraft parts and language specific libraries to simplify to<br>
the point of being a one-liner) and would be in charge of remembering<br>
the fact in a way that is meaningful to the application. Here we could<br>
simply write a configuration file, use snappy config itself to set a<br>
configuration item or do something else appropriate (talk to a<br>
service, etc).<br>
<br>
The hook would be called with extra environment variables that carry<br>
data about the capability being assigned (or unassigned). In no<br>
particular order, I'd like to propose<br>
<br>
$SNAPPY_CAP_NAME<br>
$SNAPPY_CAP_SLOT_NAME (I'll explain this later, for now you can think<br>
of a place where the capability is being assigned within the snap)<br>
$SNAPPY_CAP_LABEL<br>
$SNAPPY_CAP_TYPE<br>
$SNAPPY_CAP_ATTR_${attr_name}<br>
<br>
The last of those would be defined for each of the attributes, which<br>
are defined by types. Types would be documented (perhaps on the<br>
developer portal) so that all the people involved would understand<br>
what to expect out of each attribute. Types would also be versioned<br>
but I'd like not to discuss this yet.<br>
<br>
Back to our simple application. The "assign" hook could be written in<br>
shell and simply do something like this:<br>
<br>
#!/bin/sh<br>
case $SNAPPY_CAP_TYPE in<br>
    serial-port)<br>
        echo "$SNAPPY_CAP_ATTR_path" > "$SNAP_APP_DATA_PATH/file-to-open"<br>
        ;;<br>
    *)<br>
        exit 1<br>
esac<br>
<br>
The application (or a wrapper) would read the config file mentioned<br>
above to know which serial port to open. The unassign hook could<br>
simply remove the file based on the same information.<br>
<br>
I'm open to feedback to this idea and without any information to the<br>
contrary, I will be slowly going towards that direction.<br>
<br>
Best regards<br>
<span><font color="#888888">ZK<br>
<br>
--<br>
snappy-devel mailing list<br>
<a href="mailto:snappy-devel@lists.ubuntu.com" target="_blank">snappy-devel@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/snappy-devel" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/snappy-devel</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a></div>

</div></div>