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: [email protected]
Reporter: [email protected]
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).
--
You are receiving this mail because:
You are on the CC list for the issue.
