[libvirt] [PATCH v2] qemu: Check for existence of provided *_tls_x509_cert_dir

John Ferlan jferlan at redhat.com
Wed Jul 19 20:02:59 UTC 2017



On 07/19/2017 09:56 AM, Ján Tomko wrote:
> On Thu, Jun 29, 2017 at 10:32:35AM -0400, John Ferlan wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1458630
>>
>> Introduce virQEMUDriverConfigSetCertDir which will handle reading the
>> qemu.conf config file specific setting for default, vnc, spice, chardev,
>> and migrate. If a setting is provided, then validate the existence of the
>> directory and overwrite the default set by virQEMUDriverConfigNew.
>>
>> Update the qemu.conf description for default to describe the consequences
>> if the default directory path does not exist and as well as the
>> descriptions
>> for each of the *_tls_x509_cert_dir entries.
>>
>> Signed-off-by: John Ferlan <jferlan at redhat.com>
>> ---
>>
>> v1: https://www.redhat.com/archives/libvir-list/2017-June/msg01278.html
>>
>> - Dropped the former 1/2 patch
>>
>> - Alter the logic of virQEMUDriverConfigSetCertDir to fail instead of
>>  VIR_INFO if an uncommented entry for one of the *_tls_x509_cert_dir
>>  has a path that does not exist. This will cause a libvirtd startup
>>  failure as opposed to the previous logic which would have failed only
>>  when a domain using TLS was started.
>>
>> - Alter the description for each of the values to more accurately
>> describe
>>  what happens.
>>
>> src/qemu/qemu.conf   | 29 ++++++++++++++++++++---------
>> src/qemu/qemu_conf.c | 38 +++++++++++++++++++++++++++++++++-----
>> 2 files changed, 53 insertions(+), 14 deletions(-)
>>
>> diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
>> index e6c0832..b0ccffb 100644
>> --- a/src/qemu/qemu.conf
>> +++ b/src/qemu/qemu.conf
>> @@ -3,7 +3,7 @@
>> # defaults are used.
>>
>> # Use of TLS requires that x509 certificates be issued. The default is
>> -# to keep them in /etc/pki/qemu. This directory must contain
>> +# to keep them in /etc/pki/qemu. This directory must exist and contain:
> 
> I suspect the POSIX specification mandates that the directory must exist
> in order to contain files. :)
> 

Noted, point taken and I'll drop this hunk.

>> #
>> #  ca-cert.pem - the CA master certificate
>> #  server-cert.pem - the server certificate signed with ca-cert.pem
>> @@ -13,6 +13,12 @@
>> #
>> #  dh-params.pem - the DH params configuration file
>> #
>> +# If the directory does not exist or does not contain the necessary
>> files,
>> +# QEMU domains will fail to start if they are configured to use TLS.
>> +#
> 
> Isn't this sufficiently covered by 'Use of TLS requires that x509
> certificates be issued'?
> 

One would think/assume, but then again the point of the bz was about the
comments being too vague, so I've taken the opposite approach to be
somewhat overly verbose.

If the directory exists, but doesn't contain the right files, libvirt
startup will succeed. However, any QEMU domain that's started *and* uses
TLS in some way will fail when QEMU starts if the right files don't
exist. The libvirt config code doesn't check that the specific files
exist in the directory.

It's perhaps "notable" that /etc/pki/qemu is never checked for
existence. So if things were commented out and someone tried to use TLS
without first creating an /etc/pki/qemu, then domain startup would fail
if it was configured to use TLS (or used for migration). That's a quirk
in the "default" setting because we don't provide the /etc/pki/qemu
directory.

>> +# In order to overwrite the default path alter the following. If the
>> provided
>> +# path does not exist, then startup will fail.
>> +#
> 
> To apply the configuration, you need to restart the daemon. And since
> daemon startup will fail, I think the user will be able to notice it.
> We should error out on incorrect paths as soon as we can, without
> mentioning it in the documentation.
> 

Again, since the bz indicated it wasn't clear, I was trying be overly
obvious. Sometimes being overly succinct in documentation has advantages
with respect to setting expectations.

How about if I change them to :

