On Tue, Mar 24, 2015 at 10:10 PM, Jamie Strandboge <[email protected]> wrote: > 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.
Yes you are right. We surely shouldn't allow forks of other parties then the one we designed the policy for. So making it a clear 1:1 mapping is way to go. > > 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): > http://bazaar.launchpad.net/~jdstrand/snappy/snappy.frameworks-definition/revision/241 > > -- > Jamie Strandboge http://www.ubuntu.com/ > > > -- > snappy-devel mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snappy-devel > -- snappy-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel
