[RFC] Improving hardware access for snaps

[Alexander Sack]

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.

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.

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

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
>