[Ovirt-devel] oVirt console
Daniel P. Berrange
berrange at redhat.com
Fri Aug 1 13:15:00 UTC 2008
On Fri, Aug 01, 2008 at 01:57:27PM +0100, Richard W.M. Jones wrote:
> As some background, Hugh Brock asked me to look at how much work it
> would be to add console access to guests from the oVirt WUI, properly
> authenticated and encrypted and -- this is the key -- supporting
> Windows users.
> I previously wrote a VNC browser plugin based around the open source
> gtk-vnc[i] and virt-viewer[ii] projects. This hasn't worked out well
> because, for reasons which are elusive, the browser plugin makes the
> whole browser somewhat unstable. And in any case it looks like the
> plugin would be limited to Firefox on Linux.
> My feeling is that instead of embedding the console in the browser,
> with all the potential complexity and unstableness involved in that,
> instead we should have a very small browser plugin which launches a
> separate virt-viewer process. This way, the browser plugin should be
> very small and short-lived (so won't affect the stability of the
> browser), should be easy to port, and all the open consoles will be
> running as separate virt-viewer processes so again there is a benefit
> of separation & stability.
> To achieve this, we need the following steps:
> (1) SASL support the VNC protocol:
> (a) Register one or two new VNC protocol extensions for, respectively,
> authentication & encryption using SASL.
Only one extension is required. You negotiate encryption as part of the
SASL authentication handshake. Basically if we're using SASL on the TLS
encrypted channel then you set a min&max SSF of 0 (SSF = Security Strength
Factor), and if not using TLS then set a min SSF of 56 (good enough to
require Kerberos) and max of 100000 (or a suitably large number). This
ensures that SASL encryption will be negotiated if the underlying channel
isn't already using strong encryption.
> (b) Implement server-side protocols in upstream QEMU. This will
> eventually lead to it being supported in projects that synch
> with QEMU, ie. KVM.
The bulk of the server side stuff for libvirt is in the qemud/remote.c
file, remoteDispatchAuthSasl(Init,Start,Step). This handles all the
auth side of things. If you negotiate a SSF layer, then you also need
to wire in calls to sasl_encode, sasl_decode in the part where you
read/write data on the wire.
> (c) Implement client-side protocols in gtk-vnc.
Similarly the client side stuff in libvirt is in src/remote_internal.c
in the remoteAuthSASL() method which takes care of all client auth.
Again, we wire in sasl_encode/decode where needed for SSF.
Gathering client credentials is a hairy bit - the virConnectCredential,
virConnectAuth and virConnectAuthCallbackPtr structs/function define
the public contract to expose to apps. If we use a similar contract
for credentials in GTK-VNC, then it'll make the virt-viewer integration
easier because it already has to deal this for libvirt auth credentials.
Getting it working with Kerberos first is actually eaiser than getting it
working with username/password, because with Kerberos you don't have to
debug the callback stuff - it just uses the keytab.
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
More information about the ovirt-devel