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(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/