openldap-bugs January 2009

openldap-bugs@openldap.org

50 participants
201 discussions

(ITS#5888) MSVC 9.0 build issue
by kurt＠OpenLDAP.org 14 Jan '09

14 Jan '09

Full_Name: Kurt Zeilenga Version: HEAD OS: Windows Server 2008 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2002:4b8d:e980:0:217:f2ff:fed0:27f1) Submitted by: kurt The current configure script checks for _vsnprintf and then defines a macro #define vsnprintf _vsnprintf. But the system has a vsnprintf. This causes a clash in <stdio.h> which defines both vsnprintf and _vsnprintf. configure.in and include/portable.in need a bit of work to detected this situation....

1 0

Re: (ITS#5887) Fix GnuTLS support for TLS_CIPHER_SUITE
by simon＠josefsson.org 14 Jan '09

14 Jan '09

Quanah Gibson-Mount <quanah(a)zimbra.com> writes: > --On Wednesday, January 14, 2009 7:29 PM +0000 hyc(a)symas.com wrote: > >> quanah(a)OpenLDAP.org wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.4.13 >>> OS: NA >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.111.29.239) >>> >>> >>> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510346 >>> >>> Summary from Simon Josefsson: >>> >>> A proper fix requires co-ordination with the OpenLDAP people. Either >>> they 1) remove all strange code for parsing ciphers for GnuTLS and only >>> use gnutls_priority_set_direct on the TLS_CIPHER_SUITE string, or 2) >>> they introduce a new configuration keyword TLS_PRIORITY that is is sent >>> to GnuTLS's priority functions. Given that TLS_CIPHER_SUITE accepts >>> OpenSSL strings like 'HIGH:+SSLv2' I believe that matches GnuTLS >>> priority strings, so I would recommend 1). And improve the >>> documentation to point at, e.g., gnutls_priority_init(3) or the GnuTLS >>> manual in the OpenLDAP documentation. >> >> Sounds like we should do (1). There was no such API in GnuTLS when our >> support was written, which is why we had to go to the trouble of parsing >> the cipher suites ourselves. I'm fine with ripping that all out, if >> someone will tell us what minimum version of GnuTLS provides the new API. > > Simon? The APIs were released as stable for v2.2.0 on 2007-12-14. Perhaps you could have an autoconf test for gnutls_priority_set_direct and only enable the new code conditionally. /Simon

1 0

Re: (ITS#5887) Fix GnuTLS support for TLS_CIPHER_SUITE
by quanah＠zimbra.com 14 Jan '09

14 Jan '09

--On Wednesday, January 14, 2009 7:29 PM +0000 hyc(a)symas.com wrote: > quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.13 >> OS: NA >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.29.239) >> >> >> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510346 >> >> Summary from Simon Josefsson: >> >> A proper fix requires co-ordination with the OpenLDAP people. Either >> they 1) remove all strange code for parsing ciphers for GnuTLS and only >> use gnutls_priority_set_direct on the TLS_CIPHER_SUITE string, or 2) >> they introduce a new configuration keyword TLS_PRIORITY that is is sent >> to GnuTLS's priority functions. Given that TLS_CIPHER_SUITE accepts >> OpenSSL strings like 'HIGH:+SSLv2' I believe that matches GnuTLS >> priority strings, so I would recommend 1). And improve the >> documentation to point at, e.g., gnutls_priority_init(3) or the GnuTLS >> manual in the OpenLDAP documentation. > > Sounds like we should do (1). There was no such API in GnuTLS when our > support was written, which is why we had to go to the trouble of parsing > the cipher suites ourselves. I'm fine with ripping that all out, if > someone will tell us what minimum version of GnuTLS provides the new API. Simon? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5887) Fix GnuTLS support for TLS_CIPHER_SUITE
by hyc＠symas.com 14 Jan '09

