Interfaces


#1

Introduction

Interfaces allow snaps to communicate or share resources according to the protocol established by the interface.

Each connection has two ends, a “plug” (consumer) and a “slot” (provider). A plug and a slot can be connected if they use the same interface name. The connection grants necessary permissions for snaps to operate according to the protocol.

Slots may support multiple connections to plugs. For example the core snap exposes the network slot and all applications that can talk over the network connect their plugs there.

The availability of an interface depends on a number of factors and may be provided by the core snap or via snaps providing the slot. The available interfaces on a given system can be seen with snap interfaces.

Transitional interfaces

Most interfaces are designed for strong application isolation and user control such that auto-connected interfaces are considered safe and users choose what applications to trust and to what extent via manually connected interfaces.

Some interfaces are considered transitional to support traditional Linux desktop environments and these transitional interfaces typically are auto-connected. Since many of the underlying technologies in these environments were not designed with strong application isolation in mind, users should only install applications using these interfaces from trusted sources. Transitional
interfaces will be deprecated as replacement or modified technologies that enforce strong application isolation are available.

Making connections

Interfaces may either be auto-connected on install or manually connected after install.

To list the available connectable interfaces and connections:

$ snap interfaces

To make a connection:

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

To disconnect snaps:

$ snap disconnect <snap>:<plug interface> <snap>:<slot interface>

Consider a snap foo that uses plugs: [ log-observe ]. Since log-observe is not auto-connected, foo will not have access to the interface upon install:

$ sudo snap install foo
$ snap interfaces
Slot                 Plug
:log-observe         -
-                    foo:log-observe

You may manually connect using snap connect:

$ sudo snap connect foo:log-observe core:log-observe
$ snap interfaces
Slot                 Plug
:log-observe         foo:log-observe

and disconnect using snap disconnect:

$ sudo snap disconnect foo:log-observe core:log-observe
$ snap interfaces # shows they are disconnected
Slot                 Plug
:log-observe         -
-                    foo:log-observe

On the other hand, bar could use plugs: [ network ] and since network is auto-connected, bar has access to the interface upon install:

$ sudo snap install bar
$ snap interfaces
Slot                 Plug
:network             bar:network

You may disconnect an auto-connected interface:

$ sudo snap disconnect bar:network core:network
$ snap interfaces
Slot                 Plug
:network             -
-                    bar:network

Whether the slot is provided by the core snap or not doesn’t matter in terms of snap interfaces except that if the slot is provided by a snap, a snap that implements the slot must be installed for it to be connectable. Eg, the bluez interface is not provided by the core snap so a snap author
implementing the bluez service might use slots: [ bluez ]. Then after install, the bluez interface shows up as available:

$ sudo snap install foo-blue
$ snap interfaces
Slot                 Plug
foo-blue:bluez       -

Now install and connect works like before (eg, baz uses plugs: [ bluez ]):

$ sudo snap install baz
$ snap interfaces
Slot                 Plug
foo-blue:bluez       -
-                    baz:bluez
$ sudo snap connect baz:bluez foo-blue:bluez
$ snap interfaces
Slot                 Plug
foo-blue:bluez       baz:bluez

Supported Interfaces - Basic

account-control

Can add users and change password. Suitable for administration tools.

  • Auto-Connect: no

camera

Can access all video cameras. Suitable for programs wanting to use webcams.

  • Auto-Connect: no

dbus

Providing snaps implementing a DBus API may be accessed via their well-known DBus connection name (2.20+).

  • Auto-Connect: no
  • Attributes:
    • name (slot): well-known DBus connection name for the service (eg, org.foo.bar)
    • bus (slot): DBus bus to use (ie, session or system)
    • name (plug): well-known DBus connection name of the service from the providing snap
    • bus (plug): DBus bus to use for providing snap

Snaps that want to communicate via a well-known DBus connection name need to have matching bus and name attributes and then be connected via snap connect. Snaps specifying bus: system will have a default DBus bus policy that allows root to own the name and anyone to send to a destination that matches the well-known name (eg, org.foo.bar). Once connected, the consuming snap may communicate with the providing snap via:

  • the specified well-known DBus connection name (eg, org.foo.bar)
  • a unique DBus connection name using a matching DBus interface (eg, org.foo.bar.baz) or DBus path (eg, /org/foo/bar/norf)

