On Thu, Nov 29, 2007 at 05:16:34PM +0000, Daniel P. Berrange wrote:
This patch hooks up the basic authentication RPC calls, and the specific SASL implementation. The SASL impl can be enabled/disable via the configurre script with --without-sasl / --with-sasl - it'll auto-enable it if it finds the headers & libs OK.
The sample /etc/sasl2/libvirt.conf file enables the DIGEST-MD5 mechanism by default, since it is by far the easiest to setup for admins. No need for a Kerberos server, or certificates - it just uses username/password which can be set with 'saslpasswd2 -a libvirt [username]' and a list of all active users viewed with 'sasldblistusers2 -a libvirt'
Hum, shouldn't the spec file then Requires: cyrus-sasl-md5 to make sure this works ?
There are also example settings for enabling Kerberos (GSSAPI) but this is disabled by default. It requires a file /etc/libvirt/krb5.tab containing a service principle. On some distros you need to set KRB5_KTNAME to point to this file when starting the daemon, so our init script does that. Other distros, the 'keytab' config param in /etc/sasl2/libvirt.conf is actually honoured.
With this patch you can successfully authentication client <-> server for any authentication mechansim which doesn't need to prompt the user for credentials. In effect this means it only works for GSSAPI/Kerberos, but the later patches in this series will enable callbacks making the default DIGEST-MD5 auth work.
The way auth is controlled, is that if the 'auth' parameter is set on the struct qemud_client object, *NO* rpc call will be processed except for the REMOTE_PROC_AUTH_LIST, SASL_AUTH_INIT, SASL_AUTH_START & SASL_AUTH_STEP calls. If SASL is not compiled in, the latter 3 will send errors back to the caller.
Only once authentication is complete, are the other calls allowed. It currently hardcodes use of SASL on the TCP socket. The TLS & UNIX sockets are unchanged. A subsequent patch will make it configurable.
[...]
diff -r 1c3780349e89 libvirt.spec.in --- a/libvirt.spec.in Wed Nov 28 12:02:28 2007 -0500 +++ b/libvirt.spec.in Thu Nov 29 09:24:10 2007 -0500 @@ -16,6 +16,8 @@ Requires: dnsmasq Requires: dnsmasq Requires: bridge-utils Requires: iptables +Requires: cyrus-sasl +Requires: cyrus-sasl-gssapi
Requires: cyrus-sasl-md5 ?
BuildRequires: xen-devel BuildRequires: libxml2-devel BuildRequires: readline-devel
[...]
@@ -730,15 +735,28 @@ static struct qemud_server *qemudInitial
virStateInitialize();
+#if HAVE_SASL + if ((err = sasl_server_init(NULL, "libvirt")) != SASL_OK) { + qemudLog(QEMUD_ERR, "Failed to initialize SASL authentication %s", + sasl_errstring(err, NULL, NULL)); + goto cleanup; + } +#endif +
So if libvirt was configured/compiled with SASL but for some reason we fail to initialize SASL we can't start the daemon at all ? Isn't that a bit excessive ? [...]
if (listen_tls) { if (remoteInitializeGnuTLS () < 0) goto cleanup;
- if (remoteListenTCP (server, tls_port, 1) < 0) + if (remoteListenTCP (server, tls_port, 1, REMOTE_AUTH_NONE) < 0) goto cleanup; } }
Looks to me that as long as TLS can still work we should not fail on sasl_server_init error, right ? [...]
@@ -325,6 +356,12 @@ doRemoteOpen (virConnectPtr conn, struct } else port = NULL; /* Port not used for unix, ext. */
+ + priv->hostname = strdup (uri->server ? uri->server : "localhost"); + if (!priv->hostname) { + error (NULL, VIR_ERR_NO_MEMORY, "allocating priv->hostname"); + goto failed; + } if (uri->user) { username = strdup (uri->user); if (!username) goto out_of_memory;
Actually there we should looks for a password and store it, that's very common and convenient, e.g. use xen://foo:bar@server/ as the connection URI, libxml2 will just return the user as 'foo:bar' which could subsequently be split here to store the password (bar). [...] Looks fine to me, +1 Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/