[libvirt] [libvirt-php] libvirt_connect not reading out credential info on 0.5.2

[Michal Privoznik]

On 06.09.2016 13:45, Fernando Casas Schössow wrote:
> Thanks for the instructions since I'm not familiar with debugging as you
> probably guessed. :)
> 
> Here you have gdb output:
> 
> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/bin/php...Reading symbols from
> /usr/bin/php...(no debugging symbols found)...done.
> (no debugging symbols found)...done.
> Missing separate debuginfos, use: debuginfo-install
> php-cli-5.4.16-36.3.el7_2.x86_64
> (gdb) run /storage/lighttpd/wwwroot/libvirt.php
> Starting program: /usr/bin/php /storage/lighttpd/wwwroot/libvirt.php
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> [New Thread 0x7fffe2ceb700 (LWP 31799)]
> [Thread 0x7fffe2ceb700 (LWP 31799) exited]
> PHP Warning: unlink(test.log): No such file or directory in
> /storage/lighttpd/wwwroot/libvirt.php on line 4
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007fffe9ad54a0 in virClassIsDerivedFrom () from /lib64/libvirt.so.0
> (gdb) backtrace
> #0 0x00007fffe9ad54a0 in virClassIsDerivedFrom () from /lib64/libvirt.so.0
> #1 0x00007fffe9b861ac in virDomainLookupByUUIDString () from
> /lib64/libvirt.so.0
> #2 0x00007fffea1e82c5 in generate_uuid () from
> /usr/lib64/php/modules/libvirt-php.so
> #3 0x00007fffe7d3385a in wsmc_create_request () from
> /lib64/libwsman_client.so.4
> #4 0x00007fffe7d3546f in wsmc_action_enumerate () from
> /lib64/libwsman_client.so.4
> #5 0x00007fffe9c8e34a in hypervEnumAndPull () from /lib64/libvirt.so.0
> #6 0x00007fffe9c8ee49 in hypervGetMsvmComputerSystemList () from
> /lib64/libvirt.so.0
> #7 0x00007fffe9c8dacd in hypervConnectOpen () from /lib64/libvirt.so.0
> #8 0x00007fffe9b82f39 in virConnectOpenInternal () from /lib64/libvirt.so.0
> #9 0x00007fffe9b845ce in virConnectOpenAuth () from /lib64/libvirt.so.0
> #10 0x00007fffea1e1190 in zif_libvirt_connect () from
> /usr/lib64/php/modules/libvirt-php.so
> #11 0x000055555586b57c in zend_do_fcall_common_helper_SPEC ()
> #12 0x00005555557e8527 in execute ()
> #13 0x00005555557c115f in zend_execute_scripts ()
> #14 0x0000555555760976 in php_execute_script ()
> #15 0x000055555586d598 in do_cli ()
> #16 0x000055555561a12e in main ()


Ah, this is exactly what I needed. Well, we're doomed. There are two
problems here.

The first one is: libvirt-php is exporting symbols that is shouldn't
have. Like for instance generate_uuid which is clearly meant as an
internal helper but because of our own bug (well, missing
implementation) it is being exported. Thus, when linker is linking the 
libraries together it finds out that libwsman_client.so.4 needs
generate_uuid symbol which it finds in libvirt-pgp.so instead of
libwsman.so.1.0.0 (which is what libwsman devels intended).

objdump -T /usr/lib64/libwsman_client.so.4 | grep generate_uuid
0000000000000000      D  *UND*  0000000000000000              generate_uuid

bjdump -T /usr/lib64/php/modules/libvirt-php.so | grep generate
000000000002b660 g    DF .text  00000000000000ce  Base        generate_uuid
000000000002b590 g    DF .text  00000000000000cb  Base        generate_uuid_any

objdump -T /lib64/libwsman.so.1.0.0 | grep generate
000000000000e820 g    DF .text  00000000000001bd  Base        generate_uuid
000000000001f950 g    DF .text  000000000000005a  Base        wsman_generate_fault_buffer
000000000001f8c0 g    DF .text  0000000000000082  Base        wsman_generate_fault

The fix on our part is obvious.

The second problem is, libwsman devels should not really be using such
generic names in their libraries. At least they need to prefix their
public function names with wsman_ (see those other 'generate_fault'
functions?).

I'll work on fix and let you test it - since the backtrace proof this
is hyperv specific bug. That's why I was unable to reproduce it.

Thanks for the report!

Michal