I attempted to publish a revision of the landscape-client snap some days ago, and it was rejected due to using the snapd-control interface (see message at bottom).
This snap requires snapd-control because we (the Landscape Team at Canonical) are developing Snap management features for Landscape. We also require the following interfaces be auto-connected for the same device management reasons:
hardware-observe
mount-observe
network-observe
scsi-generic
snapd-control (with “managed” attribute)
system-observe
shutdown
Tagging @mikecw here as well, as he’s also involved with this effort.
Thank you!
(original rejection message):
Rejected by David Lane. “The snapd-control interface is typically reserved for snaps that require device ownership and the ability to control all aspects of snaps on the system. The interface is super-privileged and uploads to the Global store are therefore automatically rejected.
Please create a forum topic at https://forum.snapcraft.io/ using the ‘store-requests’ category explaining why the snap requires the snapd-control interface. Feel free to copy and paste this message in the topic. Thanks!” — David Lane
Hi @mitchburton, although the auto-connection to snapd-control has been granted, could please still provide which specific snap management tasks this snap needs to do and why? Thanks
Hi @sahnaseredini, Landscape’s roadmap includes management of snaps on registered clients, in line with the way Landscape manages packages when the landscape-client debian package is installed. This includes installation, removal, refresh, and hold/unhold via snapd’s REST API.
+1 to this request. snapd-control is a very privileged interface, so if you detail the specific snap management features landscape is developing, we might be able to find a less privileged alternative.