[RFC] Improving hardware access for snaps

[Martin Pitt]

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

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150205/2901fe5e/attachment-0001.pgp>