Interface management

doc
1

Interfaces allow (or deny) access to a resource outside of a snap’s confinement.

Most users don’t need to worry about interfaces. Snaps are designed for strong application isolation and safe interface connections are made automatically.

An interface is most commonly used to enable a snap to access sound playback or recording, your network, and your $HOME directory. But which interfaces a snap requires, and provides, is very much dependent on the type of snap and its own requirements.

See Supported interfaces for a comprehensive list of interfaces and what kind of access they permit.

Plugs and slots

An interface provides a level of access to resources, such as audio playback, as defined by a slot. One or more snaps can access this resource by connecting a corresponding plug to the slot.

In other words, the slot is the provider of the resource while the plug is the consumer, and a slot can support multiple plug connections.

How an interfaces uses a plug and a slot

In the output to snap connections vlc (see above), every interface used by VLC is listed in the first column. The Plug and Slot columns then describe how each interface is connected.

For instance, the audio-playback interface connects VLC’s audio-playback plug to the system’s audio-playback slot so you can hear the sound it produces.

Listing interfaces

You can see which snaps are using an interface with the interface command:

$ snap interface audio-playback
name:    audio-playback
summary: allows audio playback via supporting services
plugs:
  - chromium
  - vlc
  - zoom-client
slots:
  - snapd

In the above output, you can see that Chromium, VLC and the Zoom snaps are connected to snapd’s audio-playback slot, which is synonymous with Core and system.

To see all the interfaces being used by your system, run snap interface. To see all the interfaces available to your system, including those not currently being used, run snap interface --all.

Snap connections

On the terminal, the snap command provides more granular control over interface connections and which interfaces are operational on your system.

The snap connections command lists which interfaces are connected and being used, while adding --all additionally shows interfaces with unconnected slots or plugs (shown in the output as a -):

$ snap connections --all
Interface            Plug                           Slot                     Notes
adb-support          scrcpy:adb-support             :adb-support             -
alsa                 ffmpeg:alsa                    :alsa                    manual
appstream-metadata   snap-store:appstream-metadata  :appstream-metadata      -
iaudio-playback      ardour:audio-playback          :audio-playback          -
dbus                 -                              cameractrls:dbus-daemon  -
[...]

To see which interfaces a snap is using, and which interfaces it could use but isn’t, type snap connections <snapname>:

$ snap connections vlc
Interface       Plug                   Slot                 Notes
audio-playback  vlc:audio-playback     :audio-playback      -
audio-record    vlc:audio-record       -                    -
camera          vlc:camera             -                    -
desktop         vlc:desktop            :desktop             -
home            vlc:home               :home                -
(...)

In the above output, the camera interface is not connected because its slot is empty. This means VLC cannot access any connected cameras.

VLC can access the user’s /home directory because the home interface is connected to the system $HOME directory (denoted by the :home slot name).

To see all connected interfaces on your system, use the snap connections command without a snap name:

$ snap connections
Interface      Plug                    Slot                 Notes
adb-support    scrcpy:adb-support      :adb-support         -
alsa           ffmpeg:alsa             :alsa                manual
alsa           telegram-desktop:alsa   :alsa                manual
audio-playback ardour:audio-playback   :audio-playback      -
audio-playback chromium:audio-playback :audio-playback      -
(...)

Adding --all to the snap connections command will list all interfaces, including those without a connection:

$ snap connections --all
Interface      Plug                    Slot                 Notes
adb-support    scrcpy:adb-support      :adb-support         -
alsa           entropypianotuner:alsa  -                    -
alsa           ffmpeg:alsa             :alsa                manual
alsa           guvcview:alsa           -                    -
(...)

Auto-connections

Many interfaces are automatically connected when a snap is installed, and this ability is a property of either the interface itself, or the snap.

Automatically connecting interfaces include the network, audio-playback and opengl interfaces. This auto-connection ability is carefully reviewed for each interface, where permissiveness, security and privacy implications, and the expectations of the user, are all considered.

A snap’s developer can also request that an interface is connected automatically through a manual review process. As above, these requests are carefully considered and reviewed before being granted or denied.

