[libvirt] [PATCH v7 2/5] conf: Introduce {default|chardev}_tls_x509_secret_uuid

[John Ferlan]

On 09/20/2016 08:52 AM, Daniel P. Berrange wrote:
> On Tue, Sep 20, 2016 at 08:26:55AM -0400, John Ferlan wrote:
>>
>>
>> On 09/19/2016 10:53 AM, Daniel P. Berrange wrote:
>>> On Mon, Sep 19, 2016 at 10:39:21AM -0400, John Ferlan wrote:
>>>> Add a new qemu.conf variables to store the UUID for the secret that could
>>>> be used to present credentials to access the TLS chardev.  Since this will
>>>> be a server level and it's possible to use some sort of default, introduce
>>>> both the default and chardev logic at the same time making the setting of
>>>> the chardev check for it's own value, then if not present checking whether
>>>> the default value had been set.
>>>>
>>>> The chardevTLSx509haveUUID bool will be used as the marker for whether
>>>> the chardevTLSx509secretUUID was successfully read. In the future this
>>>> is how it'd determined whether to add the secret object for a TLS object.
>>>>
>>>> Signed-off-by: John Ferlan <jferlan at redhat.com>
>>>> ---
>>>>  src/qemu/libvirtd_qemu.aug         |  2 ++
>>>>  src/qemu/qemu.conf                 | 24 ++++++++++++++++++++++++
>>>>  src/qemu/qemu_conf.c               | 22 ++++++++++++++++++++++
>>>>  src/qemu/qemu_conf.h               |  3 +++
>>>>  src/qemu/test_libvirtd_qemu.aug.in |  2 ++
>>>>  5 files changed, 53 insertions(+)
>>>>
>>>> diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
>>>> index 988201e..73ebeda 100644
>>>> --- a/src/qemu/libvirtd_qemu.aug
>>>> +++ b/src/qemu/libvirtd_qemu.aug
>>>> @@ -29,6 +29,7 @@ module Libvirtd_qemu =
>>>>     (* Config entry grouped by function - same order as example config *)
>>>>     let default_tls_entry = str_entry "default_tls_x509_cert_dir"
>>>>                   | bool_entry "default_tls_x509_verify"
>>>> +                 | str_entry "default_tls_x509_secret_uuid"
>>>>  
>>>>     let vnc_entry = str_entry "vnc_listen"
>>>>                   | bool_entry "vnc_auto_unix_socket"
>>>> @@ -51,6 +52,7 @@ module Libvirtd_qemu =
>>>>     let chardev_entry = bool_entry "chardev_tls"
>>>>                   | str_entry "chardev_tls_x509_cert_dir"
>>>>                   | bool_entry "chardev_tls_x509_verify"
>>>> +                 | str_entry "chardev_tls_x509_secret_uuid"
>>>>  
>>>>     let nogfx_entry = bool_entry "nographics_allow_host_audio"
>>>>  
>>>> diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
>>>> index e4c2aae..7114fa1 100644
>>>> --- a/src/qemu/qemu.conf
>>>> +++ b/src/qemu/qemu.conf
>>>> @@ -28,6 +28,20 @@
>>>>  #
>>>>  #default_tls_x509_verify = 1
>>>>  
>>>> +#
>>>> +# In order to provide a password to unlock the private key to be used
>>>> +# in order to provide the TLS credentials, a libvirt secret will need
>>>> +# to be created and then the UUID of that secret added as a configuration
>>>> +# parameter. See the libvirt documentation for specific details regarding
>>>> +# how to create a "tls" secret type.
>>>> +#
>>>> +# NB This default all-zeros UUID will not work. Replace it with the
>>>> +# output from the UUID for the TLS secret from a 'virsh secret-list'
>>>> +# command and then uncomment the entry
>>>> +#
>>>> +#default_tls_x509_secret_uuid = "00000000-0000-0000-0000-000000000000"
>>>
>>> We could perhaps be a little more explicit about the fact that when
>>> this is commented out, the private key is required to be in
>>> non-encrypted PEM format.
>>>
>>
>> Fair enough - a simple enough addition, so at the end of the first
>> paragraph (and repeated again for chardev_tls_x509_secret_uuid), how about:
>>
>> " A libvirt secret requires usage of a non-encrypted PEM format
>> certificate."
>>
>> Or is there some other wording that is preferable?
> 
> Something like this:
> 
>   "Libvirt assumes the server-key.pem file is unencrypted by default.
>    To use an encrypted server-key.pem file, the password to decrypt
>    the PEM file is requird. This can be provided by creating a secret
>    object in libvirt and then uncommenting this setting to set the
>    UUID of the secret"
> 

OK - I'll adjust this patch.

In terms of the others are they reasonable or is it more of the case
that the available hours needed to review exceed capacity...

Tks -

John