https://bugs.openldap.org/show_bug.cgi?id=9474
Issue ID: 9474
Summary: ldap_install_tls() should return meaningful error code
Product: OpenLDAP
Version: 2.4.57
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
The description of my findings (take a note that these are OpenLDAP logs that
happen under the application that uses libldap):
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: tls_write: want=610,
written=610
...
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace:
SSL_connect:SSLv3 flush data
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: tls_read: want=5
error=Interrupted system call
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace:
SSL_connect:error in SSLv3 read finished A
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace:
SSL_connect:error in SSLv3 read finished A
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS: can't connect: .
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_free_connection 1
1
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_send_unbind
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ber_flush2: 7 bytes to
sd 23
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0000: 00 05 00 01
00 42 00
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_write: want=7,
written=7
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0000: 00 05 00 01
01 42 00
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_free_connection:
actually freed
So, 'error=Interrupted system call' is caught by this:
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/tls2.c#L360
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblber/sockbuf.c#L829
It is only the debug message that comes from the caller itself so we can see
what is passed to OpenSSL.
And 'Interrupted system call' is just an EINTR string representation.
What we should do is to catch the error that OpenSSL returns to us after it is
interrupted.
As we can see from the logs:
"libldap: TLS: can't connect: ."
This line returns nothing:
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/tls2.c#L427
So 'ld->ld_error' is set to empty value.
If we go deeper into the 'tls_imp->ti_session_errmsg' call we can reach the
point where ERR_peek_error() is called:
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/tls2.c#L416
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/tls_o.c#L563
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/tls_o.c#L569
In the conclusion:
ldap_install_tls() should return meaningful error code that would allow to
figure out a reason for the failure, especially network IO fail due to EITR.
--
You are receiving this mail because:
You are on the CC list for the issue.
