The VNC server in QEMU can be configured using either TCP or UNIX sockets. Historically, libvirt apps have configured VNC using TCP, but restricted to localhost (127.0.0.1) by default. This allows apps like virt-manager to connect, while not exposing it to the outside world by default. The downside, is that in fact any local user on the host can connect. This is undesirable for many types of deployment.
The alternative option would be to configured QEMU to use a well known UNIX socket by default. While this works fine if QEMU is running as the same UID/GID as the local user desiring access to VNC, it isn't so great if the client is a different UID to QEMU, since it won't be able to access the UNIX socket. One option would be to make the UNIX socket world accessible and then integrate QEMU with policykit directly to grant access to selected local users. This would in fact work, but some users have rightfully pointed out that if they already have a connection to libvirt they should be able to connect to QEMU VNC without needing to authenticate further. This last issue can be solved by making use of FD passing over UNIX domain sockets. The application desiring access to the VNC server has a connection to libvirt. The create an anoymous unbound UNIX socketpair, and pass one of the FDs to libvirtd using a new libvirt API. libvirtd (optionally) checks they are allowed for the specific VM in question, and if so, issues a QEMU monitor command, passing the socketpair FD onto QEMU. The client app now has a direct connection to the QEMU VNC server. With this functionality the typical deployment configuration would be to setup QEMU to run on a well known UNIX socket by default. If the app can access this socket then they can use it directly, otherwise if they have sufficient authorization via libvirt, they can indirectly connect to VNC using this new FD passing. This patch series is not intended for merging right now. It is just a proof of concept I'm sending in case anyone else was looking for something like this. It supports - Passing an FD to connect to VNC (tested) - Passing an FD to connect to any chardev configured with a socket backend (not tested yet) Not currently wired up, but desired before proposing for merging: - Passing an FD to connect to SPICE