Re: (ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS

[hyc@symas.com]

arthur@arthurdejong.org wrote:
> Full_Name: Arthur de Jong
> Version: 2.4.23
> OS: Debian/unstable
> URL:
> Submission from: (NULL) (2001:888:1613:0:218:8bff:fe55:2c9f)
>
>
> When a network connection to the LDAP server fails (is severed with iptables in
> my set-up) the error is detected properly with ldap_result()
> (LDAP_OPT_TIMELIMIT, LDAP_OPT_TIMEOUT and LDAP_OPT_NETWORK_TIMEOUT options are
> set), however closing the connection with ldap_unbind() hangs indefinitely on a
> read() operation (determined by strace) when using a ldaps:// connection.
>
> If the connection is opened without TLS ldap_unbind() only writes some data on
> the connection and then closes it but with TLS it expects some response back.
> Since read() is used this blocks.

Looks like this is a GnuTLS issue. Have you duplicated this with OpenSSL?
>
> This is a backtrace of the thread that was hanging:
>
> #0  0xb7fe2424 in __kernel_vsyscall ()
> #1  0xb7f5809b in read () at ../sysdeps/unix/syscall-template.S:82
> #2  0xb7e021bb in sb_stream_read (sbiod=0x8064630, buf=0x8083038, len=5)
>      at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:493
> #3  0xb7e0132a in sb_debug_read (sbiod=0x807e250, buf=0x8083038, len=5)
>      at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:827
> #4  0xb7fa0d27 in tlsg_recv (ptr=0x806fb50, buf=0x8083038, len=4294966784) at
> tls_g.c:904
> #5  0xb7c65aa2 in ?? () from /usr/lib/libgnutls.so.26
> #6  0xb7c65f77 in ?? () from /usr/lib/libgnutls.so.26
> #7  0xb7c611e7 in _gnutls_recv_int () from /usr/lib/libgnutls.so.26
> #8  0xb7c626b8 in gnutls_bye () from /usr/lib/libgnutls.so.26
> #9  0xb7fa0dc4 in tlsg_sb_close (sbiod=0x807e268) at tls_g.c:970
> #10 0xb7e01831 in ber_int_sb_close (sb=0x80645a8)
>      at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:383
> #11 0xb7f8d1a0 in ldap_free_connection (ld=0x8066418, lc=0x8065b60, force=1,
> unbind=1) at request.c:768
> #12 0xb7f83060 in ldap_ld_free (ld=0x8066418, close=1, sctrls=0x0, cctrls=0x0)
> at unbind.c:93
> #13 0xb7f83326 in ldap_unbind_ext (ld=0x8066418, sctrls=0x0, cctrls=0x0) at
> unbind.c:52
> #14 0xb7f8343f in ldap_unbind (ld=0x8066418) at unbind.c:69
> #15 0x0804cfc0 in ?? ()
> #16 0x0804e750 in ?? ()
> #17 0x08057a9f in ?? ()
> #18 0x0804bb8d in ?? ()
> #19 0xb7f50955 in start_thread (arg=0xb7b92b70) at pthread_create.c:300
> #20 0xb7ed0e7e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
>
>
> More background information is available at [0].
>
> As a workaround [1] I've used LDAP_OPT_DESC to get the file descriptor for the
> connection and used setsockopt(SO_RCVTIMEO) and setsockopt(SO_SNDTIMEO) on it.
> This fixes the problem for me at least but I'm not 100% this has no unwanted
> side-effects.
>
> [0] http://bugs.debian.org/596983
> [1] http://arthurdejong.org/viewvc/nss-pam-ldapd?view=rev&revision=1264
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/