[RFC] Snappy frameworks

Jamie Strandboge jamie at canonical.com
Tue Mar 24 21:10:59 UTC 2015

On 03/19/2015 09:18 PM, Sergio Schvezov wrote:
> On jueves 19 de marzo de 2015 19h'38:53 ART, Jamie Strandboge wrote:
>> We've discussed frameworks quite a bit but we've yet to provide a definition,
>> how they will be used on snappy, how they work with the store and how
>> they extend security policy. This email attempts to address this (I expect there
>> to be some fine-tuning but I think it is in good enough shape for wider comment).
>> Please see:
>> http://bazaar.launchpad.net/~jdstrand/snappy/snappy.frameworks-definition/view/head:/docs/frameworks.md
> I created an MP with syntax and typo corrections:
> https://code.launchpad.net/~sergiusens/snappy/snappy.frameworks-definition/+merge/253625
Thanks! Merged

> wrt some parts of the text:
> Can frameworks be forked? If yes, the definition of pkgname and the associated
> policy becomes tricky. The top level discussion makes me assume it is a yes
> I'm thinking foo.sergiusens, the dbus path for that would still be `/foo/meh`,
> right? It would be good to reinforce forks in the document (forks are .developer
> packages in this context).
> When the policy lives outside of the package, I suppose this would imply that
> all forks inherit the same policy.
I wasn't thinking we would allow forks of this nature in the store, but
developers would be able to sideload a modified framework if they want.

Consider this characteristic of frameworks which informs much of the definition
of frameworks:

 "Unlike apps, frameworks have special permissions which allow them elevated
  access to the system"

Frameworks are special. Frameworks are trusted. Frameworks need to be designed
with security in mind since they increase the attack surface for untrusted apps.
As such, we shouldn't allow forks of a framework in the store (people may always
sideload); the framework should just be updated as needed. We will of course
always support a differently named framework so if people really want to fork,
they can grab the framework, rename it, rename the file or two in the policy
directory, rename binaries, etc and when ready to upload to the store, work with
the store owner (eg, Canonical for the Ubuntu store). I think it is also
important to remember that there will be relatively few frameworks relative to apps.

On top of all of that, allowing forks of this nature would add a lot of
complexity with little benefit due to how frameworks will be managed by store
processes. Sharing policy is a hard and assuming we could share policy in a
clean way, we would then have to have rules that worked across all of them which
would result in a 'lowest common denominator' policy that might not provide the
protection we want.

One thing that came to mind when drafting this is that there is an interesting
inconsistency between these characteristics:
* Frameworks exist primarily to provide mediation of shared resources
* Frameworks can be installed on the same system without conflicts

The current RFC handles this ok on the filesystem fine. However, we have not
defined runtime conflicts: what happens if there are two different competing
frameworks for say, handling a serial device. Framework foo gives app bar access
to /dev/ttyS0 and framework baz gives app norf access to /dev/ttyS0-- we have a
runtime conflict.

This is interesting to think about, but I don't think it should block our
current definition. Since the store owner works with the framework authors, the
store owner can either choose to only allow one framework per shared resource or
allow competing frameworks. If the store allows competing frameworks, and since
this might provide a runtime conflict, we perhaps want to support the concept of
'conflicts' at the store level (ie, a store admin can say two frameworks
conflict, and 'snappy install' knows what to do with that information-- ie,
don't encode it in the package.yaml or anything).

(IMHO it seems reasonable to have competing frameworks so long as they each
"provide a significant benefit for many users".)

> With regards to binaries, *top* level binaries and clashing, how is that dealt
> with while having the coinstall requirement?
I was thinking this would be coordinated as part of the onboarding process and
enforced by the review tools.

I've updated the doc based on the above (with a few other minor changes):

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/20150324/09e59827/attachment.pgp>

More information about the snappy-devel mailing list