[RFC] enforcing system or app preference for app-provided slots

snapd
1

There are interfaces for which slots can be provided either implicitly by the system but also by application snaps (for example network-manager, wayland, possibly docker…).

In the case that both the system slot is present and also an application sported one, the auto-connection feature will refuse to auto-connect any snap to either of those because of the ambiguity.

There have been discussions and requests to allow enforcing a preference either generally for the interface, or from the point of view of an application snap with a plug for the interface.

It has been suggested to leverage the snap-declaration mechanism to be able to express this, either in the base-declaration for a general preference, or in the snap-declaration for a consuming snap preference.

A candidate solution is to extend the syntax supporting greedy plugs to cover this case.

The proposal is to allow for modifiers for the 1 slot case for slots-per-plug:

    slots-per-plug: 1,prefer-system|prefer-app

The modifiers wouldn’t be accepted for the any (*) case nor for plugs-per-slot as ATM there is no concept of system plugs. The order and the comma are mandatory.

1 Like
2

Is it conceivable that there could be multiple app snaps that provide the same slot? Would it be a better syntax to instead have the declaration list the provider snap names in order of preference?

slots-per-plug: 1,core|docker

ie. the above says to prefer the core snap to provide the docker slot and then the docker snap

3

In most of these cases where applications could plug either an implicit system slot or another application snap slot, it will be talking to some unique global resource.

In cases like the x11 and docker slots, this is a unix domain socket with a well known path (e.g. /tmp/.X11-unix/*, /run/docker.sock). In cases like the fwupd and avahi-observe slots, this is a well known name on the D-Bus system bus.

On the plug side, the application is going to talk to whatever happens to be listening to those well known locations. It’s not clear that the app can have a meaningful opinion over which slot to prefer. It’s not at all clear that the interface connection can meaningfully steer requests in one direction or the other.

If we’re not doing anything to force only one snap to provide slots like this, then greedy plugging to allow communication with all providers of the slot seems like the option least likely to cause problems.

1 Like
4

I agree with @jamesh. (And can confirm the same applies to the wayland interface to which I PR’d related changes.)

1 Like
5

enabling greedy plugs would simply paper over what seems to be ill-defined slots for practical/historical reasons. I will try to set up a discussion with @jdstrand to see if there is some remedy or some way to mitigate that.

1 Like
6

Bump? And another for 20 chars: bump?

7

@pedronis did anything ever happen?

Folks are still tripping over the insanity that Wayland doesn’t auto-connect when there is a snap with a Wayland slot installed. (C.f. https://github.com/snapcore/snapd/pull/7417)

8

In the specific case of Wayland, it’s possible that the already implemented “greedy plugs” feature is the right option rather than this RFC.

In general, interface connections are not going to influence which Wayland server an application connects to. They will connect to whichever server is identified by the $WAYLAND_DISPLAY environment variable. It’s quite possible that two concurrent invocations of a snapped application could connect to different Wayland servers.

Given that the wayland interface’s connected plug rules are just AppArmor and seccomp snippets, greedy plugging is probably the desired behaviour in most cases, and could be implemented via store assertions on the Wayland server snap.

9

@jamesh thanks for that suggestion. I’ll look into “greedy plugs” and how to get any necessary store assertions.

10

I asked @jamesh to chime on here. Thanks @jamesh. Greedy-plugs are discussed here: Plug/slot declaration rules: greedy plugs

1 Like
11

The only existing use of greedy plugs at present is for the gtk-common-themes and gtk-theme-traditionalhumanized snaps. You can see their snap declarations with the following commands:

snap known --remote snap-declaration series=16 snap-id=jZLfBRzf1cYlYysIjD2bwSzNtngY0qit
snap known --remote snap-declaration series=16 snap-id=JcEieEaWssvHBXLhtEvh0mdo9Q6Utoss

You’ve probably already got gtk-common-themes installed. If you install gtk-theme-traditionalhumanized, you should see it connect to the gtk-3-themes plug of all installed application snaps. When installing future GTK app snaps, you should see them connect to both theme snaps.

1 Like
12

There is also the arduino snap which uses greedy plugs for the serial-port interface:

$ snap known snap-declaration --remote snap-id=q7ex9QXSEs0gfmZHBPYtmSGSwjDTuYhF series=16
...
plugs:
  raw-usb:
    allow-auto-connection: true
  removable-media:
    allow-auto-connection: true
  serial-port:
    allow-auto-connection:
      slot-snap-type:
        - gadget
        - core
      slots-per-plug: *
...

which is probably slightly simpler to follow than the gnome examples

1 Like