Re: [Xen-devel] PATCH: 3/4: Add VNC auth support from upstream QEMU - Daniel P. Berrange - com.xensource.lists.xen-devel

7 messages in com.xensource.lists.xen-develRe: [Xen-devel] PATCH: 3/4: Add VNC a...

From	Sent On	Attachments
Daniel P. Berrange	29 Oct 2007 14:48
Daniel P. Berrange	29 Oct 2007 14:50
Daniel P. Berrange	29 Oct 2007 14:51
Daniel P. Berrange	29 Oct 2007 14:52
Daniel P. Berrange	29 Oct 2007 14:53
Pasi Kärkkäinen	30 Oct 2007 00:53
Daniel P. Berrange	30 Oct 2007 06:31

Subject:	Re: [Xen-devel] PATCH: 3/4: Add VNC auth support from upstream QEMU
From:	Daniel P. Berrange (berr...@redhat.com)
Date:	10/30/2007 06:31:00 AM
List:	com.xensource.lists.xen-devel

On Tue, Oct 30, 2007 at 09:53:59AM +0200, Pasi K?rkk?inen wrote:

On Mon, Oct 29, 2007 at 09:52:47PM +0000, Daniel P. Berrange wrote:

This patch adds in the upstream QEMU VNC authentication code. This spports the
previous VNC password auth scheme, as well as the VeNCrypt protocol extenion. The latter
allows for performing a TLS handshake, and client verification of the server identify
using x509 certificates. It is also possible for the server to request a client
certificate and validate that as a simple auth scheme. The code depends on GNU TLS for SSL
APIs, and the configure script will auto-detect this.

Might be a stupid question as I don't know what upstream QEMU VNC supports, but would it make sense to add user+pass authentication support (via pam) ?

This does not make much if any sense. There is no sensible mapping between host user accounts & guest virtual machine console access. If one were to add any further authentication to VNC, then it should be SASL based.

UltraVNC supports this, at least against Windows/AD users.

That makes sense for UltraVNC because it is exposing the Windows desktop sessions for users. It does not make sense for QEMU because we're not exposing any sessions associated with host users.

Dan.