Re: [libvirt] Stored secrets seem to get corrupted

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.