An additional description/summary column would be helpful, which gives packagers a clue what an interface does without dive into its page.
Shouldn’t every user uses the latest release of snapd? A “(not yet released)” notice in the interface name field should suffice…?
I think this is a good idea. It may take some work getting something small enough to not make the table confusing, but I’ll work on it as I go through the separate pages for each interface.
The interface specific page is fine IMO.
FYI, @mpt went through this exercise with the descriptions that gnome-software exposes.
With help from @jdstrand and others, I got as far as user-facing descriptions for 127 of 208 interfaces.
Thank you! That’s going to be really useful.
An interface page template would be helpful. Also, the underlying topics should all be converted into wiki.
The template is currently very simple:
Attributes: if any
Transitional: only if yes
Requires snapd version foo.bar+.
And yes, I’m making them wiki when I remember to!
A Linux Kconfig style of connection hint is also helpful:
If <condition>, then connect; if in doubt, don't connect etc.
UPDATE: Refer the The unity7 interface topic for a reference design.
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).
Here is an article with some insights: mjg59 | Circumventing Ubuntu Snap confinement
Warning: Potentially offensive/biased opinion included.
What I’m missing on this page is an explanation of how to make your snap use these interfaces. (adding the interface as a
plug to your
“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.
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.