https://bugs.openldap.org/show_bug.cgi?id=9389
Issue ID: 9389 Summary: Improve the way how libldap handles interruption signal while in tls_read Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs@openldap.org Reporter: simon.pichugin@gmail.com Target Milestone: ---
Description: When signal-interrupted (by any signal, i.e. SIGRTMIN+1) while in tls_read, libldap will stop the execution.
It will be better to make libldap more robust because some applications may use the signals in their watchdogs (i.e. SSSD).
The issue happens when client executes the function - libraries/libldap/tls2.c:1280:ldap_install_tls(LDAP *ld)
(Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 read server certificate A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 read server certificate request A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 read server done A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 write client certificate A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 write client key exchange A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 write change cipher spec A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 write finished A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: tls_write: want=610, written=610 (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0000: 16 03 00 00 07 0b 00 00 03 00 00 00 16 03 03 02 ................ (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0010: 06 10 00 02 02 02 00 83 00 20 ec bc 90 f5 f3 d3 ......??? ...... (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0020: 87 72 d6 a2 1e 00 d0 5d a0 64 00 00 99 9f 0b db .r.......d.M....
.... (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0230: 44 06 1c 96 00 28 ee a1 28 00 63 1f 00 49 00 34 D.......(.c..I.4 (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0240: 50 63 79 78 00 11 65 de 00 5d e0 aa 00 c8 00 aa P.x.....]..[.Z. (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0250: 88 83 3e 59 00 7b 80 6b 65 a2 c3 ee 12 20 00 2c ..>Y.{.ke.... ., (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0260: 00 a1 .. (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 flush data (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: tls_read: want=5 error=Interrupted system call (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:error in SSLv3 read finished A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:error in SSLv3 read finished A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS: can't connect: . (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_free_connection 1 1 (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_send_unbind (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ber_flush2: 7 bytes to sd 23 (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0000: 00 05 00 01 00 42 00 .....B. (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_write: want=7, written=7 (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0000: 00 05 00 01 01 42 00 .....B. (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_free_connection: actually freed
The issue is hard to reproduce as it should be interrupted in a very precise moment.
Proposal: Add a retry action somewhere inside of ldap_install_tls which will reinitiate the operation from the beginning (so it won't affect the security aspect but it will increase reliability).