[libvirt] Stored secrets seem to get corrupted

[Wido den Hollander]

On 04-07-12 14:08, Eric Blake wrote:
> [adding gnulib]
>
> On 07/04/2012 02:45 AM, Daniel P. Berrange wrote:
>
>>>> ==6825==
>>>> ==6825== Invalid read of size 4
>>>> ==6825==    at 0xA57E4B9: base64_encode (in /usr/lib/x86_64-linux-gnu/libroken.so.18.1.0)
>>>> ==6825==    by 0x10DDBC98: base64_encode_alloc (base64.c:140)
>
>>>>
>>>> This one is very interesting. It shows that the 'base64_encode' function
>>>> is doing an out-of-bounds read. More tellingly though is that it is
>>>> reporting 'base64_encode' function is in a wierd library:
>>>>
>>>>     /usr/lib/x86_64-linux-gnu/libroken.so.18.1.
>>>>
>>>> If this were normal, we should expect to see that function present
>>>> in 'base64.c' since this function code is provided by gnulib itself.
>>>>
>>>> So something else libvirt is linking to, directly or indirectly
>>>> is using  libroken.so which also has a 'base64_encode'symbol
>>>> defined. This is overriding gnulib's symbol of the same name.
>>>>
>>>> I'm willing to bet the API contract of this libroken.so base64_encode.
>>>> differs from GNULIBS, with crashtastic results
>>>>
>
>>> The library is libroken18-heimdal under Ubuntu 12.04:
>>> http://packages.ubuntu.com/precise/libroken18-heimdal
>>>
>>> When installing ubuntu-virt-server libraries like gnutls depend on
>>> this library.
>>>
>
>> I expect that this is an internal symbol from libroken.so which
>> they leak into the public namespace.
>>
>
>> It sounds like we might need to have a workaround in gnulib to
>> avoid this problem. With other cases where gnulib replaces existing
>> symbols they use some magic such that the gnulib replacement gets
>> prefixed with 'rpl_'.
>
> Yuck.  Gnulib can't really probe at configure time whether an
> application will link against a shared library that drags in namespace
> pollution, so I don't see how to automate any 'rpl_' renaming in gnulib
> directly.  It would be possible to blindly rename the gnulib functions,
> but that's an interface change that would affect all clients of the
> gnulib base64 module.
>
> I'm wondering if it is better for libvirt to just #define base64_encode
> to a different name in config.h.  Meanwhile, we need to open a bug
> report against heimdal to fix their library namespace pollution through
> libroken.
>

As this is getting a bit out of my league it's safe for me to assume 
somebody else will pick this up?

Not to take the easy way out, but I don't think I can't provide much 
help here other then testing any patches.

Wido