SSSD / sssd

Clone

#2878 sssd failover does not work on connecting to non-responsive ldaps:// server
Closed: Fixed 4 years ago by jhrozek. Opened 8 years ago by jhrozek.

Closed: Fixed
Reopen Issue

In case ldaps:// is used, then
establishing the
secure socket is a sychronous operation. If there's nothing on the other
end, then the process would be stuck waiting in for the crypto library
to finish:

# pstack $(pidof sssd_be)
#0  0x00007fdde3963530 in __read_nocancel () from /lib64/libpthread.so.0
#1  0x00007fdde592f3c8 in sb_debug_read () from /lib64/liblber-2.4.so.2
#2  0x00007fdde570c4fb in tlsm_PR_Recv.part.8 () from /lib64/libldap-2.4.so.2 
#3  0x00007fdde494ffae in ssl_DefRecv () from /lib64/libssl3.so
#4  0x00007fdde494af5f in ssl3_GatherCompleteHandshake () from /lib64/libssl3.so
#5  0x00007fdde494be55 in ssl_GatherRecord1stHandshake () from /lib64/libssl3.so
#6  0x00007fdde49547b5 in ssl_Do1stHandshake () from /lib64/libssl3.so
#7  0x00007fdde4954dc8 in SSL_ForceHandshake () from /lib64/libssl3.so
#8  0x00007fdde570efb3 in tlsm_session_accept_or_connect () from /lib64/libldap-2.4.so.2
#9  0x00007fdde5709ab5 in ldap_int_tls_connect.isra () from /lib64/libldap-2.4.so.2
#10 0x00007fdde570a2d8 in ldap_int_tls_start () from /lib64/libldap-2.4.so.2
#11 0x00007fddde58a864 in sss_ldap_init_sys_connect_done (subreq=0x0) at /sssd/src/util/sss_ldap.c:458
#12 0x00007fddde589c8f in sdap_async_sys_connect_done (ev=0x1364660, fde=0x0, flags=2, priv=0x13a8440) at /sssd/src/util/sss_ldap.c:226
#13 0x00007fdde354a3c3 in epoll_event_loop_once () from /lib64/libtevent.so.0
#14 0x00007fdde3548907 in std_event_loop_once () from /lib64/libtevent.so.0
#15 0x00007fdde354511d in _tevent_loop_once () from /lib64/libtevent.so.0
#16 0x00007fdde35452bb in tevent_common_loop_wait () from /lib64/libtevent.so.0
#17 0x00007fdde35488a7 in std_event_loop_wait () from /lib64/libtevent.so.0
#18 0x00007fdde6ca7181 in server_loop (main_ctx=0x1365ab0) at /sssd/src/util/server.c:673
#19 0x000000000040e1e9 in main (argc=8, argv=0x7fff90060c18) at /sssd/src/providers/data_provider_be.c:2842

On the SSSD side, we can use LDAP_OPT_X_TLS_CONNECT_CB, but there are
still some issues on the libldap side side, the functions would report
TLS is already established.