14 Jan '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.13 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510346 > > Summary from Simon Josefsson: > > A proper fix requires co-ordination with the OpenLDAP people. Either > they 1) remove all strange code for parsing ciphers for GnuTLS and only > use gnutls_priority_set_direct on the TLS_CIPHER_SUITE string, or 2) > they introduce a new configuration keyword TLS_PRIORITY that is is sent > to GnuTLS's priority functions. Given that TLS_CIPHER_SUITE accepts > OpenSSL strings like 'HIGH:+SSLv2' I believe that matches GnuTLS > priority strings, so I would recommend 1). And improve the > documentation to point at, e.g., gnutls_priority_init(3) or the GnuTLS > manual in the OpenLDAP documentation. Sounds like we should do (1). There was no such API in GnuTLS when our support was written, which is why we had to go to the trouble of parsing the cipher suites ourselves. I'm fine with ripping that all out, if someone will tell us what minimum version of GnuTLS provides the new API. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5853) LDAP search crashes when chasing multiple referrals
by jsafrane＠redhat.com 14 Jan '09

14 Jan '09

This is a multi-part message in MIME format. --------------090400040509090303060604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ando(a)sys-net.it wrote: > jsafrane(a)redhat.com wrote: > >> Following ldapsearch crashes when referral chasing is enabled in very unusual >> environment with many AD servers referring to each other (I had to increase >> refhoplimit to chase all the referrals). > > Thanks for the detailed report. However, IMHO, automatic referral > chasing Is Broken. Clients should explicitly chase them, possibly > providing some interactive means for rebinding. This is what is > currently done, for example, by slapd when using slapo-chain(5), and > what should be done by proxy backends as well. nss_ldap does not have an option to chase referrals, it depends on ldap libraries to do the dirty job. I think that referral chasing in OpenLDAP libraries works pretty well apart my crash. Is there anything I am not aware of? Instead adding new features to nss_ldap, it would be better to fix OpenLDAP, more applications would benefit from that. I tried to work around the crash, see patch attached (apply to current 2.4 branch in CVS). I was not able to prevent deleting connections during referral chasing (I admit I got lost in the code and various code paths). So I added very simple mechanism to detect possibly freed connection and restart the loop in wait4msg(). It seems to help in my scenario. Jan --------------090400040509090303060604 Content-Type: text/plain; name="openldap-2.4-refer-crash.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="openldap-2.4-refer-crash.patch" Index: libraries/libldap/ldap-int.h =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/libldap/ldap-int.h,v retrieving revision 1.168.2.9 diff -u -r1.168.2.9 ldap-int.h --- libraries/libldap/ldap-int.h 8 Nov 2008 00:14:45 -0000 1.168.2.9 +++ libraries/libldap/ldap-int.h 14 Jan 2009 14:54:09 -0000 @@ -401,6 +401,7 @@ LDAPConn *ld_defconn; /* default connection */ LDAPConn *ld_conns; /* list of server connections */ + int ld_conns_version; /* unique id tracking deletions in ld_conns list */ void *ld_selectinfo; /* platform specifics for select */ }; #define LDAP_VALID(ld) ( (ld)->ld_valid == LDAP_VALID_SESSION ) Index: libraries/libldap/request.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/libldap/request.c,v retrieving revision 1.125.2.12 diff -u -r1.125.2.12 request.c --- libraries/libldap/request.c 8 Nov 2008 01:15:17 -0000 1.125.2.12 +++ libraries/libldap/request.c 14 Jan 2009 14:54:09 -0000 @@ -697,6 +698,7 @@ } prevlc = tmplc; } + ld->ld_conns_version++; #ifdef LDAP_R_COMPILE ldap_pvt_thread_mutex_unlock( &ld->ld_conn_mutex ); #endif Index: libraries/libldap/result.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/libldap/result.c,v retrieving revision 1.124.2.14 diff -u -r1.124.2.14 result.c --- libraries/libldap/result.c 10 Nov 2008 17:39:16 -0000 1.124.2.14 +++ libraries/libldap/result.c 14 Jan 2009 14:54:09 -0000 @@ -396,6 +396,7 @@ if ( lc->lconn_status == LDAP_CONNST_CONNECTED && ldap_is_read_ready( ld, lc->lconn_sb ) ) { + int version = ld->ld_conns_version; #ifdef LDAP_R_COMPILE ldap_pvt_thread_mutex_unlock( &ld->ld_conn_mutex ); #endif @@ -403,12 +404,12 @@ #ifdef LDAP_R_COMPILE ldap_pvt_thread_mutex_lock( &ld->ld_conn_mutex ); #endif - if ( lc == NULL ) { + if ( version != ld->ld_conns_version || lc == NULL ) { /* if lc gets free()'d, * there's no guarantee - * lc->lconn_next is still + * lc or lc->lconn_next is still * sane; better restart - * (ITS#4405) */ + * (ITS#4405, ITS#5853) */ lc = ld->ld_conns; /* don't get to next conn! */ --------------090400040509090303060604--

