We could of course add more insight as to why it is transitional, but I think the word is accurate-- it is transitional because the interface is known to have problems and while we don’t know how to solve them now in the general case, we know it isn’t what we want and in the future we want something better.
For the specific case of x11, it is transitional because the X protocol has many security issues. The future is wayland, but it isn’t ready yet so X isn’t going away anytime soon. Will x11 ever be completely removed? Doubtful (at least not for many years), but we would probably not auto-connect at some point (but that point is not defined).
“monitor mouse/keyboard input and graphics output of other apps” does connecting to X11 interface allows to monitor other apps inputs or disconnecting does? i’m confused because another place in documents says you “should” allow this if it is a GUI app but when i disconnect all GUI apps works also WTF?
I disconnected all of them and my machine become lightweight so i guess answer is there.
@Ebuzer - on any system, connected to the X server allows the application to eavedrop and inject input events. This is a flaw in the design of the X window system. On a system that supports full confinement, when the x11 snapd interface is connected, applications are allowed to connect to the X server and when the interface is disconnected, the applications cannot. The doc for desktop applications still recommends that snaps plug the x11 interface because far too many people still rely on X (though a lot of progress has been made with wayland; someday we’ll be able to deprecate x11, but that won’t be for a while still).
On the system where you disconnected the interface and it still worked, it may have been a system that doesn’t support full strict mode, it was a devmode snap, it was using wayland or mir, or possibly was running and already had the socket open to the X server after the snapd interface was disconnected (though I would expect that application to fail at some point).
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.
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.
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.
The meaning of the ‘autoconnect’ column is unclear to me. For interfaces marked “autoconnect: no”, does this mean:
The interface is not automatically connected by default, but can be auto connected by adding appropriate declarations in the snapcraft.yaml
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.
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:
publisher pushes snap that plugs mount-observe w/o auto-connect from store
user installs the snap, mount-observe is not connected
publisher requests and receives auto-connect, snap declaration in the store is updated
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.