This interface is particularly well-suited for leaf-style applications from GNOME, KDE, etc to integrate into the desktop session. Future versions of snapd may allow greater flexibility for bus policy, DBus interfaces and DBus paths and also support session services and DBus
activation.

Note: when developing snaps using devmode for DBus system services, the slot implementation must use this interface so that snapd may adjust the DBus bus policy so the snap may use the system bus.

desktop

Can access basic desktop graphical resources (2.28+). This interface is designed to be used with other interfaces, such as wayland.

  • Auto-Connect: yes

desktop-legacy

Can access desktop legacy methods such as a11y and input methods which gives privileged access to sensitive information and does not prevent eavesdropping or apps interfering with each other (2.28+).

  • Auto-Connect: yes
  • Transitional: yes

gsettings

Can access global gsettings of the user’s session which gives privileged access to sensitive information stored in gsettings and allows adjusting settings of other applications.

  • Auto-Connect: yes
  • Transitional: yes

home

Can access non-hidden files in user’s $HOME and gvfs mounted directories owned by the user to read/write/lock.

  • Auto-Connect: yes on classic (traditional distributions), no otherwise
  • Transitional: yes
  • Attributes:
    • read (plug): optional, when set to ‘all’ allow reading non-hidden files
      in home directories of all users as traditional file permissions allow.
      (2.33+)

mpris

Providing snaps implementing the Media Player Remote Interfacing Specification (mpris) may be accessed via their well-known DBus name.

Consuming snaps can access media players implementing mpris via the providing snap’s well-known DBus name.

  • Auto-Connect: no
  • Attributes:
    • name (slot): optional, media player name to use for DBus well-known name
      (ie, org.mpris.MediaPlayer2.$name). If omitted, use the snap’s name.

network

Can access the network as a client.

  • Auto-Connect: yes

network-bind

Can access the network as a server.

  • Auto-Connect: yes

opengl

Can access OpenGL hardware.

  • Auto-Connect: yes

optical-drive

