Re: [libvirt] Stored secrets seem to get corrupted

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