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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list