Interfaces not connected automatically require the user to make a manual connection (see below), such as the camera, removable-media and audio-record interfaces. Manual connections enable the user to have a complete control over what kind of access they allow.

If a snap is installed prior to an interface being granted auto-connect permission, and permission is subsequently granted and the snap updated, when the installed snap updates, the interface will be auto-connected.

For more technical details on how interface auto-connections are processed, see The interface auto-connection mechanism.

ⓘ See the Auto-connect column in the Supported interfaces table for which interfaces are connected automatically.

Manual connections

When you need to connect an interface manually, such as when you want to grant a snap access to audio-record for audio input, use the snap connect command:

snap connect <snap>:<plug interface>

With no further arguments, the plug will connect to the system via the snap daemon, snapd.

For example, to connect VLC’s audio-record plug to the system’s audio-record, you’d enter the following:

sudo snap connect vlc:audio-record

To connect an interface to a slot provided by another snap, provide this as an additional argument:

snap connect <snap>:<plug interface> <snap>:<slot interface>

A slot and a plug can only be connected if they have the same interface name.

Add the --no-wait option to snap connect or snap disconnect to run the process in the background and return immediately to the command prompt.

A successful connection grants any necessary permissions that may be required by the interface to function.

Disconnect interfaces

To disconnect an interface, use snap disconnect:

snap disconnect <snap>:<plug interface>

Following our previous example, you would disconnect vlc:audio-record with the following command:

sudo snap disconnect vlc:audio-record

Forget manual disconnections

When an automatic connection (see above) is manually disconnected, its disconnected state is retained after a snap refresh. This state is even stored after a snap has been removed, including removal with the --purge option.

The --forget flag can be added to the disconnect command to reset this behaviour, and consequently, re-enable the automatic re-connection after a snap refresh.

4 Likes
2

Is it correct that for a Snap to operate in confined mode through an interface, that the app must somehow code against that interface? For example, if I have an X11 app would I code it against the Snap X11 wrapper, or just start using the X11 API directly?

3

It is important to note that ‘interface’ here is a snapd term, not to be confused with Application Programming Interfaces (APIs), Application Binary Interfaces (ABIs), DBus interfaces, etc. Your snapcraft.yaml/snap.yaml declares the snapd interfaces that your snap needs to use relevant programming interfaces for the resource. In your case, you declare ‘plugs: [x11]’ and then you are allowed to talk to the X server using the raw X protocol or any other higher level abstractions (eg, windowing toolkits like gtk, qt, etc).

1 Like
4

Ok interesting, that is a little different than what I had expected. Doesn’t that leave the Snaps in the position of needing knowledge of the systems they’re deploying to? For example if I have a Snap that is requesting :network-setup-control don’t I need to know what network manager is installed?

Also, are there any good resources on writing against Snap interfaces for developers? This is pretty much the only link I can find and it’s hard to understand what exactly is being opened up when an app is connected to an interface.

5

Interfaces can be thought of as contracts between the slot side (the provider, sometimes its a service) and the plug side (the consumer). On an all-snaps system like Ubuntu Core, the snap executes in a predictable runtime where snapd exposes so-called ‘implicit slots’. Other slots are provided by app snaps (eg, a network-manager snap). In this manner, you only have to know what the slot implementation provides. It would be considered a bug in a providing snap to drop APIs, etc or otherwise break consuming snaps.

For so-called classic distributions where snaps are installed alongside debs/rpms, the above mostly holds true for strict and devmode snaps, though, yes, it is true that Fedora and Ubuntu might ship different network-managers as part of the system. Typically there isn’t a tight coupling between the client libraries and services (indeed, libraries like Qt have abstractions you program to and they figure out which network-manager DBus APIs are available), but where there is a tight coupling, the snap would have to account for that.

For ‘classic snaps’ which have no confinement and can access anything on the system directly, it is up to the snap publisher to account for any difference across distributions (which is made is by using libraries like the aforementioned Qt with network-manager).

6

I’ll defer to the snap advocacy team here (@evan, @Wimpress and @popey) but can say you can look at the snapd source code for the latest on what is allowed: https://github.com/snapcore/snapd/tree/master/interfaces/builtin

7

