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

Ján Tomko jtomko at redhat.com
Thu Jul 20 14:30:48 UTC 2017


On Wed, Jul 19, 2017 at 04:02:59PM -0400, John Ferlan wrote:
>On 07/19/2017 09:56 AM, Ján Tomko wrote:
>> On Thu, Jun 29, 2017 at 10:32:35AM -0400, John Ferlan wrote:
>>> #
>>> #  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.
>

The bz was about a comment not matching the behavior.

>>> +# 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.
>

Looks good.

>(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?
>

Yes.

>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...
>

I will work on destrangifying my snipping.

>>> 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;

If the default values should be propagated, it would be simpler
to let the parser only fill the specified paths first and then
fill out the defaults. That way all the auto-magic logic would
be in one place.

>    }
>
>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!
>

It's not really a system error, nor an internal error. So any of
VIR_ERR_CONF_SYNTAX, VIR_ERR_INTERNAL_ERROR or SYSTEM_ERROR should do.

The issue I have with this is that it makes the parser function
dependent on the host state.

>> 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?

Apart from namespaces, these are checked against duplicates/compared
against some known strings, all things that could be theoretically
represented by some schema document.

For namespaces, we also check them against host state, which does not
belong in a parser.

Jan

>
>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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170720/4d4f213d/attachment-0001.sig>


More information about the libvir-list mailing list