FYI, I looked into this a bit more and with the symlink trick we can make the client find the wayland server (and also the systemd user session bus at /run/user/<uid>/bus), but part of the protocol is for the client to create another socket for wayland to use. Because XDG_RUNTIME_DIR is set to a snap-specific directory, that socket is put in /run/user/<uid>/snap.$SNAP_NAME when it should be alongside the wayland server socket. The filename for this socket is unpredictable (eg, weston-shared-XXXXXX) so the symlink trick won’t work.
In short, there seem to be 3 things that need to be in the same XDG_RUNTIME_DIR:
- the wayland server socket (eg, /run/user/1000/wayland-0)
- the systemd user session bus (ie, /run/user/1000/bus)
- the client socket for wayland (eg, /run/user/1000/weston-shared-XXXXXX)
we run into problems if some are in the normal XDG_RUNTIME_DIR and some in the snap-specific XDG_RUNTIME_DIR/snap.$SNAP_NAME.
@niemeyer - I’d like to better understand your comment. If we bind mount the entire
/run/user/$(id -u) into the snap and relying on apparmor for the access control, that isn’t really different (from a security perspective) from just using apparmor with no bind mounts and not setting XDG_RUNTIME_DIR to something snap specific. There are limitations to this approach-- we want snap-specific dconf databases and we’d really like the client sockets (weston-shared-XXXXXX) to be isolated (the apparmor rule atm must be weston-shared-*).
The approach outlined by upstream dconf works for these cases, but it also means we’ll want to bind mount a bunch of other stuff (eg, pulse?, perhaps gnome-shell?, etc). What else needs to be bind mounted needs investigation (perhaps the Desktop team can help?).