Ah ok actually that source is very helpful. So for the network_setup_control interface, it’s actually operated by files using netplan. And I guess network_bind operates by allowing system calls to accept/bind/listen? That seems doable.

Our current installation script uses authbind though. So much to learn. I’ll save it all for another thread though. It looks like the source is the place to go for good dev details on interfaces now.

8

Is it possible for a launcher (preferably, a shell script) to detect whether a certain interface is connected to a snap without detecting AppArmor denials?

9

You could try:

#!/bin/sh

usage() {
    echo "Usage: check-plug <snap name> <interface name>"
    exit
}

if [ -z "$1" -o -z "$2" ]; then
    usage
fi

SNAPNAME="$1"
INTERFACE="$2"

if snap interface "$INTERFACE" | sed -e '1,/plugs:/d' | sed -e '/slots:/,$d' | awk '{print $2}' | grep "^$SNAPNAME\$" >/dev/null; then
    echo connected
else
    echo not connected
fi

Edit: Just spotted that you want this inside the snap. I don’t know if that data is exposed to the application in a snap… I just checked snapctl, which doesn’t appear to expose the info, so you cannot do it through that.

1 Like
10

Thanks for the info.

11

indeed you dont really need to “detect denials” but just check if you have the expected access to a file, device or whatever the interface normally provides.

#! /bin/sh

[ -r "/var/log/syslog" ] || echo "please connect log-observe !!"
1 Like
12

I would like to found out how to assert plugs/slots and plugs & slots with attributes in this topic.

13

This topic used to have all the undocumented and new interfaces which are not yet updated in https://docs.snapcraft.io/reference/interfaces . I see they are no longer available here as well. Could you please add a link where we can find the updated interfaces list ?

1 Like
14

We’re currently working on the Interfaces pages and we’ll definitely be adding the interface list back (likely today), along with a reference to each interface. Sorry this isn’t clear - when something like this affects the docs again, I’ll leave a ‘Work in progress’ note with an explanation.

1 Like
15

The interface section is still not available. When can we expect it to be back ?

16

Have you seen Supported interfaces? It should include all the details there were previously in this topic, but let me know if there’s something missing.

2 Likes
17

Still broken here (18.04 LTS). The above steps do not resolve it.

The snap was ‘postman’ and my home folder is /home/local/SOMETHING/myname

18

So this page doesn’t seem to teach you how to add interfaces to your snapcraft file, and neither does:

The latter tells you what interfaces are supported, but neither of these docs seem to be linking me towards, as an author, how to do a strict mode snap and have it request interfaces.

The Go examples are both “devmode” snaps, and thus don’t do confinement (AFAICT).

Some of that seems to be described in:
https://docs.snapcraft.io/the-snap-format/698

but if you just start with “Creating a Snap” it seems to direct you immediately to the language-specific details, which at least for the Go ones, doesn’t direct you back.

19

We’re missing a huge chunk of the snapcraft lifecycle, including installation (in a central place), command syntax, confinement, adding interfaces, using plugins, tracking down dependencies, build override examples, scriptlets, troubleshooting and publishing.

All of the above are high priority (and what I’m currently working on), so we’ll have something published on here soon.

2 Likes
20

As a snap package creator, I am interested in what precisely a particular interface provides, in technical terms. Some interfaces are pretty intuitive, like ‘home’. Some others are rather obscure: for example, what precisely does plugging into ‘avahi-control’ enable? How exactly does it affect my C program which uses the avahi-client library? And If I want to provide a slot for an interface, what precisely must I do in my snap?

I assume it ultimately all comes down to the basic Linux kernel and IPC interfaces: files, system calls, etc. It would be helpful if the interfaces were described in terms of those primitives. Given that there is just a few of those basic primitives, I also wonder why there are very specific interfaces such as ‘avahi-control’? Why is something related to an application like Avahi part of the basic snap system? Would it make sense for any snap other than ‘avahi’ to provide the avahi-related slots? What happens if multiple snaps provide this slot? As another example, the ‘docker’ interface begs the same questions.

Furthermore, if the interfaces are intended to be so application specific, then it seems essential for a snap application developer or an embedded system developer to also be able to implement their own interfaces, without hacking the snap system itself. Is that possible or is it part of the vision?

2 Likes