[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libvirt] Stored secrets seem to get corrupted
From: |
Daniel P. Berrange |
Subject: |
Re: [libvirt] Stored secrets seem to get corrupted |
Date: |
Wed, 4 Jul 2012 15:56:23 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Wed, Jul 04, 2012 at 06:08:59AM -0600, 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.
Yeah, that's sort of what I was imagining we could do in base64.h
in fact. If its better to just do it in libvirt config.h, then we
can do that too
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|