qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [RFC PATCH 0/3] Use FD passing to accept new VNC/chardev cl


From: Daniel P. Berrange
Subject: [Qemu-devel] [RFC PATCH 0/3] Use FD passing to accept new VNC/chardev clients
Date: Thu, 23 Jun 2011 13:31:40 +0100

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]