Request for snapd-control interface and auto-connection of interfaces for landscape-client

store-requests
#1

Hello!

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

Auto-connect shutdown interface for landscape-client
#2

I’m surprised there is no log-observe in the list, does landscape not also allow monitoring device logs ?

Similar for the shutdown interface that would allow reboot and shutting down the machine from the agent via a dbus call.

#3

Currently, no, client does not monitor device logs, but good call on shutdown. Will add.

#4

@mitchburton Hi Mitch, I’ve added allow-installation and allow-auto-connection to snapd-control for the landscape-client snap. Please give it a try!

#5

Thanks! Looks good to me. Can we also get auto-connection for the other interfaces I mentioned or is there something I need to change on my end?

#6

There are a few more interfaces we would like to have auto-connected, if we could. Let me know if you need more details on any of them:

  • hardware-observe
  • mount-observe
  • network-observe
  • scsi-generic
  • system-observe
1 Like
#7

Ok. I’ve asked @policy-reviewers to weigh in and confirm. :ballot_box:

#8

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

1 Like
#9

However, regarding the need for the following interfaces, they are inline with this snaps functionality:

  • hardware-observe
  • mount-observe
  • network-observe
  • scsi-generic
  • system-observe

Therefore +1 from me for auto-connect of these snaps.

@reviewers could you please chime in as well. Thanks.

#10

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.

#11

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

#12

+1 from me as well for the requested auto-connections. They are clearly required for the landscape-client snap to properly operate.

#13

ah sorry I missed you already answered! thanks for the explanation.

#14

@mitchburton thanks for the explanation.

#15

+2 votes for and 0 against. Granting auto-connection to the following interfaces to landscape-client:

  • hardware-observe
  • mount-observe
  • network-observe
  • scsi-generic
  • system-observe

This is now live.

1 Like