# In order to overwrite the default path alter the following. This path
# definition will be used as the default path for other *_tls_x509_cert_dir
# configuration settings if they are not specifically set.

(and assuming the changes descibed in [1] below)

>> #default_tls_x509_cert_dir = "/etc/pki/qemu"
>>
>>
>> @@ -79,8 +85,9 @@
>>
>> # In order to override the default TLS certificate location for
>> # vnc certificates, supply a valid path to the certificate directory.
>> -# If the provided path does not exist then the default_tls_x509_cert_dir
>> -# path will be used.
>> +# If the default listed here does not exist, then the default
>> /etc/pki/qemu
>> +# is used.
> 
> If I override default_tls_x509_cert_dir, without overriding all the
> specific *_tls_x509_cert_dir values, I expect they will all use my
> value, not the hardcoded default of /etc/pki/qemu.
> So the behavior described by the original comment makes more sense.
> 

But that doesn't reflect the actuality of the code. So are you expecting
the code to change too?

During virQEMUDriverConfigNew (SET_TLS_X509_CERT_DEFAULT), if the
"/etc/pki/libvirt-*" doesn't exist (where * would be vnc, spice,
chardev, migrate), then by default it is set to /etc/pki/qemu.

If someone then later changes default_tls_x509_cert_dir, then that
directory is used instead of the default /etc/pki/qemu. If the other
settings remain commented out, then their defaults are /etc/pki/qemu.

That being said - the virQEMUDriverConfigSetCertDir could change to add
code that could check if "default" was set to something other than the
default, then copy in "default" (and assume it was already checked) [1].

>> If uncommented and the provided path does not exist, then startup
>> +# will fail.
>> #
>> #vnc_tls_x509_cert_dir = "/etc/pki/libvirt-vnc"
>>

Strange snipping seems to have missed a [...] since the patch definitely
had more here, but they're all the same...

>> diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
>> index 73c33d6..4eb6f0c 100644
>> --- a/src/qemu/qemu_conf.c
>> +++ b/src/qemu/qemu_conf.c
>> @@ -440,6 +440,34 @@ virQEMUDriverConfigHugeTLBFSInit(virHugeTLBFSPtr
>> hugetlbfs,
>> }
>>
>>
>> +static int
>> +virQEMUDriverConfigSetCertDir(virConfPtr conf,
>> +                              const char *setting,
>> +                              char **value)
>> +{
>> +    char *tlsCertDir = NULL;
>> +
>> +    if (virConfGetValueString(conf, setting, &tlsCertDir) < 0)
>> +        return -1;
>> +
>> +    if (!tlsCertDir)

[1] (from above comments)...

If the entry was commented out, then if cfg->defaultTLSx509certdir is
not /etc/pki/qemu (the default), then STRDUP into *value:

    if (!tlsCertDir) {
        if (STRNEQ_NULLABLE(defaultTLS, *value)) {
            if (VIR_STRDUP(*value, defaultTLS) < 0)
                return -1
        }
        return 0;
    }

where defaultTLS is either cfg->defaultTLSx509certdir or NULL for
default. Since for the default case, the STRDUP isn't necessary;
however, for others (vnc, spice, chardev, and migrate) the *value would
be set to whatever cfg->defaultTLSx509certdir is.

If this happens, then the keeping the original comment is fine and the
bz would change it's "expected results" perhaps although it isn't clear
because it's not "default" that's changing.

>> +        return 0;
>> +
>> +    if (!virFileExists(tlsCertDir)) {
>> +        virReportError(VIR_ERR_CONF_SYNTAX,
> 
> This is not a syntax error.

And your suggestion for a better error is what? Should I create a new
one? Should I use virReportSystemError(ENOENT, ???)?

IDC really, but please don't make me guess!

> Validating these settings does not belong in virQEMUDriverConfigLoadFile;
> qemuStateInitialize or a function called from it would be a better
> place.
> 
> Jan

So this is different in what way than securityDriverNames, controllers,
migrateHost, migrationAddress, or namespaces?

I think creating some new validation routine to be run afterwards is
outside the scope of what's being done here especially considering there
already is validation taking place.

John




More information about the libvir-list mailing list