We are developing a product at Crossbar.io GmbH, that will be able to remotely install snaps on a UbuntuCore system (apart from lots of other features)
How easy/difficult would it be to get it published to store, there a criteria out there to be eligible to get permissions for snapd-control ?
a hard requirement for snaps using snapd-control is that they do not live in the public store, you need a brand store for snapd-control (and some other super-privileged interfaces like module-control) …
I thought a gadget owner could also do it (but I don’t know that part of the code).
a gadget owner can surely set up the interface via the connections: option in gadget.yaml … but you wont be able to upload a snap using it to the public store, it gets stuck in manual review and will be rejected due to policy.
this is a bummer for us. In this case, we will need to use sth else than ubuntu core - or bake our own images removing this restriction - but we then still can’t use the public store. this sucks.
can you tell us more about your use case?
sure, our use case looks like this:
we are a commercial OSS company, produce crossbar https://github.com/crossbario/ and
initiated WAMP https://wamp-proto.org/
crossbar is a decentralized messaging middleware - a data plane, like SDN for apps
we have a commercial/enterprise product built on that: crossbarfx center
this adds a controller able to manage/monitor networks of interconnected crossbarfx nodes
those nodes can also run on edge devices (IoT is a focus for us), and crossbarfx
allows to remotely deploy/manage/monitor applications components that connect to crossbar
via Docker containers and snaps
for managing Docker containers, the crossbarfx running on the edge device talks to
the Docker daemon on that edge device host (via unix domain socket), and the crossbarfx node itself connects to our controller (via outgoing secure websocket), from where the user can centrally manage all the nodes and containers
note that we have that already. works great.
as we really like the advantages of ubuntu core / snaps, in particular in IoT (but also desktop), we would like to do similar with snaps/snapd
eg admin logs into crossbarfx center (web based), selects some app microservice wrapped as a snap, selects the edge devices and hits “deploy now”.
doing it with docker works, but as docker wasn’t designed for edge devices (eg not fine grained control over hardware access permissions, rollbacks, etc), we really would love to support snap(d) as well.
well, technically, I think we have an alpha already implemented, not sure about status. anyways. technically easy to do, but we only now became aware of the policy restrictions that might bite us - hence this thread;)
can we (are we legally allowed) to:
publish our snap “somewhere” (our site) or preinstall it and then have it talk to snapd and pull snaps from the public store (for deploying apps/microservices connecting to crossbar on the device)?
rgd branded snap store, how would that work? I’ve read https://docs.ubuntu.com/core/en/build-store/create.html, but still confused.
so you say our snap that talks to snapd can only be published on a branded app store. if we had such a store, and would only publish our own, single snap there (to overcome the policy), we could have our snap talk to snapd and eg pull snaps from the public canonical store, right?
but the user cannot any longer just say snap install crossbarfx because it needs to pull that from our branded store first, right?
i dont see why anything would legally block you to manually pre-install a non-store snap anywhere, but note that snaps that do not come from the store will not be automatically upgradeable, will not be able to use snap declarations to auto-connect interfaces or set command aliases and you will always have to use the --dangerous flag to install them.
if you say “preinstall” i assume you mean in an ubuntu core image ? for that you would simply build the image from your brand store (note that brand stores inherit the core snap automatically and if needed you can make it auto-copy required kernel or gadget snaps into your store). for classic images see the doc at the bottom of this post, you’d put a change to /etc/environment into your build to have your snap installed from a particular store.
if you want general users (i.e. not users of your preinstalled image) to install a snap from your brand store you would have to ask them to set an UBUNTU_STORE_ID environment variable:
thanks a lot for your comment and the infos!
also, please let me prefix: we want to understand more about brand stores, and of course are fine in principle that canonical “means business” at some point;) that is cool, need to understand this (the branded app store approach) better first. do you have a contact to PM to learn more about the business/cost side of this?
if you say “preinstall” i assume you mean in an ubuntu core image ?
yeah, I mean baking a complete image (for the target devices) that has crossbarfx preinstalled.
I guess in this case we could also build and run a patched version of snapd (complying with its GPL3) to work around those other artificial restrictions you mention.
obviously, we’d rather want to avoid that.
another option would be to somehow distribute our own snap to the devices (outside of snapd), and then install the snap locally (triggered remotely from our controller)
well, why is there this policy in the first place? not being allowed to talk to snapd is harsh …
it gives all snaps using that interface pretty much full root access to the system (snapd runs suid root) which is why this interface (like i.e. the kernel-module-control interface) is not allowed in the public store…
brand stores are designed for device manufacturers, the build tools have full integration with brand stores for that reason (and will automatically create images that use that store) … if you own a device image you can indeed have full root access (you typically own the gadget and kernel too) so you can also use all the super-privileged interfaces in your brand store for them.
so snapd exposes an API entry point that allows me to run arbitrary commands (via snapd as root then)? if so, would be IMO a bug in snapd (for the record, I don’t expect this to be the case). if not, then what’s the attack surface?
as far as I understand, sure, installing/uninstalling snaps is security sensitive, and should not be allowed to any arbitrary snap, but this is far from “full root access”.
pls excuse, I don’t wanna trigger a big ranty thread on this. I do figure there might be very good business reasons for canonical here, but technically (security wise) … different matter. I would much prefer a clear, direct statement: “if we open that, why would anyone buy a branded store?” or sth=) again, I don’t wanna leave a wrong impression here. business reasons are very good reasons …
indeed not … but it gives your snap way more access than a snap should have …
regarding the business reasons, indeed these exist, but the decision to block that interface in the public store was there before brand stores existed, they are not the cause but the solution after all 
