I have a personal project that allows to manage snapd remotely.
The app connects to a server and exposes snapd management features (install/remove/refresh, etc) as remote procedures. These procedures may then be called using the http OR the wamp protocol (great for pub/sub).
My snap was rejected with the message Rejecting use of snapd-control to this snap for the public store. This interface is reserved for snaps that require device ownership and the ability to control all aspects of snaps on the system.
allow the use of snapd-control at all (ie, the installation constraint)
allow auto-connection of the interface
For ‘2’, with a name like ‘snap-manager’, it would seem logical to auto-connect the interface (if use of the interface was granted).
For ‘1’, the name ‘snap-manager’ is quite generic and sounds very official, and I don’t doubt that your snap needs snapd-control for what it advertises. I wonder if ‘snap-manager’ is too general and official sounding. Also, we’ve thus far severely restricted what snaps could use snapd-control in the public store since the interface grants device ownership to the snap, and granting the snap declaration strongly implies that this snap is safe for everyone to use. As described, it uses http and wamp. http is not encrypted and WAMP encryption is dependent on server configuration.
Is ‘snap-manager’ intended to be used on specific devices (and thus tied to models, publishers, gadgets, etc)?
Given the context, I’d suggest continuing its development by establishing the connection as usual, with snap connect your-snap:snapd-control, until the management software is further along, and then come back to discuss this again. The critical issue is the one James described above: this offers complete ownership of the system, so the bar for allowing auto-connections on it must necessarily be higher.
I am also interested in using the snapd-control interface for managing snaps on Ubuntu Core devices. Is there any chance of relaxing the default policy of rejecting every snap submission that uses snapd-control? Given that auto-connecting the interface requires a separate approval process, it seems unnecessarily unfriendly to developers to outright reject the snap.
@om26er Another point from Jamie was that the snap name was too general and official-sounding, and indeed I’d argue that the “snap manager” is actually snapd. Again, this would probably not be a big deal if we weren’t talking about a snap that has system ownership capabilities. Would you mind to pick another name that is less controversial in that sense?
@lance There’s no default policy of rejecting snaps that use snapd-control. There are policites that may cause snaps to be rejected when using it, though, for the reasons clarified in this topic. I hope people appreciate the fact we’re not offering ownership of their devices so easily.
Actually, snapd-control is one of the so-called ‘super-privileged’ interfaces and the base declaration has an installation constraint (in addition to auto-connection), so specifying it at all (currently) triggers manual review in the store (there is no problem with unasserted installs of course).
This can be revisited of course, but I would continue to argue in favor of the current status for the installation constraint. I’ve expressed my thoughts on this in the past so don’t need to rehash here-- if you’d like to reconsider this, I can make a change to the base declaration.