Full_Name: Del Version: 2.0.7 OS: Linux (RH6.2, Kernel 2.2.16) URL: Submission from: (NULL) (203.96.111.201) The following command core dumps: ldapsearch -H ldaps://<servername>/ -x This dumps core regardless of whether the server is an OpenLDAP 2.0.7 server running in SSL mode (slapd -h "ldap:/// ldaps:///") or an NDS server also set up for SSL mode. A command line openssl connection to the LDAP server on port 636 appears to work OK, and shows a trace of certificates and certificate issuers. ... following the debug output of the slapd server, it appears that the connection gets started OK, and almost completes OK. I see messages like these (trimming out the hex dump scribble): TLS trace: SSL_accept:before/accept initialization tls_read: want=11, got=11 TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A tls_write: want=1024, written=1024 TLS trace: SSL_accept:SSLv3 flush data tls_read: want=5 error=Resource temporarily unavailable TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A daemon: select: listen=6 active_threads=0 tvp=NULL daemon: select: listen=7 active_threads=0 tvp=NULL daemon: activity on 1 descriptors daemon: activity on: 8r daemon: read activity on 8 connection_get(8) connection_get(8): got connid=0 connection_read(8): checking for input on id=0 tls_read: want=5, got=5 TLS trace: SSL_accept:SSLv3 read client key exchange A tls_read: want=5, got=5 TLS trace: SSL_accept:SSLv3 read finished A TLS trace: SSL_accept:SSLv3 write change cipher spec A TLS trace: SSL_accept:SSLv3 write finished A tls_write: want=51, written=51 TLS trace: SSL_accept:SSLv3 flush data daemon: select: listen=6 active_threads=0 tvp=NULL daemon: select: listen=7 active_threads=0 tvp=NULL daemon: activity on 1 descriptors daemon: activity on: 8r daemon: read activity on 8 connection_get(8) connection_get(8): got connid=0 connection_read(8): checking for input on id=0 ber_get_next tls_read: want=5, got=0 ldap_read: want=1, got=0 ber_get_next on fd 8 failed errno=0 (Success) connection_read(8): input error=-2 id=0, closing. connection_closing: readying conn=0 sd=8 for close connection_close: conn=0 sd=8 daemon: removing 8 tls_write: want=29, written=29 TLS trace: SSL3 alert write:warning:close notify daemon: select: listen=6 active_threads=0 tvp=NULL daemon: select: listen=7 active_threads=0 tvp=NULL daemon: activity on 1 descriptors daemon: select: listen=6 active_threads=0 tvp=NULL daemon: select: listen=7 active_threads=0 tvp=NULL ... and at this point the client dies with no output. ldappasswd dumps core also on ldaps, but works fine in -ZZ mode. When run in ldaps mode it doesn't appear to write a password. In -ZZ mode it does. also, Julio Sanchez Fernandez wrote: > It seems to fail in ldap_int_sasl_external in cyrus.c, possibly > because ld_defconn is garbage. > > But I don't quite understand why it is trying to do an external > sasl bind, if that is what it is doing... > > Use of -Y does not seem to have any effect. Del
del@babel.com.au wrote: > Version: 2.0.7 > ldapsearch -H ldaps://<servername>/ -x > also, Julio Sanchez Fernandez wrote: > > > It seems to fail in ldap_int_sasl_external in cyrus.c, possibly > > because ld_defconn is garbage. > > > > But I don't quite understand why it is trying to do an external > > sasl bind, if that is what it is doing... I think that ldap_int_sasl_external is to set the sasl external ssf value and auth_id to those of the external mechanism. It tries to access ld->ld_defconn->lconn_sasl_ctx which is not there yet. ldap_pvt_tls_start (which calls ldap_int_sasl_external) is also called when establishing TLS. In this context, ld->ld_defconn is already valid. But in a SSL connect, ld->ld_defconn is set to the return value of ldap_new_connection in ldap_open_defconn. ldap_new_connection first allocates lc to which ld->defconn is set. But ldap_new_connection calls ldap_int_open_connection -> ldap_pvt_tls_start -> ldap_int_sasl_external, which then tries to access the non existent ld->ld_defconn. I suggest adding another parameter to ldap_pvt_tls_start which explicitly holds ldap_conn and then calling ldap_int_sasl_external with "LDAPConn *conn" instead of "LDAP *ld": ldap_int_sasl_external( LDAPConn *conn, const char * authid, ber_len_t ssf ) { int sc; sasl_conn_t *ctx = conn->lconn_sasl_ctx; -- Norbert Klasen DFN Directory Services tel: +49 7071 29 70335 ZDV, Universität Tübingen fax: +49 7071 29 5912 Wächterstr. 76, 72074 Tübingen http://www.directory.dfn.de Germany norbert.klasen@zdv.uni-tuebingen.de
At 08:32 PM 11/15/00 +0000, klasen@zdv.uni-tuebingen.de wrote: >del@babel.com.au wrote: >> Version: 2.0.7 >> ldapsearch -H ldaps://<servername>/ -x >> also, Julio Sanchez Fernandez wrote: >> >> > It seems to fail in ldap_int_sasl_external in cyrus.c, possibly >> > because ld_defconn is garbage. >> > >> > But I don't quite understand why it is trying to do an external >> > sasl bind, if that is what it is doing... > >I think that ldap_int_sasl_external is to set the sasl external ssf >value and auth_id to those of the external mechanism. > >It tries to access ld->ld_defconn->lconn_sasl_ctx which is not there >yet. > >ldap_pvt_tls_start (which calls ldap_int_sasl_external) is also called >when establishing TLS. In this context, ld->ld_defconn is already valid. > >But in a SSL connect, ld->ld_defconn is set to the return value of >ldap_new_connection in ldap_open_defconn. ldap_new_connection first >allocates lc to which ld->defconn is set. But ldap_new_connection calls >ldap_int_open_connection -> ldap_pvt_tls_start -> >ldap_int_sasl_external, which then tries to access the non existent >ld->ld_defconn. > >I suggest adding another parameter to ldap_pvt_tls_start which >explicitly holds ldap_conn and then calling ldap_int_sasl_external with >"LDAPConn *conn" instead of "LDAP *ld": A simple and quick solution is just to have ldap_int_sasl_external do nothing if there is no SASL context. ldaps:// is really pre-LDAP SASL and deprecated. LDAP SASL (RFC 2829) is designed to be used with Start TLS (RFC 2830). However, I have no objection to fixing this such that SASL/EXTERNAL can be used with ldaps://. Likely here the fix is to establish the SASL context prior to starting TLS. Kurt
Kurt@OpenLDAP.org wrote: > However, I have no objection to fixing this such that SASL/EXTERNAL > can be used with ldaps://. Likely here the fix is to establish > the SASL context prior to starting TLS. Here's a patch that sets ld->ld_defconn temporarily in ldap_int_open_connection() (taken from the rebind section in ldap_new_connection() ). Thus there is a valid sasl context in ldap_int_sasl_external(). I first though of adding a sasl_conn_t parameter to ldap_pvt_tls_start() but there seems to be some effort, not to include sasl.h in ldap_pvt.h ftp://ftp.openldap.org/incoming/norbert.klasen-20001122-its889.patch -- Norbert Klasen DFN Directory Services tel: +49 7071 29 70335 ZDV, Universität Tübingen fax: +49 7071 29 5912 Wächterstr. 76, 72074 Tübingen http://www.directory.dfn.de Germany norbert.klasen@zdv.uni-tuebingen.de
moved from Incoming to Software Bugs
changed notes changed state Open to Release
changed notes changed state Release to Closed
moved from Software Bugs to Archive.Software Bugs
committed to HEAD and re20