[RFC] Improving hardware access for snaps

[Jamie Strandboge]

On 02/06/2015 01:23 AM, Alexander Sack 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.
> 
> 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
> 

That's fine. I've now got this:


= Relevant packaging yaml =
  name: foo
  version: 0.1
  ...
  services:
    - name: bar
      start: bin/bar
    - name: baz
      start: bin/baz


= Adding access =
$ snappy install foo
...

$ snappy hw-assign foo /dev/ttyS0
'foo' is now allowed to access /dev/ttyS0

$ snappy hw-assign foo /dev/ttyS1
'foo' is now allowed to access /dev/ttyS1


$ snappy hw-assign foo /dev/ttyUSB*
'foo' is now allowed to access /dev/ttyUSB*


= Listing access =
Use 'hw-info' to be consistent with 'snappy info' command.

$ snappy hw-info
foo: /dev/ttyS0, /dev/ttyS1, /dev/ttyUSB*
norf: ...

$ snappy hw-info foo
foo: /dev/ttyS0, /dev/ttyS1, /dev/ttyUSB*


= Removing access =

$ snappy hw-unassign foo /dev/ttyS0
'foo' is no longer allowed to access /dev/ttyS0

$ snappy hw-info foo
foo: /dev/ttyS1, /dev/ttyUSB*


> 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).
> 
As mentioned in my blog post and elsewhere, I agree with you that the final UX
to be different, yes. However, the above need not be temporary since we can keep
it around (even if its not prominently documented as the proper way (eg, could
just have it in a man page)) for whenever a board-person, tinkerer or evaluator
just wants to make a change to test something out real quick.

-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150213/5f61d7ac/attachment.pgp>