[libvirt] libvirt: TLS client certificate handling

[Doug Goldstein]

Trying to setup qemu+tls here and I'm running into a few oddities
(well that I feel are oddities) that I wanted clarification on before
I submitted patches. The documentation I am following is:
[1] http://libvirt.org/remote.html#Remote_certificates
[2] http://wiki.libvirt.org/page/TLSSetup
[3] http://wiki.libvirt.org/page/VNCTLSSetup

All my storage is on iSCSI. I have 3 VM servers. 2 which every user
can access and 1 which only a subset of users can access via the
"tls_allowed_dn_list" parameter. Now how I envision this is that each
of the 3 machines have their server certs & client certs in
/etc/pki/libvirt, while each of the clients have their certs in
$HOME/.pki/libvirt. That way a user, who doesn't have root or sudo
access on the machine they are on could access the 2 VM servers they
are allowed to access. However, if you look at the code, the only time
$HOME/.pki/libvirt is used is when getuid() != 0 (this is correct) but
the user either had to not specify a server to connect to and is using
/session or you're auto-probing the local auto-spawned daemon for the
remote URI. Effectively this means my approach can't happen. To
complicate matters further, the documentation tells you to chown the
client cert & key as root:root and set the permissions to 400. Which
effectively means users can never use qemu+tls.

I propose that we change the code for getuid() != 0 to always try
$HOME/.pki/libvirt/ first and then try the system certificate. If
everyone agrees, then I'll submit patches shortly.

Additionally I wanted to note that as per [3], the default path for
libvirt's user keys in $HOME differs from all other applications out
there so I would also make it check
$HOME/.pki/libvirt/private/clientkey.pem as well as
$HOME/.pki/libvirt/clientkey.pem so that we'd match other application
configurations.

-- 
Doug Goldstein