Can access the first optical drive. Suitable for CD/DVD playback (write added in (2.33+).

  • Auto-Connect: by default, yes; when write: true, no
  • Attributes:
    • write: true|false (defaults to false)

password-manager-service

Can access global password manager services provided by popular Desktop Environment (eg, Secret Service and KWallets) which gives privileged access to sensitive information stored in the user’s session (2.27+).

  • Auto-Connect: no
  • Transitional: yes

pulseaudio

Can access the PulseAudio sound server which allows for sound playback and recording.

  • Auto-Connect: yes

removable-media

Can access files from removable media in /media and /run/media. This can be used to give an app access to mounted USB sticks and external hard drives on a desktop.

  • Auto-Connect: no

screen-inhibit-control

Can access desktop session manager screen inhibit and uninhibit functionality.

  • Auto-Connect: yes

shutdown

Can control the system power state and rebooting, powering off or halting the system.

  • Auto-Connect: no

unity7

Can access Unity7. Unity 7 runs on X and requires access to various DBus services(including but not limited to, global appmenu support). This interface grants privileged access to the user’s session since the Unity 7 environment does not prevent eavesdropping or apps interfering with one another.

  • Auto-Connect: yes
  • Transitional: yes

wayland

Can access compositors providing the wayland protocol (2.28+).

  • Auto-Connect: yes

x11

Can access snaps providing the X server which typically gives privileged access to the user’s session since X does not prevent eavesdropping or apps interfering with one another.

  • Auto-Connect: yes
  • Transitional: yes

Supported Interfaces - Advanced

account-control

Can create and delete non-system extra users and change the password for non-system extra users (2.22+).

  • Auto-Connect: no

alsa

Can directly access ALSA devices in /dev/snd.

  • Auto-Connect: no

autopilot-introspection

Can be introspected by autopilot (2.24+).

  • Auto-Connect: no

avahi-control

Can access and control snaps providing Avahi mDNS/DNS-SD services on the network which gives privileged access to the service (2.28+).

  • Auto-Connect: no

avahi-observe

Can access snaps providing Avahi to browse for mDNS/DNS-SD services on the network.

  • Auto-Connect: no

bluetooth-control

Allow to manage the kernel side Bluetooth stack.

  • Auto-Connect: no

bluez

Can access snaps providing the bluez interface which gives privileged access to bluetooth.

  • Auto-Connect: no

broadcom-asic-control

Can access broadcom-asic devices and sysfs interfaces (2.28+).

  • Auto-Connect: no

browser-support

Can access files and IPC needed by modern browsers. This interface is intended to be used when using an embedded Chromium Content API or using the sandboxes in major browsers from vendors like Google and Mozilla. The allow-sandbox attribute may be used to give the necessary access to use the browser’s sandbox functionality.

  • Auto-Connect: no when allow-sandbox: true, yes otherwise
  • Attributes:
    • allow-sandbox: true|false (defaults to false)

Note: for webapps that use electron or Oxide, it is often useful to disable the internal sandbox and rely on strict confinement so that the snap uses allow-sandbox: false. To do this:

  • for electron, specify --no-sandbox on the command line for your app
  • for Oxide webviews, export OXIDE_NO_SANDBOX=1

calendar-service

Can access Evolution Data Service Calendar (2.34+).

  • Auto-Connect: no

can-bus

Can access the CAN bus (2.34+).

  • Auto-Connect: no

cifs-mount

Can mount network CIFS volumes (2.36+).

  • Auto-Connect: no

classic-support

Allows resources necessary for running as classic dimension snap which gives device ownership to the snap. This interface is reserved for the classic snap (2.23).

Auto-Connect: no

contacts-service

Can access Evolution Data Service Contacts (2.34+).

  • Auto-Connect: no

content

Can access content from the providing snap from within the consuming snap’s filesystem area.

Consult dedicated page about the content interface

  • Auto-Connect: yes for snaps from same publisher, no otherwise
  • Attributes:
    • read (slot): read-only paths from providing snap to expose to the consuming snap
    • write (slot): read-write paths from providing snap to expose to the consuming snap
    • content (slot): reference to plug side of connection. Defaults to local slot name
    • default-provider (plug): name and slot of preferred providing snap (<SNAP>:<SLOT>)
    • target (plug): path in consuming snap to find providing snap’s files
    • content (plug): reference to slot side of connection. Defaults to local plug name

Read, write and target can start with either $SNAP, $SNAP_DATA or $SNAP_COMMON to refer to the designated directory. The content attribute specified of the consuming snap (plug) must have a content attribute match in the providing snap (slot).

core-support (deprecated in 2.34+)

Can control all aspects of systemd via the systemctl command, update rsyslog configuration, update systemd-timesyncd configuration and update/apply sysctl configuration which gives privileged access to the system (2.22+). Reserved for core snaps (type: os).

  • Auto-Connect: no

cpu-control

Can set certain CPU tunables (2.35+).

  • Auto-Connect: no

cups-control

Can access cups control socket which gives privileged access to configure printing.

  • Auto-Connect: no

daemon-notify

Can access service manager for sending status changes (2.33+).

  • Auto-Connect: no

dcdbas-control

Can interact with the Dell Systems Management Base Driver which provides a sysfs interface for systems management software such as Dell OpenManage to perform system management interrupts and host control actions (system power cycle or power off after OS shutdown) on certain Dell systems.

  • Auto-Connect: no

docker

Can access snaps providing the docker interface which gives privileged access to the system.

  • Auto-Connect: no

docker-support

Can access resources and syscalls necessary to run Docker application containers. The privileged-containers attribute may be used to give the necessary access to run privileged containers. Providing snaps specifying this interface currently may only be established with the Docker project.

  • Auto-Connect: no
  • Attributes:
    • privileged-containers (plug): true|false (defaults to false)

dvb

Can use all DVB (Digital Video Broadcasting) devices and APIs (2.34+).

  • Auto-Connect: no

firewall-control

Can configure network firewalling giving privileged access to networking.

  • Auto-Connect: no

framebuffer

Can use the universal framebuffer (/dev/fb[0-9]*, (2.22+)).

  • Auto-Connect: no

fuse-support

Can mount fuse filesystems (as root only).

  • Auto-Connect: no

fwupd

Can access snaps providing the fwupd interface which gives privileged access to update UEFI capsule format firmware.

  • Auto-Connect: no

gpg-keys

Can read GnuPG user configuration, public and private keys (2.31+).

  • Auto-Connect: no

gpg-public-keys

Can read GnuPG non-sensitive user configuration and public keys (2.31+).

  • Auto-Connect: no

gpio

Can access GPIO devices. This is restricted because it provides privileged access to GPIO hardware.

  • Auto-Connect: no

  • Attributes:

    • number (slot): GPIO pin number to export and expose to consuming snaps

Snaps that want to consume a gpio device simply plugs: [ gpio ] and the gpio device to connect is specified during interface connection. Available gpio devices for the system can be seen with snap interfaces. Once connected, the consuming snap can use the device via /sys/class/gpio/gpioN where N is the pin number specified by the connected slot.

gpio-memory-control

Can access all GPIO memory via /dev/gpiomem. This is restricted because it provides privileged access to all GPIO devices (2.31+)…

  • Auto-Connect: no

greengrass-support

Can access resources and syscalls necessary to run Amazon Greengrass services and lambda functions. Providing snaps specifying this interface currently may only be established with the Amazon Greengrass project
(2.26+).

  • Auto-Connect: no

hardware-observe

Can query hardware information from the system.

  • Auto-Connect: no

hardware-random-control

Allow read/write access to /dev/hwrng (2.25+).

  • Auto-Connect: no

hardware-random-observe

Allow read access to /dev/hwrng (2.25+).

  • Auto-Connect: no

hidraw

Can access hidraw devices. This is restricted because it provides privileged access to hardware devices.

  • Auto-Connect: no

  • Attributes:

    Should specify a single path attribute:

    • path (slot): path to hidraw device node e.g. /dev/hidraw0

    Or three attributes:

    • usb-vendor (slot): integer representing the USB Vendor ID, must be in range
      0 < vid <= 65535
    • usb-product (slot): integer representing the USB Product ID, must be in range
      0 <= vid <= 65535
    • path (slot): path where a symlink will be created to the device
      e.g. /dev/hidraw-mydevice

Snaps that want to consume a hidraw device simply plugs: [ hidraw ] and the hidraw device to connect is specified during interface connection. Available hidraw devices for the system can be seen with snap interfaces. Once connected, the consuming snap can use the device via the path specified by the connected slot.

hostname-control

Can configure system hostname (2.33+).

  • Auto-Connect: no

i2c

Can access i2c devices. This is restricted because it provides privileged access to hardware devices.

  • Auto-Connect: no

  • Attributes:

    • path (slot): path to i2c device node e.g. /dev/i2c-0

Snaps that want to consume an i2c device simply plugs: [ i2c ] and the i2c device to connect is specified during interface connection. Available i2c devices for the system can be seen with snap interfaces. Once connected, the consuming snap can use the device via the path specified by the connected slot.

iio

Can access IIO devices. This is restricted because it provides privileged
access to IIO hardware (2.20+).

  • Auto-Connect: no

  • Attributes:

    • path (slot): path to IIO device node e.g. /dev/iio:device0

Snaps that want to consume an IIO device simply plugs: [ iio ] and the IIO device to connect is specified during interface connection. Available IIO devices for the system can be seen with snap interfaces. Once connected, the consuming snap can use the device via the path specified by the connected slot.

io-ports-control

Can write to /dev/port to change the I/O port permissions and privilege level of the calling process and disable interrupts (2.21+).

  • Auto-Connect: no

joystick

Can access /dev/input/js* (2.24+) and /dev/input/event* (2.33) devices that are udev marked with ID_INPUT_JOYSTICK=1.

  • Auto-Connect: no

juju-client-observe

Can access the user’s $HOME/.local/share/juju (2.33+).

  • Auto-Connect: no

kernel-module-control

Can insert kernel modules. This interface gives privileged access to the device.

  • Auto-Connect: no

kubernetes-support

Can access resources and syscalls necessary to operate as the Kubernetes service and run application containers (2.25+).

  • Auto-Connect: no

kvm

Can access /dev/kvm which gives privileged access to the kvm hypervisor (2.28+).

  • Auto-Connect: no

libvirt

Can access the libvirt control socket, which gives privileged access to control libvirtd on the host. This is commonly used to create and manage QEMU/KVM instances on the host.

  • Auto-Connect: no

locale-control

Can manage locales directly separate from config core.

  • Auto-Connect: no

location-control

Can access snaps providing the location-control interface which gives privileged access to configure, observe and use location services.

  • Auto-Connect: no

location-observe

Can access snaps providing the location-observe interface which gives privileged access to query location services.

  • Auto-Connect: no

log-observe

Can read system logs and set kernel log rate-limiting.

  • Auto-Connect: no

lxd

Can use the LXD API via the socket provided by the “lxd” snap. LXD_DIR must be set to /var/snap/lxd/common/lxd. This interface requires manual connection.

  • Auto-Connect: no

lxd-support

Can access all resources and syscalls on the device for LXD to mediate access for its containers. This interface currently may only be established with the upstream LXD project.

  • Auto-Connect: no
  • Transitional: yes

maliit

Can access snaps providing the maliit input interface (2.24+).

  • Auto-Connect: no

media-hub

Can access snaps providing the media-hub interface (2.25+).

  • Auto-Connect: yes

mir

Can access snaps providing the mir display server interface.

  • Auto-Connect: yes

modem-manager

Can access snaps providing the modem-manager interface which gives privileged access to configure, observe and use modems.

  • Auto-Connect: no

mount-observe

Can query system mount information. This is restricted because it gives privileged read access to mount arguments and should only be used with trusted apps.

  • Auto-Connect: no

netlink-audit

Can communicate via NETLINK_AUDIT (2.26+).

  • Auto-Connect: no

netlink-connector

Can communicate via NETLINK_CONNECTOR (2.26+).

  • Auto-Connect: no

network-control

Can configure networking and network namespaces via ip netns (2.20+) which gives wide, privileged access to networking.

  • Auto-Connect: no

network-manager

Can access snaps providing the network-manager interface which gives privileged access to configure and observe networking.

  • Auto-Connect: no

network-observe

Can query network status information which gives privileged read-only access to networking information.

  • Auto-Connect: no

network-setup-control

Can read/write network setup configuration files. This is restricted because it gives access to system network configuration which can container network security details (2.22+).

  • Auto-Connect: no

network-setup-observe

Can read network setup configuration files. This is restricted because it gives access to system network configuration which can contain network security details.

  • Auto-Connect: no

network-status

Can access snaps providing the NetworkingStatus interface (2.25+).

  • Auto-Connect: yes

ofono

Can access snaps providing the ofono interface which gives privileged access to configure, observe and use ofono devices.

  • Auto-Connect: no

online-accounts-service

Can access snaps providing the Online Accounts Service interface (2.25+).

  • Auto-Connect: yes

openvswitch

Can access the openvswitch control socket, which gives privileged access to control openvswitch on the host (2.20+).

  • Auto-Connect: no

openvswitch-support

Enables kernel support for openvswitch (2.20+).

  • Auto-Connect: no

physical-memory-control

Can write to /dev/mem to access architecture-specific subset of the physical address space for common use cases (eg, X without KMS, dosbox, etc) when kernels are compiled with STRICT_DEVMEM=y (required for certified kernels). With STRICT_DEVMEM=n, can write to all physical memory (2.21+).

  • Auto-Connect: no

physical-memory-observe

Can read from /dev/mem to access architecture-specific subset of the physical address space for common use cases (eg, X without KMS, dosbox, etc) when kernels are compiled with STRICT_DEVMEM=y (required for certified kernels). With STRICT_DEVMEM=n, can read from all physical memory (2.21+).

  • Auto-Connect: no

ppp

Can access Point-to-Point protocol daemon which gives privileged access to configure and observe PPP networking.

  • Auto-Connect: no

process-control

Can manage processes via signals and nice.

  • Auto-Connect: no

raw-usb

Can directly access connected USB devices via a raw interface (2.18+).

  • Auto-Connect: no

screencast-legacy

Can perform screen recording and audio recording via legacy desktop environment APIS which also allows writing to arbitrary filesystem paths (2.36+).

  • Auto-Connect: no
  • Transitional: yes

serial-port

Can access serial ports. This is restricted because it provides privileged access to configure serial port hardware. Note that the slot is meant to be implemented by a gadget snap (this is not provided by the core snap).

  • Auto-Connect: no

  • Attributes:

    Should specify a single path attribute:

    • path (slot): path to serial device node e.g. /dev/ttyS1

    Or three attributes:

    • usb-vendor (slot): integer representing the USB Vendor ID, must be in range
      0 < vid <= 65535
    • usb-product (slot): integer representing the USB Product ID, must be in range
      0 <= vid <= 65535
    • path (slot): path where a symlink will be created to the device
      e.g. /dev/serial-port-mydevice

Snaps that want to consume a serial port simply plugs: [ serial-port ] and the serial port to connect is specified during interface connection. Available serial ports for the system can be seen with snap interfaces. Once connected, the consuming snap can use the device via the path specified by the connected slot.

snapd-control

Can manage snaps via snapd.

  • Auto-Connect: no

spi

Can access SPI devices. This is restricted because it provides privileged access to SPI hardware (2.28+).

  • Auto-Connect: no

  • Attributes:

    • path (slot): path to SPI device node e.g. /dev/spidev0.0

Snaps that want to consume an SPI device simply plugs: [ spi ] and the SPI device to connect is specified during interface connection. Available SPI devices for the system can be seen with snap interfaces. Once connected, the consuming snap can use the device via the path specified by the connected slot.

ssh-keys

Can read SSH user configuration, public and private keys (2.31+).

  • Auto-Connect: no

ssh-public-keys

Can read SSH non-sensitive user configuration and public keys (2.31+).

  • Auto-Connect: no

storage-framework-service

Can access snaps providing the Storage Framework Service interface (2.25+).

  • Auto-Connect: no

system-observe

Can query system status information which gives privileged read access to all processes on the system.

  • Auto-Connect: no

system-trace

Can use kernel tracing facilities. This is restricted because it gives privileged access to all processes on the system and should only be used with trusted apps.

  • Auto-Connect: no

thumbnailer-service

Can access snaps providing the thumbnailer service interface (2.22+).

  • Auto-Connect: no

time-control

Can set system time and date and query systemd-timedated for time information.

  • Auto-Connect: no

timeserver-control

Can manage timeservers via systemd-timedated and directly separate from config core

  • Auto-Connect: no

timezone-control

Can manage timezone via systemd-timedated and directly separate from config core

  • Auto-Connect: no

tpm

Can access the tpm device /dev/tpm0.

  • Auto-Connect: no

ubuntu-download-manager

Can access snaps providing the ubuntu-download-manager interface.

  • Auto-Connect: yes

udisks2

Can access snaps providing the udisks2 interface which gives privileged access to storage on the device

  • Auto-Connect: no

uhid

Can access /dev/uhid to create kernel hid devices from user-space which gives privileged access to HID transport drivers.

  • Auto-Connect: no

unity8

Can access Unity8 (2.22+). This interface is in active development and should not yet be used in production and its use is therefore restricted.

  • Auto-Connect: yes

unity8-calendar

Can access snaps providing the Unity8 calendar interface which gives access to the Unity8 global calendar.

  • Auto-Connect: no

unity8-contacts

Can access snaps providing the Unity8 contacts interface which gives access to the Unity8 global contacts list.

  • Auto-Connect: no

upower-observe

Can access snaps providing the UPower interface for power devices, history and statistics.

  • Auto-Connect: yes

Adding OpenGL/GPU support to a snap
Home folder folder permissions
Gtk-Message: Failed to load module "appmenu-gtk-module"
Command line utility needs read access to file in current dir
Minecraft launcher crashed in Debian
Permission denied when trying to access user files
Using in-development features in `snapcraft.yaml`
Pulseaudio recording
Home folder folder permissions
Manual Review Requested - hub (classic confinement)
Snapcraft.yaml reference
Security policy and sandboxing
#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).


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


/usr/bin/fold got permission denied but /usr/bin/fmt is working fine. What's happened?
#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.

https://netplan.io/

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.


#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 !!"

#12

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