[RFC] Improving hardware access for snaps

[Sergio Schvezov]

On Friday, February 6, 2015, Alexander Sack <asac at canonical.com> wrote:
> On Thu, Feb 5, 2015 at 7:40 AM, Martin Pitt <martin.pitt at ubuntu.com>
wrote:
>> Hey Jamie,
>>
>> Jamie Strandboge [2015-02-04 12:54 -0600]:
>>> On 02/02/2015 04:34 AM, Martin Pitt wrote:
>>> >  * Often you don't want the exposed program to have said capability,
>>> >    but a daemon. E. g. you have a daemon which talks to the hardware
>>> >    and thus needs the privileges, but there is no reason to expose
>>> >    that as "public" binary; you only do that for a possible CLI
>>> >    control program (which doesn't need the hw access), or possibly
>>> >    you don't even have such a CLI program in the first place. And I
>>> >    suppose we don't want to force snaps to have to declare their
>>> >    internal daemons as binaries, as these should be "services:"?
>>> >
>>> I'm not sure what you were thinking here, but I'm not sure that matters
(see
>>> below where I agree with your point). That said, I'll say a few things
so we are
>>> on the same page.
>>>
>>> A snap need not specify different 'services:' or 'binaries:' for all the
>>> binaries it ships. This means that if there is a service that starts on
boot, it
>>> may call out to any programs in the snap's install dir and inherit the
policy of
>>> the service.
>>
>> Exactly my point -- I thought we explicitly don't want a .snap to
>> explicitly declare "internal" binaries such as daemons or helpers,
>> only the user-facing ones. But then something like "add hw access to
>> myapp/myprogram" doesn't work if "myprogram" isn't declared in
>> binaries: or services: in the first place. Also, we shouldn't care
>> which internal binary actually does the hw access, as it should be an
>> implementation detail. From the OS' POV the thing that matters is that
>> the snap as a whole can access the hardware or not, isn't it?
>>
>>> In this manner, specifying <name>/<service> achieves the goals of
>>> giving these helper binaries access.
>>
>> Oh, so you intended this to work even for internal binaries which
>> weren't declared in the yaml? (past tense as I think we already agree
>> and you also want to make this per-snap now, not per-binary.)
>
> So even if this is temporary, I full agree that we shouldn't go down
> to per binary nor per service; just per snap. Ultimately, if an app is
> stepping on its own toes and does concurrent access to a device node
> that only can have one client at a time, then that's a buggy app. Yes,
> maybe giving apps means to protect itself frm its own buggyness and
> evilness might make sense, but let's first keep the security and
> access contract simple and something focussed to model the system -
> app and app - app rules rather than going inside the app itself.
>

I think this is what will drive people to do frameworks (or rely on them)
in the future.

> Not sure what the conclusion was, but for assigning a device to an app
> would allow all processes that are launched inside the app space
> access to it. (e.g. internal, binaries, services doesnt matter). But
> let me know if I am missing something.

That's the general agreement.

> On general command line XP, I feel hw-add is just the wrong word. In
> the end the hw gets either added by the user or the appliance builder
> and not by this command, but what this op is doing is really assigning
> or granting (exclusive) access:
>
> With both, how about:
>
> $ snappy hw-assign foo /dev/ttyUSB0
> $ snappy hw-unassign foo /dev/ttyUSB0

How about?

snappy allow foo [resource]
snappy disallow foo [resource]

Feels like simple words even if not one syllable.

>
> btw, while we suspect that the above might be a temporary thing and I
> sense our real CLI xp will be quite different soon it is not really
> true that the above would have to cause problem with repluggin. This
> is only a problem if we would safe the devnode path in the acl engine,
> while i can fully see this op just being a short hand that under the
> hood saves the real identifier of the device class we found and uses
> that for set up and potentially reeval the apparmor rules on hotplug
> to just do the right thing (TM).
>
>>
>> Thanks,
>>
>> Martin
>>
>> --
>> Martin Pitt                        | http://www.piware.de
>> Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
>>
>> --
>> snappy-devel mailing list
>> snappy-devel at lists.ubuntu.com
>> Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snappy-devel
>>
>
> --
> snappy-devel mailing list
> snappy-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snappy-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150206/ae25b570/attachment-0001.html>