The rationale is basically the same as last time: the snap acts as the desktop session of the user on an graphical Ubuntu Core system. We’d like X11 application snaps to work out of the box on the system. The suggested snap-declaration should be similar to the existing wayland and desktop slots:
The on-classic: false conditions prevent the slot from being treated as a connection candidate, should someone happen to install the snap on a non-Core system.
The current snap declaration includes a plug-snap-id condition for the slot. That should not be included in the new declaration, since we want to allow other snaps to connect to the slot. I think Alex added that to silence some automated review warnings, while keeping the slot locked down until we asked for a proper declaration.
+2 votes for, 0 votes against, granting use of x11 slot for ubuntu-desktop-session. This is now live.
FYI the previous use of plug-snap-id was there to constrain the slot to only being able to be connected to by this same snap - this was a misconception on my part as I assumed it was to fit the usual use-case for Ubuntu Core where a snap ships Xwayland and would use say mir-kiosk as the Wayland server. So the snap in that case needs to both plug and slot x11 so it can use Xwayland but it should connect its plug to its own slot. Apologies.
For future reference, we didn’t need this kind of self-connection because the base template AppArmor rules allow unrestricted communication over unix domain sockets between processes that are part of the same snap:
Combined with the wayland interface permanent slot rules allowing the snap to create the listening socket, and we don’t need the self-connection to let Xwayland connect to gnome-shell as the wayland compositor. The reverse is also true in the x11 case with gnome-shell connecting to Xwayland to act as a window manager.