1 0

(ITS#5887) Fix GnuTLS support for TLS_CIPHER_SUITE
by quanah＠OpenLDAP.org 14 Jan '09

14 Jan '09

Full_Name: Quanah Gibson-Mount Version: 2.4.13 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510346 Summary from Simon Josefsson: A proper fix requires co-ordination with the OpenLDAP people. Either they 1) remove all strange code for parsing ciphers for GnuTLS and only use gnutls_priority_set_direct on the TLS_CIPHER_SUITE string, or 2) they introduce a new configuration keyword TLS_PRIORITY that is is sent to GnuTLS's priority functions. Given that TLS_CIPHER_SUITE accepts OpenSSL strings like 'HIGH:+SSLv2' I believe that matches GnuTLS priority strings, so I would recommend 1). And improve the documentation to point at, e.g., gnutls_priority_init(3) or the GnuTLS manual in the OpenLDAP documentation. /Simon

1 0

Re: (ITS#5886) epoll issues with lost connections
by quanah＠zimbra.com 13 Jan '09

13 Jan '09

--On Tuesday, January 13, 2009 6:25 PM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, January 13, 2009 9:04 PM +0000 openldap-its(a)OpenLDAP.org > wrote: > > Actually, this appears to be a kernel/epoll bug. Adding a 10000 > microsecond (.01 second) sleep to my script makes it so that slapd never > times out accepting connections. If I remove the sleep, slapd stops > accepting connections for about a 5-10 second period of time. It appears > entirely related to "connection lost" type of connections, because adding > an unbind statement also never triggers the issue. As a side note, however, LDAPI was unsable after about 200 connections with this script until the connection handling was patched. After that, it worked without any sleep in place. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5886) epoll issues with lost connections
by quanah＠zimbra.com 13 Jan '09

13 Jan '09

--On Tuesday, January 13, 2009 9:04 PM +0000 openldap-its(a)OpenLDAP.org wrote: Actually, this appears to be a kernel/epoll bug. Adding a 10000 microsecond (.01 second) sleep to my script makes it so that slapd never times out accepting connections. If I remove the sleep, slapd stops accepting connections for about a 5-10 second period of time. It appears entirely related to "connection lost" type of connections, because adding an unbind statement also never triggers the issue. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5886) epoll issues with lost connections
by quanah＠zimbra.com 13 Jan '09

13 Jan '09

Full_Name: Quanah Gibson-Mount Version: 2.4.13 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) When OpenLDAP is built on a system with epoll instead of select, it loses the ability to properly clean up those connections, as for epoll this is a separate event. slapd needs to be fixed to handle this case when epoll is used. It's fairly trivial to trigger it, simply write a script that does lots of searches and closes the connection without unbinding. This will cause slapd to eventually hang and stop accepting connections for a few seconds.

1 0

Re: (ITS#5885) TLS/SSL error from client
by quanah＠zimbra.com 13 Jan '09

13 Jan '09

--On Monday, January 12, 2009 5:54 PM +0000 bejnet(a)yahoo.com wrote: > Full_Name: Bejoy > Version: 2.4.11 > OS: gNewSense Gnu/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.211.200.129) > > > Hi > > I am having some TLS/SSL issues for connecting with ldapsearch from > clients. While using openssl to check the certificates - the OpenLDAP > server responds properly. But when ldapsearch uses the same certificates, > server throws error on improper TLS handshake. Usage questions should be sent to the openldap-software(a)openldap.org list. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2009