My snap rejected for using snapd-control

store
1

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).

The source is available here: https://github.com/om26er/snap-manager (Note: the name is tentative and may change based on feedback).

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.

Here is the review url: https://dashboard.snapcraft.io/dev/snaps/8349/rev/1/

2

The idea for such a project originated on my previous question here Remotely managing devices

3

Note, the full text of the review is:

"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.

If the access is required, please give details why (eg, via https://forum.snapcraft.io/c/store) or consider using a brand store for your snaps."

4

There are, I suspect, two parts to this request:

  1. allow the use of snapd-control at all (ie, the installation constraint)
  2. 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)?

5

Currently that is true, but as the project gets a little more stable, I’ll make TLS mandatory.

This is currently a personal project. Mostly scratching the itch. So the main target for this snap are 1. desktops 2. Ubuntu Core systems (RPi etc).

We do have remote management as a planned feature at Crossbar but that’ll probably land in our commercial (closed-source) project.

6

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.

7

I am fine with that. Can my snap now be allowed to be published in the store ?

8

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.

The alternative of allowing private snaps to use snapd-control might also work if that proposal gains traction. (Related thread: Manually reviewing private snaps?)

9

@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.

10

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.

11

@jdstrand You may have read “default policy of rejecting” as “default policy of reviewing”.

12

Oh, ha, yes :slight_smile: We don’t have a default policy of rejecting, which is why I recommended @om26er come here to request and discuss its use. Thanks for correcting me! :slight_smile:

13

I am a bit out of names here, but will think of something. I wonder what name would feel “unofficial”. I definitely want to keep a mention of the word snap in its name.