Snapd-desktop-integration snap ownership and auto-connection request

store-requests
1

The snapd-desktop-integration snap will run in the users session and handle theme installation for the user. This requires access to install other snaps. This snap is maintained by the Ubuntu Desktop Team, I’d like to request transfer of ownership to Canonical

I’d also like to request auto-connection for snapd-desktop-integration:snapd-control

Thanks for your consideration

2

Is there a design document for this? I’m thinking about:

  • can snap login/polkit be bypassed?
  • what limits (perhaps internal, perhaps snapd-enforced) are in place on what the snap is allowed to install?
  • if there are limits, how are they enforced?
  • how can the unconfined non-root user influence the snap if the user is in a privileged group (eg, the first user on the system)?
  • how can the unconfined non-root user influence the snap if the user is not in a privileged group (eg, non-admin users on the system (ie, a child’s account))?
  • how can other snaps influence this snap? Does it export a content interface? A DBus service?
  • how can other snaps influence this snap on systems with partial or forcedevmode confinement (eg, Arch or Fedora, respectively)?

There may be other questions after design review

3

I think the closest thing we have to a design doc is Automatic theme snap installation notes

I’ll defer to @jamesh to answer the questions.

4

That doc says that snapd will enforce via polkit if theme snaps can be installed and there will be a separate API for that, but this request is for use of snapd-control, so has that API and polkit integration been implemented in snapd?

If no, then I would be uncomfortable granting snapd-control at this time since the snap would have device ownership.

If ‘yes’, then most of my questions are answered (snapd via polkit policy on the theme-specific APIs are mediated by snapd).

Also, it wasn’t clear to me from that doc that the snapd-desktop-integration helper would itself be delivered as a snap, so this question remains: how can other snaps influence this snap? Does it export a content interface? A DBus service?

Another question is that the snapd-control interface grants access to a particular socket and access to that socket grants device ownership to the snap. It sounds like the other forum topic handles when non-root processes use the new theme APIs, but it makes me a bit uncomfortable that snapd-desktop-intergration must use ‘snapd-control’ interface since that socket API offers much more than the new polkit-protected theme APIs. Eg, what can the non-root snapd-desktop-intergration do with the other APIs that are currently offered to non-root? If the snapd-desktop-intergration snap ever shipped a system daemon, it runs as root and the snap would have the ability to access the whole API. Should we add a new interface (eg, snapd-themes-control?) or a new attribute to snapd-control? (@pedronis, perhaps you can weigh in)

5

The plan was never to simply grant snapd-control. We need to design an API that is mediated probably over the snapctl socket and via polkit and possibly a specific interface.

I discussed this with @jamesh and he should be aware.

6

The snapcraft.yaml currently plugs snapd-control because the prototype is currently implemented in terms of existing REST API calls rather than something we can provide via a locked down interface. We will definitely work towards creating and migrating to a safer interface once we’re sure what that API should look like.

As an interim measure, would it be okay to allow installation of the snap but not auto-connect the plug?

7

From my POV, the publisher is vetted and the snap won’t be used for anything but development purposes while the API is being worked out, so this would be ‘ok’. I’d like to hear @pedronis thoughts on this before granting it though.

8

As discussed with @jamesh the agreement is to try to get to the proper interface/API sooner rather than giving snapd-control temporarely.

1 Like
9

Thanks, we’ll remove this from our review queue then.