Supported interfaces

Subject snaps are in strict confinement as the “info --verbose” output states. When other interfaces disconnected desired effects are visible which i think shows that confinement working also no Mir or Wayland on machine only Xorg installed and active.

it still works after restart.

Does unity7 interface suffers the same X11 interface security flaws? i’m using Xorg as DS and lightdm as DM. My guess is yes since it still uses Xorg as server but i’m curious if there is a security hardening at unity level.

Unity7 is a window manager for X and as such, applications that run under Unity7 must necessarily be able to talk to X, therefore all the same flaws are present. You might be thinking of Unity8 which used Mir instead of X and by design, Mir didn’t suffer from the same issues. At some point, window managers that sit on top of wayland implementations will be widely used and we can drop the reliance on X, ideally leaving the x11 (and unity7) snapd plugs as manually connected for those that need it. We aren’t there yet, but I have every expectation that some day we’ll get there.


until then can snap implement nested X approach or X11 bridge approach at least as an option for security sensitive use cases. X11docker and Subuser doing it for docker containers with help of Xephyr, Xpra … but they are not convenient and stable as snap. It will be great if this was a option for snap it will make snap one stop shop.

Right now i’m using x11docker for experimental wild wild west applications and boy it is painful to do. And snap for applications i was already using for long time and have some trust on them.

1 Like

Is there any interface which allows permission of reading from FIFO file using socat ? One of my applixation suffering from this issue right now and need a fix.

This is being discussed in No read from fifo device in snap packaged app

1 Like

yes this is fixed now :slight_smile:

@degville there’s no docker-support description even though there’s one at The docker-support interface

1 Like

Thanks for flagging this - not sure why I missed it originally, but I’ve put the description in there now.


Please do let me know if you have found the missing part of the puzzle.

The meaning of the ‘autoconnect’ column is unclear to me. For interfaces marked “autoconnect: no”, does this mean:

  1. The interface is not automatically connected by default, but can be auto connected by adding appropriate declarations in the snapcraft.yaml

  2. The interface cannot be made to autoconnect by adding declarations in the snapcraft.yaml. The only way to connect it is for users to explicitly run ‘snap connect’ commands.

Thanks for flagging this, and I can see what you mean. All interfaces used by a snap need to be added to a snap’s snapcraft.yaml, regardless of whether they’ll be connected automatically to the system after they’ve been installed by the user. Then:

This is from the text above the table. But I can see that this isn’t 100% clear - it’s also possible for a snap developer to request permission for their snap to auto-connect an interface that wouldn’t ordinarily auto-connect. I’ll update the text at the top to explain this.


This page explains how to add interfaces to your snapcraft.yaml:

1 Like

Can we adjust this section to indicate that a snap that was already installed before a snap was granted auto-connect for some interface (i.e. mount-observe), will be updated to use the new auto-connection when that is granted as per store processes? I.e. this is the expected workflow:

  1. publisher pushes snap that plugs mount-observe w/o auto-connect from store
  2. user installs the snap, mount-observe is not connected
  3. publisher requests and receives auto-connect, snap declaration in the store is updated
  4. at some point in the future, snapd downloads the new snap declaration for the snap and applies the new auto-connect.

There was some confusion from others about this point and I’m not sure how to succinctly summarize this point.

1 Like

Yes, absolutely. I’ll work on something and add it to the doc. Thanks for flagging this!


This page suggests that the pulseaudio interface does not auto-connect, but my experience was that it did. Has this changed?


1 Like

If your snap previously used pulseaudio when it was automatically auto-connected, then it will continue to do so, but new snaps will not get auto-connection of pulseaudio.


I answered this question over here: Electron Audio on Ubuntu Core. What is listed on this page is mostly about implicit slots or expected auto-connections for app-provided slots. The pulseaudio snap predates the audio-* interfaces and still allows auto-connecting to it. If/when it is updated, we can update its snap declaration to match the above.

1 Like

Thank you very much for explaining.

Might it be useful to add a note to explain this documentation only applies to Classic? I assumed from reading it that it applied to all operating systems equally.