Bug 503178
| Summary: | libvirtd crashes on tls connection | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Daniel Berrangé <berrange> |
| Component: | libvirt | Assignee: | Daniel Berrangé <berrange> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 5.4 | CC: | crobinso, nzhang, sghosh, veillard, virt-maint, xen-maint |
| Target Milestone: | rc | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 503066 | Environment: | |
| Last Closed: | 2009-09-02 09:22:33 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Daniel Berrangé
2009-05-29 12:56:24 UTC
To test: Server side: - On libvirtd server configure TLS CA cert and a server cert - Enable listen_tls =1 in livirtd.conf - Add --listen to /etc/sysconfig/libvirtd - Restart libvirtd daemon Client side: - Delibrately configure libivrt client with a *different* CA cert - Connect to server using virsh -c qemu+tls://somehostname/system Results: - client will fail to connect - server will crash with SEGV Sometimes it is neccessary to connect a couple of times with the client before it will crash the server. libvirt-0.6.3-4.el5 has been built in dist-5E-qu-candidate with the patch, Daniel I tested with libvirt-0.6.3-4.el5 on RHEL-5.4, still has a problem. Server side: - Enable listen_tls = 1 in livirtd.conf - Add --listen to /etc/sysconfig/libvirtd - Restart libvirtd daemon [root@dhcp-66-70-85 ~]# service libvirtd restart Stopping libvirtd daemon: [ OK ] Starting libvirtd daemon: [ OK ] [root@dhcp-66-70-85 ~]# service libvirtd status libvirtd dead but subsys locked Client side: [root ~]# virsh -c qemu+tls://10.66.70.85/system error: failed to connect to the hypervisor I can't reproduce the failure with 0.6.3-4.el5, so can you try and get more debuginfo, by installing the matching libvirt-debuginfo RPM, and then run libvirtd manually under GDB, eg # service libvirtd stop # gdb --args /usr/sbin/libvirtd --listen (gdb) run And then on the remote client try connecting again, and if it crashes, then do 'thread apply all backtrace' in the GDB console. I retest with 0.6.3-5.el5. On my machine, there will be a CA error as following. [root@dhcp-66-70-85 ~]# service libvirtd stop Stopping libvirtd daemon: [ OK ] [root@dhcp-66-70-85 ~]# gdb --args /usr/sbin/libvirtd --listen GNU gdb Fedora (6.8-35.el5) Copyright (C) 2008 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"... (gdb) run Starting program: /usr/sbin/libvirtd --listen [Thread debugging using libthread_db enabled] [New Thread 0x2b6a263971b0 (LWP 4158)] 13:37:07.036: error : Cannot access CA certificate '/etc/pki/CA/cacert.pem': No such file or directory Program exited with code 02. (gdb) q [root@dhcp-66-70-85 ~]# ls /etc/pki/CA/cacert.pem ls: /etc/pki/CA/cacert.pem: No such file or directory [root@dhcp-66-70-85 ~]# Ok, you were not actually testing the scenario I described. You need to actaully configure the server with a CA cert and server certificate and private key, otherwise libvirtd will simply quit upon startup as you see there. Only once you have the server running with a certificate, can you test the scenario from comment #1 This page provides info on how to configure certificates: http://libvirt.org/remote.html#Remote_certificates Yes, I configured the server with CA, but still has error when client try to connect to the server like following. [root ~]# virsh -c qemu+tls://10.66.70.85/system error: failed to connect to the hypervisor [root@dhcp-66-70-85 CA]# service libvirtd stop Stopping libvirtd daemon: [ OK ] [root@dhcp-66-70-85 CA]# gdb --args /usr/sbin/libvirtd --listen GNU gdb Fedora (6.8-35.el5) Copyright (C) 2008 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"... (gdb) run Starting program: /usr/sbin/libvirtd --listen [Thread debugging using libthread_db enabled] [New Thread 0x2b709f03e8e0 (LWP 4027)] [New Thread 0x41ded940 (LWP 4030)] [New Thread 0x427ee940 (LWP 4031)] [New Thread 0x431ef940 (LWP 4032)] [New Thread 0x43bf0940 (LWP 4033)] [New Thread 0x445f1940 (LWP 4034)] 20:11:41.304: error : gnutls_record_recv: A TLS packet with unexpected length was received. 20:12:11.743: error : gnutls_record_recv: A TLS packet with unexpected length was received. The client is supposed to see the error 'error: failed to connect to the hypervisor'. All that we were attempting to solve was that the server libvirtd process would crash with SEGV after the 'gnutls_record_recv: A TLS packet with unexpected length was received. ' message. Since you're most recent comment shows the libvirtd continues to run without crashing, I'd you've now verified that the SEGV crash is solved. OK, now is the expected results as following, it's fixed with libvirt 0.6.3-5 in RHEL-5.4. - client: fail to connect - server: do not crash with SEGV An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-1269.html |