On Friday, February 6, 2015, Alexander Sack <<a href="mailto:asac@canonical.com">asac@canonical.com</a>> wrote: > On Thu, Feb 5, 2015 at 7:40 AM, Martin Pitt <<a href="mailto:martin.pitt@ubuntu.com">martin.pitt@ubuntu.com</a>> 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 | <a href="http://www.piware.de">http://www.piware.de</a> >> Ubuntu Developer (<a href="http://www.ubuntu.com">www.ubuntu.com</a>) | Debian Developer (<a href="http://www.debian.org">www.debian.org</a>) >> >> -- >> snappy-devel mailing list >> <a href="mailto:snappy-devel@lists.ubuntu.com">snappy-devel@lists.ubuntu.com</a> >> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/snappy-devel">https://lists.ubuntu.com/mailman/listinfo/snappy-devel</a> >> > > -- > snappy-devel mailing list > <a href="mailto:snappy-devel@lists.ubuntu.com">snappy-devel@lists.ubuntu.com</a> > Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/snappy-devel">https://lists.ubuntu.com/mailman/listinfo/snappy-devel</a> >