Fields changed blockedby: => blocking: => changelog: => coverity: => description: In case ldaps:// is used, then establishing the secure socket is a sychronous operation. If there's nothing on the other end, then the process would be stuck waiting in for the crypto library to finish: # pstack $(pidof sssd_be) #0 0x00007fdde3963530 in __read_nocancel () from /lib64/libpthread.so.0 #1 0x00007fdde592f3c8 in sb_debug_read () from /lib64/liblber-2.4.so.2 #2 0x00007fdde570c4fb in tlsm_PR_Recv.part.8 () from /lib64/libldap-2.4.so.2 #3 0x00007fdde494ffae in ssl_DefRecv () from /lib64/libssl3.so #4 0x00007fdde494af5f in ssl3_GatherCompleteHandshake () from /lib64/libssl3.so #5 0x00007fdde494be55 in ssl_GatherRecord1stHandshake () from /lib64/libssl3.so #6 0x00007fdde49547b5 in ssl_Do1stHandshake () from /lib64/libssl3.so #7 0x00007fdde4954dc8 in SSL_ForceHandshake () from /lib64/libssl3.so #8 0x00007fdde570efb3 in tlsm_session_accept_or_connect () from /lib64/libldap-2.4.so.2 #9 0x00007fdde5709ab5 in ldap_int_tls_connect.isra () from /lib64/libldap-2.4.so.2 #10 0x00007fdde570a2d8 in ldap_int_tls_start () from /lib64/libldap-2.4.so.2 #11 0x00007fddde58a864 in sss_ldap_init_sys_connect_done (subreq=0x0) at /sssd/src/util/sss_ldap.c:458 #12 0x00007fddde589c8f in sdap_async_sys_connect_done (ev=0x1364660, fde=0x0, flags=2, priv=0x13a8440) at /sssd/src/util/sss_ldap.c:226 #13 0x00007fdde354a3c3 in epoll_event_loop_once () from /lib64/libtevent.so.0 #14 0x00007fdde3548907 in std_event_loop_once () from /lib64/libtevent.so.0 #15 0x00007fdde354511d in _tevent_loop_once () from /lib64/libtevent.so.0 #16 0x00007fdde35452bb in tevent_common_loop_wait () from /lib64/libtevent.so.0 #17 0x00007fdde35488a7 in std_event_loop_wait () from /lib64/libtevent.so.0 #18 0x00007fdde6ca7181 in server_loop (main_ctx=0x1365ab0) at /sssd/src/util/server.c:673 #19 0x000000000040e1e9 in main (argc=8, argv=0x7fff90060c18) at /sssd/src/providers/data_provider_be.c:2842 On the SSSD side, we can use LDAP_OPT_X_TLS_CONNECT_CB, but there are still some issues on the libldap side side, the functions would report TLS is already established. => In case ldaps:// is used, then establishing the secure socket is a sychronous operation. If there's nothing on the other end, then the process would be stuck waiting in for the crypto library to finish: {{{ # pstack $(pidof sssd_be) #0 0x00007fdde3963530 in __read_nocancel () from /lib64/libpthread.so.0 #1 0x00007fdde592f3c8 in sb_debug_read () from /lib64/liblber-2.4.so.2 #2 0x00007fdde570c4fb in tlsm_PR_Recv.part.8 () from /lib64/libldap-2.4.so.2 #3 0x00007fdde494ffae in ssl_DefRecv () from /lib64/libssl3.so #4 0x00007fdde494af5f in ssl3_GatherCompleteHandshake () from /lib64/libssl3.so #5 0x00007fdde494be55 in ssl_GatherRecord1stHandshake () from /lib64/libssl3.so #6 0x00007fdde49547b5 in ssl_Do1stHandshake () from /lib64/libssl3.so #7 0x00007fdde4954dc8 in SSL_ForceHandshake () from /lib64/libssl3.so #8 0x00007fdde570efb3 in tlsm_session_accept_or_connect () from /lib64/libldap-2.4.so.2 #9 0x00007fdde5709ab5 in ldap_int_tls_connect.isra () from /lib64/libldap-2.4.so.2 #10 0x00007fdde570a2d8 in ldap_int_tls_start () from /lib64/libldap-2.4.so.2 #11 0x00007fddde58a864 in sss_ldap_init_sys_connect_done (subreq=0x0) at /sssd/src/util/sss_ldap.c:458 #12 0x00007fddde589c8f in sdap_async_sys_connect_done (ev=0x1364660, fde=0x0, flags=2, priv=0x13a8440) at /sssd/src/util/sss_ldap.c:226 #13 0x00007fdde354a3c3 in epoll_event_loop_once () from /lib64/libtevent.so.0 #14 0x00007fdde3548907 in std_event_loop_once () from /lib64/libtevent.so.0 #15 0x00007fdde354511d in _tevent_loop_once () from /lib64/libtevent.so.0 #16 0x00007fdde35452bb in tevent_common_loop_wait () from /lib64/libtevent.so.0 #17 0x00007fdde35488a7 in std_event_loop_wait () from /lib64/libtevent.so.0 #18 0x00007fdde6ca7181 in server_loop (main_ctx=0x1365ab0) at /sssd/src/util/server.c:673 #19 0x000000000040e1e9 in main (argc=8, argv=0x7fff90060c18) at /sssd/src/providers/data_provider_be.c:2842 }}} On the SSSD side, we can use LDAP_OPT_X_TLS_CONNECT_CB, but there are still some issues on the libldap side side, the functions would report TLS is already established. design: => design_review: => 0 feature_milestone: => fedora_test_page: => mark: no => 0 review: True => 0 selected: => testsupdated: => 0

Fields changed

owner: somebody => jhrozek

Since there is a downstream request, this ticket should go to 1.13. But there is a risk it would be popped out since we don't know exactly what is the issue on the OpenLDAP side.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13.3

I still need feedback from the OpenLDAP maintainer on the libldap issue..

milestone: SSSD 1.13.3 => SSSD 1.13.4

Fields changed

cc: => mhonek

We need to discuss whether to defer this ticket

milestone: SSSD 1.13.4 => NEEDS_TRIAGE

Deferring this ticket until libldap is fixed to provide the proper error codes. Please note the same behavior happens also with OpenSSL-backed libldap.

milestone: NEEDS_TRIAGE => SSSD Deferred

Metadata Update from @jhrozek:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD Patches welcome
7 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch reset (from 0)
- Custom field review reset (from 0)
- Custom field sensitive reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
4 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue set to the milestone: SSSD 2.3 (was: SSSD Patches welcome)
4 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3919

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata
None
None
None
major
defect
SSSD
None
None
false
false
https://bugzilla.redhat.com/show_bug.cgi?id=1283798
false
false
None
None
None
false
None
None
false
mhonek
None
None
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.