[Libvir] PATCH: 1/10: SASL authentication support

[Daniel Veillard]

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