[libvirt] Stored secrets seem to get corrupted

[Wido den Hollander]

On 03-07-12 15:13, Daniel P. Berrange wrote:
>>>
>>> That is really bizarre. Can you look at what is actually stored
>>> in the .base64 file each time ? And what 'secret-get-value'
>>> replies with ?
>>
>> I haven't been able to look into this any further, however: I just
>> downloaded 0.9.13 from the libvirt website and installed it on a
>> totally different host which is also running Ubuntu 12.04
>>
>> I wanted to start a virtual machine with RBD storage and that
>> failed, the secret was corrupted...
>>
>> The symptoms on this machine are exactly the same, the secret file
>> is just 2 bytes big.
>>
>> root at amd:~# ls -al /etc/libvirt/secrets/*.base64
>> -rw------- 1 root root 2 Jul  3 15:02
>> /etc/libvirt/secrets/69f9540e-f0ce-4184-8254-9b22efade5f2.base64
>> root at amd:~#
>>
>>>
>>> This is the correct behaviour tht I see myself too.
>>>
>>>> I verified that stack01 isn't out of disk space or out of inodes,
>>>> those are in the acceptable values range.
>>>>
>>>> Any suggestions?
>>>
>>> I think you'll probably need to add some more  VIR_DEBUG lines
>>> to secret_driver.c to see where in the process it is going
>>> wrong. Or perhaps strace libvirtd to see what it thinks it
>>> is writing out & whether any errors appear.
>>>
>>
>> I haven't added any VIR_DEBUG lines yet, but stracing the libvirtd
>> process doesn't show any fopen() nor fwrites() to any *.base64
>> files.

I just added a couple of VIR_DEBUG lines to secret_driver.c and found 
out that the base64 encoding is actually the problem.

In secretSaveValue

     VIR_DEBUG("WIDO Secret value: %s, size %lu", secret->value, 
secret->value_size);

     filename = secretBase64Path(driver, secret);
     if (filename == NULL)
         goto cleanup;
     base64_encode_alloc((char *)secret->value, secret->value_size,
                         &base64);
     if (base64 == NULL) {
         virReportOOMError();
         goto cleanup;
     }

     VIR_DEBUG("WIDO Writing %s to %s with a length of %lu", base64, 
filename, strlen(base64));
     if (replaceFile(filename, base64, strlen(base64)) < 0)
         goto cleanup;


The results I get back:

$ virsh secret-set-value 322bccea-f2ed-4eae-a7e5-d0793ffb162d d2lkbw==

2012-07-03 14:02:57.065+0000: 4593: debug : secretSaveValue:297 : WIDO 
Secret value: wido, size 4
2012-07-03 14:02:57.065+0000: 4593: debug : secretSaveValue:309 : WIDO 
Writing ���
 
             to 
/etc/libvirt/secrets/322bccea-f2ed-4eae-a7e5-d0793ffb162d.base64 with a 
length of 6

Here you can see the secret value arrives at the secret driver in tact, 
but the base64_encode_alloc seems to scramble the data.

It should display base64 encoded data to write to 'filename', but it's 
showing some binary stuff.

I then tried to shut down libvirt, manually write the base64 data to the 
file and start libvirt again:

loadSecrets:510 : Error reading secret: internal error invalid base64 in XXX

But there is valid base64 data in that file.

This seems to be a gnulib thing? The submodule gnulib is used for the 
base64 encoding, isn't it?

Checking the gnulib source shows that there have been no changes to 
base64.h and .c. The last change is from over a year ago.

>
> When strac'ing libvirtd make sure you add the '-f' arg so that you
> trace all threads - the libvirtd thread leader will never do any
> interesting stuff except RPC i/o
>

Right... My bad :)

Wido