any API to do that?
Thanks!
Shuduo
Hey
Since I think I know what you were asking (based on our IRC conversation) I will answer more broadly:
Yes you can manage interfaces with an API. This is how “snap connect” and “snap disconnect” do it today. You cannot yet create interfaces dynamically, that is on the roadmap under the term “hotplug”. You create new interface types dynamically, those have to be proposed and merged to snapd.
The reason for that last part is that interfaces have total control over the security of the whole system. A single line in an interface definition can disable the sandbox so we really want to ensure nobody is compromising their system by installing a snap.
Having said that the process for inclusion of new interfaces is pretty well tested. Most of the contributors to snapd that added a just a few patches added a new interface. If you have a need for concrete interfaces those can be discussed here on the forum or on a bug report. The security team routinely reviews all the bug reports tagged with the tag snapd-interface. Given our rapid release cycle the interface is broadly available for general use very rapidly. People tracking edge can use it hours after it gets merged upstream.
Let me know if we can help you in any way.
@zyga-snapd, I guess there are two questions. 
One is how to add a new interface as we have discussed on IRC and you answered clearly already.
Another question I believe is customer want to batch-manage many devices via a management tool like Landscape. I know Landscape for snappy is not ready today so I’m curious if there is an API can be utilized by customer own tool/script. Suppose customer own those devices and have permission to login device.
There’s the snapd-control interface that can be used by management solutions. Your snap can use it (though an assertion controls if you can actually get it, it can be granted from the store) to ask snapd to perform arbitrary management tasks.
snapd-control interface in https://snapcraft.io/docs/reference/interfaces has no much detail information. Could you please point where I can find its documentation? And could assertion control be granted from brand store? I am not sure if a snap on public store can get assertion control on public store will be easy.
Indeed, that’s not well-documented. I think we should have a per-interface documentation thread that is a wiki and can be edited. I will start one soon. For the moment I will say that it allows you to talk to the privileged snapd socket and issue any command to it (like an unconfined user running the snap command). You can use it to install / remove / disable / enable / refresh snaps and anything else.
regarding customers that actually provide images, you can declare plug/slot connections in the gadget snap for automatic connection in your image (like you can pre-install snaps).
so if you have a customer that actually rolls out images for specific devices they can indeed use that mechanism to pre-connect the necessary plugs and slots.
Not only pre-defined plug/slot. Customer requests to “dynamically” manage them. For example switch off 1000 IP-camera capturing among 5000 IP-camera devices for some reason.
OK, I will explain with this.
there you would probably just stop the capturing service then… i’m not sure you want to manage such a thing via blocking the interface and keep the service running and spam your logs with denial messages. i dont think connecting/disconnecting except in relation with a package install/removal is anything you want to use as “management interface” for anything.
If the camera capture device has a configuration you can use the snapd-control interface to reconfigure a snap on those 1000 devices to, for example, set the capture=false property. You can also stop any services or even revoke camera access, it’s all up to you. That said the snapd-control` interface is privileged and you’d have to get in touch with Canonical to request access to it.
this works as long as the device manufacturer is the one wanting interface auto-connection. as soon as an ISV takes up a device from someone else, creating a new gadget snap means a new model assertion, a new kernel snap, etc… and suddenly they loose all benefits of a maintained kernel snap from the original ODM.
One topic per interface is a great idea!
But let’s please not create empty topics waiting for good content. Let’s only create one when we have the time to describe the status quo for that interface well.
1 Like
Let me think another scenario… customer want to make all snaps stop to access network (snapd is still working to access network for auto refresh) on 1000 gateway among 5000 gateway devices.
I’ll start with the content interface as it has the most demand and quirks to document.
I have raised my concern if a snap with snapd-control privilege on public store can be downloaded by anyone to harm any device?
No, that interface is not auto-connected by default unless it’s a known snap that went through review, so simply installing snaps that are experimenting with it cannot harm anyone unless the administrator explicitly grants access.
1 Like
same thing, your log would explode with denial messages for all the snaps you disconnected … since your managemment tool will need to iterate over a list of snaps per device to disconnect them all you can as well just use this list of snaps to turn off their services instead. using the interfaces to manage such stuff is really not the best idea.
i agree it should be possible for privileged consumers of the REST API to be able to connect and disconnect them, like you can do with snap connect and disconnect when ssh’ed in, no question. but they are a privilege management system, they should not be abused as service management tool.
1 Like
Any documentation on how API can be used to connect/disconnect interfaces?
Otherwise, How can I make my snap plugs auto-connect?