openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

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

Re: (ITS#5884) disclose ACL not safe on non-leaf objects
by andrew.findlay＠skills-1st.co.uk 13 Jan '09

13 Jan '09

On Mon, Jan 12, 2009 at 07:47:20PM +0000, hyc(a)symas.com wrote: > > For example, if I have a DIT like this: > > > > dc=example,dc=org--+ > > +--dc=a--+ > > | +--dc=people--+ > > | +--cn=a1 > > | > > +--dc=b--+ > > +--dc=people--+ > > +--cn=b1 > > > > and I give read access on dc=example,dc=org (base) > > and on dc=a,dc=example,dc=org (subtree) > > and dc=people,dc=b,dc=example,dc=org (subtree) > > but no access at all on dc=b,dc=example,dc=org > > then I would not expect to be able to read the cn=b1 entry, as doing so would > > expose the existence of dc=b. > > > > What actually happens is that any attempt to read dc=b itself returns > > correctly as if the entry does not exist, but a simple subtree search > > happily returns cn=b1. > > Which is the natural outcome of granting read access to the dc=people subtree. > > If you want the server's behavior to make sense, then give it ACLs that make > sense. Agreed - for some value of "sense" :-) I simplified the example to the minimum that would demonstrate the behaviour, so it may seem like an odd thing to do in the first place. There are several possible reasons to want a non-discoverable entry to block discovery of entries beneath it. One example would be an organisation that is preparing to open a new department: it needs to populate the department data with entries carrying the access markers that will be used in production, but have the whole lot remain invisible to users and applications until everything is ready. The obvious way to implement this is to use access-control to make the root of the new subtree non-discoverable, but it only works if the non-discoverability extends to the whole subtree. This is effectively the scenario that I described in the ITS. I want to make the discoverability of entries dependent on the value of an attribute in a parent node, but I cannot see a way of doing it using the existing ACL syntax and behaviour. The closest I have got so far is to use the set syntax in a deny rule: # Blockers - look for exampleVisibility=block in all parent entries # access to * by set="this/-*/exampleVisibility & [block]" none by * break This allows any entry to block its subtree to *all* users by setting exampleVisibility=block There does not seem to be any way to make the block dependent on *who* is requesting access, as sets are only valid in the 'by <who>' part of the rule. Something like this might work if sets could be used in the <what> part: access to set="this/-*/exampleVisibility & [internet]" attrs="entry,children" by * read access to set="this/-*/exampleVisibility & [users]" attrs="entry,children" by users read Ah - no it would not work, as it would permit read if *any* superior entry permits read. I want to be sure that *all* superior entries permit read. Foiled again! Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs