Logged in as guest
Viewing Software Bugs/7143 Full headers
Major security issue: yes no
Notes: fixed in master fixed in RE24 Notification:
Date: Sun, 29 Jan 2012 17:35:52 +0000 From: mattias@centaurix.com To: openldap-its@OpenLDAP.org Subject: Assertion error (crash); using relay backend and translucent overlay
Full_Name: Mattias Andersson Version: 2.4.25 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.182.107.220) I have configured a proxy server using both the relay backend and the translucent overlay: backend hdb backend relay database hdb directory /var/lib/ldap suffix "dc=foo,dc=example,dc=com" rootdn "cn=admin,dc=foo,dc=example,dc=com" rootpw secret index objectClass eq database relay suffix "dc=example,dc=com" overlay rwm rwm-suffixmassage "dc=foo,dc=example,dc=com" overlay translucent uri ldap://ldap.example.com This configuration makes it possible for me to override attributes in the remote ldap directory and at the same time extend the local directory with new entries. This has been tested and works for authorization in a linux environment. If I issue an LDAP search query, as follows, ldapsearch -x -b dc=chalmers,dc=se -s base "(objectClass=*)" 1.1 it will yield the following debug output: slapd starting conn=1000 fd=11 ACCEPT from IP=127.0.0.1:36838 (IP=0.0.0.0:389) conn=1000 op=0 BIND dn="" method=128 conn=1000 op=0 RESULT tag=97 err=0 text= conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" conn=1000 op=1 SRCH attr=1.1 conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self. conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=1000 op=2 UNBIND conn=1000 fd=11 closed However, if I query the server using the Softerra LDAP Administrator software (Windows), the slapd daemon crashes with an assertion error: slapd starting conn=1000 fd=11 ACCEPT from IP=11.22.33.44:54752 (IP=0.0.0.0:389) conn=1000 op=0 BIND dn="" method=128 conn=1000 op=0 RESULT tag=97 err=0 text= conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" conn=1000 op=1 SRCH attr=1.1 conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self. slapd: /build/buildd/openldap-2.4.25/servers/slapd/attr.c:236: attr_dup2: Assertion `j < i' failed. Aborted This is a security vulnerability, since it would be enough to send an LDAP query to take down the server. Mattias
Date: Mon, 30 Jan 2012 17:27:05 -0800 From: Howard Chu <hyc@symas.com> To: mattias@centaurix.com CC: openldap-its@openldap.org Subject: Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
mattias@centaurix.com wrote: > Full_Name: Mattias Andersson > Version: 2.4.25 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.182.107.220) Please provide a full gdb backtrace from the assertion failure. I've reproduced this configuration locally but see no crash using ldapsearch. I don't have the Softerra browser. > I have configured a proxy server using both the relay backend and the > translucent overlay: > > backend hdb > backend relay > > database hdb > directory /var/lib/ldap > suffix "dc=foo,dc=example,dc=com" > rootdn "cn=admin,dc=foo,dc=example,dc=com" > rootpw secret > index objectClass eq > > database relay > suffix "dc=example,dc=com" > overlay rwm > rwm-suffixmassage "dc=foo,dc=example,dc=com" > overlay translucent > uri ldap://ldap.example.com > > This configuration makes it possible for me to override attributes in the remote > ldap directory and at the same time extend the local directory with new entries. > This has been tested and works for authorization in a linux environment. > > If I issue an LDAP search query, as follows, > > ldapsearch -x -b dc=chalmers,dc=se -s base "(objectClass=*)" 1.1 > > it will yield the following debug output: > > slapd starting > conn=1000 fd=11 ACCEPT from IP=127.0.0.1:36838 (IP=0.0.0.0:389) > conn=1000 op=0 BIND dn="" method=128 > conn=1000 op=0 RESULT tag=97 err=0 text= > conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 > filter="(objectClass=*)" > conn=1000 op=1 SRCH attr=1.1 > conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self. > conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= > conn=1000 op=2 UNBIND > conn=1000 fd=11 closed > > However, if I query the server using the Softerra LDAP Administrator software > (Windows), the slapd daemon crashes with an assertion error: > > slapd starting > conn=1000 fd=11 ACCEPT from IP=11.22.33.44:54752 (IP=0.0.0.0:389) > conn=1000 op=0 BIND dn="" method=128 > conn=1000 op=0 RESULT tag=97 err=0 text= > conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 > filter="(objectClass=*)" > conn=1000 op=1 SRCH attr=1.1 > conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self. > slapd: /build/buildd/openldap-2.4.25/servers/slapd/attr.c:236: attr_dup2: > Assertion `j< i' failed. > Aborted > > This is a security vulnerability, since it would be enough to send an LDAP query > to take down the server. We don't consider crashes/DOS to be a security vulnerability. A vulnerability is anything which allows users to see information they should not be allowed to see; in the case of a crash no information can be retrieved so all data is completely secure. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
To: "Howard Chu" <hyc@symas.com> Cc: openldap-its@openldap.org Subject: Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay Date: Tue, 31 Jan 2012 03:24:45 +0100 From: "Mattias Andersson" <mattias@centaurix.com>
------------hvfQvbIMuXxQGZ2Ols8tGf Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu <hyc@symas.com> wrote: > mattias@centaurix.com wrote: >> Full_Name: Mattias Andersson >> Version: 2.4.25 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.182.107.220) > > Please provide a full gdb backtrace from the assertion failure. I've > reproduced this configuration locally but see no crash using ldapsearch. > I don't have the Softerra browser. Ok, see attachment. The problem is not reproducible with ldapsearch. >> This is a security vulnerability, since it would be enough to send an >> LDAP query >> to take down the server. > > We don't consider crashes/DOS to be a security vulnerability. A > vulnerability is anything which allows users to see information they > should not be allowed to see; in the case of a crash no information can > be retrieved so all data is completely secure. You're right, but it's a service vulnerability -- the server must be online in order for our users to be able to log in. In any case, I have a different configuration now, that solves the problem in another way (by using two separate local databases -- one for the translucent overlay and one for the subordinate directory.) Another problem with the previous configuration was that I was getting "user modification of overlay database not permitted" errors when using ldapadd/ldapmodify (seems the translucent overlay can not be stacked with the rwm overlay.) Mattias ------------hvfQvbIMuXxQGZ2Ols8tGf Content-Disposition: attachment; filename=gdb-slapd.txt Content-Type: text/plain; name="gdb-slapd.txt" Content-Transfer-Encoding: Quoted-Printable GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.= html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copyin= g" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>. (gdb) handle SIG33 pass nostop noprint Signal Stop Print Pass to program Description SIG33 No No Yes Real-time event 33 (gdb) set pagination 0 (gdb) attach 4625 Attaching to process 4625 ptrace: No such process. (gdb) attach 4824 Attaching to process 4824 ptrace: No such process. (gdb) attach 4864 Attaching to process 4864 Reading symbols from /usr/sbin/slapd...Reading symbols from /usr/lib/deb= ug/usr/sbin/slapd...done. done. Reading symbols from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2...(no = debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 Reading symbols from /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2...(no de= bugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 Reading symbols from /usr/lib/libslp.so.1...(no debugging symbols found)= ...done. Loaded symbols for /usr/lib/libslp.so.1 Reading symbols from /usr/lib/x86_64-linux-gnu/libsasl2.so.2...(no debug= ging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libsasl2.so.2 Reading symbols from /lib/x86_64-linux-gnu/libcrypt.so.1...(no debugging= symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libcrypt.so.1 Reading symbols from /usr/lib/libltdl.so.7...(no debugging symbols found= )...done. Loaded symbols for /usr/lib/libltdl.so.7 Reading symbols from /lib/x86_64-linux-gnu/libwrap.so.0...(no debugging = symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libwrap.so.0 Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...(no debuggi= ng symbols found)...done. [Thread debugging using libthread_db enabled] [New Thread 0x7f66e2c7d700 (LWP 4865)] Loaded symbols for /lib/x86_64-linux-gnu/libpthread.so.0 Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging sym= bols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libc.so.6 Reading symbols from /lib/x86_64-linux-gnu/libresolv.so.2...(no debuggin= g symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libresolv.so.2 Reading symbols from /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2...(no= debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 Reading symbols from /usr/lib/x86_64-linux-gnu/libgnutls.so.26...(no deb= ugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libgnutls.so.26 Reading symbols from /lib/x86_64-linux-gnu/libgcrypt.so.11...(no debuggi= ng symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libgcrypt.so.11 Reading symbols from /lib/x86_64-linux-gnu/libnsl.so.1...(no debugging s= ymb
Date: Mon, 30 Jan 2012 18:52:26 -0800 From: Howard Chu <hyc@symas.com> To: Mattias Andersson <mattias@centaurix.com> CC: openldap-its@openldap.org Subject: Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
Mattias Andersson wrote: > On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc@symas.com> wrote: > >> mattias@centaurix.com wrote: >>> Full_Name: Mattias Andersson >>> Version: 2.4.25 >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.182.107.220) >> >> Please provide a full gdb backtrace from the assertion failure. I've >> reproduced this configuration locally but see no crash using ldapsearch. >> I don't have the Softerra browser. > > Ok, see attachment. The problem is not reproducible with ldapsearch. The assertion leads me to believe that one of the values received from the remote server violated the attribute syntax, and so the value failed in the normalizer on the local slapd. What is the remote server? It's a bit strange that changing the configuration, but leaving the remote server unchanged, avoids the problem. > In any case, I have a different configuration now, that solves the problem > in another way (by using two separate local databases -- one for the > translucent overlay and one for the subordinate directory.) Another > problem with the previous configuration was that I was getting "user > modification of overlay database not permitted" errors when using > ldapadd/ldapmodify (seems the translucent overlay can not be stacked with > the rwm overlay.) > > Mattias -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Date: Mon, 30 Jan 2012 18:56:06 -0800 From: Howard Chu <hyc@symas.com> To: Mattias Andersson <mattias@centaurix.com> CC: openldap-its@openldap.org Subject: Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
This is a multi-part message in MIME format. --------------090902020105000306040907 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Mattias Andersson wrote: > On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc@symas.com> wrote: > >> mattias@centaurix.com wrote: >>> Full_Name: Mattias Andersson >>> Version: 2.4.25 >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.182.107.220) >> >> Please provide a full gdb backtrace from the assertion failure. I've >> reproduced this configuration locally but see no crash using ldapsearch. >> I don't have the Softerra browser. > > Ok, see attachment. The problem is not reproducible with ldapsearch. Please see if the attached patch alters the behavior. Thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------090902020105000306040907 Content-Type: text/plain; charset=UTF-8; name="diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="diff.txt" diff --git a/servers/slapd/overlays/rwm.c b/servers/slapd/overlays/rwm.c index 05cf98a..37e52cb 100644 --- a/servers/slapd/overlays/rwm.c +++ b/servers/slapd/overlays/rwm.c @@ -1277,7 +1277,7 @@ rwm_attrs( Operation *op, SlapReply *rs, Attribute** a_first, int stripEntryDN ) NULL ); if ( rc != LDAP_SUCCESS ) { - BER_BVZERO( &(*ap)->a_nvals[i] ); + ber_dupbv( &(*ap)->a_nvals[i], &(*ap)->a_vals[i] ); } } BER_BVZERO( &(*ap)->a_nvals[i] ); --------------090902020105000306040907--
To: "Howard Chu" <hyc@symas.com> Cc: openldap-its@openldap.org Subject: Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay Date: Tue, 31 Jan 2012 11:41:49 +0100 From: "Mattias Andersson" <mattias@centaurix.com>
On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc@symas.com> wrote: > Mattias Andersson wrote: >> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc@symas.com> wrote: >> >>> Please provide a full gdb backtrace from the assertion failure. I've >>> reproduced this configuration locally but see no crash using >>> ldapsearch. >>> I don't have the Softerra browser. >> >> Ok, see attachment. The problem is not reproducible with ldapsearch. > > Please see if the attached patch alters the behavior. Thanks. I'm getting an error that MozNSS is not found when I run ./configure. Mattias
Date: Tue, 31 Jan 2012 03:07:07 -0800 From: Howard Chu <hyc@symas.com> To: mattias@centaurix.com CC: openldap-its@openldap.org Subject: Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
mattias@centaurix.com wrote: > On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu<hyc@symas.com> wrote: > >> Mattias Andersson wrote: >>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc@symas.com> wrote: >>> >>>> Please provide a full gdb backtrace from the assertion failure. I've >>>> reproduced this configuration locally but see no crash using >>>> ldapsearch. >>>> I don't have the Softerra browser. >>> >>> Ok, see attachment. The problem is not reproducible with ldapsearch. >> >> Please see if the attached patch alters the behavior. Thanks. > > I'm getting an error that MozNSS is not found when I run ./configure. Are you building the latest source? You can use --with-tls=openssl (or gnutls) to explicitly choose. But it shouldn't be defaulting to MozNSS, unless perhaps you're on a Redhat or Fedora system. If worse comes to worse, you can configure --without-tls just to run this test. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Date: Fri, 03 Feb 2012 11:26:01 -0800 From: Quanah Gibson-Mount <quanah@zimbra.com> To: mattias@centaurix.com, openldap-its@openldap.org Subject: Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
--On Tuesday, January 31, 2012 10:41 AM +0000 mattias@centaurix.com wrote: > On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc@symas.com> wrote: > >> Mattias Andersson wrote: >>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc@symas.com> wrote: >>> >>>> Please provide a full gdb backtrace from the assertion failure. I've >>>> reproduced this configuration locally but see no crash using >>>> ldapsearch. >>>> I don't have the Softerra browser. >>> >>> Ok, see attachment. The problem is not reproducible with ldapsearch. >> >> Please see if the attached patch alters the behavior. Thanks. > > I'm getting an error that MozNSS is not found when I run ./configure. > > Mattias Hi Mattias, Any update? We would like to get a fix for this into OpenLDAP 2.4.29 if possible. Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
To: openldap-its@openldap.org Subject: Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay Date: Fri, 03 Feb 2012 22:23:41 +0100 From: "Mattias Andersson" <mattias@centaurix.com>
On Fri, 03 Feb 2012 20:26:01 +0100, Quanah Gibson-Mount <quanah@zimbra.com> wrote: > Hi Mattias, > > Any update? We would like to get a fix for this into OpenLDAP 2.4.29 if > possible. I'm having some problems with the BDB library: 4f2c4dd3 bdb_back_initialize: BDB library version mismatch: expected Berkeley DB 5.1.29: (October 25, 2011), got Berkeley DB 5.1.25: (January 28, 2011) I'll see if I can figure it out. Mattias
To: "Quanah Gibson-Mount" <quanah@zimbra.com> Subject: Re: ~*~ [spam] Re: (ITS#7143) Assertion error (crash); using relay backend and translucent ove Date: Fri, 03 Feb 2012 22:35:03 +0100 Cc: "openldap-its@openldap.org" <openldap-its@openldap.org> From: "Mattias Andersson" <mattias@centaurix.com>
On Fri, 03 Feb 2012 22:24:36 +0100, Quanah Gibson-Mount <quanah@zimbra.com> wrote: > --On Friday, February 03, 2012 10:19 PM +0100 Mattias Andersson > <mattias@centaurix.com> wrote: > >> I'm having some problems with the BDB library: >> >> 4f2c4dd3 bdb_back_initialize: BDB library version mismatch: expected >> Berkeley DB 5.1.29: (October 25, 2011), got Berkeley DB 5.1.25: (January >> 28, 2011) > > You built against BDB 5.1.29, but you have BDB 5.1.25 installed. This > would definitely happen if one system was updated when the other was not. Actually I did install BDB 5.1.29, but probably I need to adjust some library path or change a symlink. Mattias
To: openldap-its@openldap.org, "Quanah Gibson-Mount" <quanah@zimbra.com> Subject: Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay Date: Fri, 03 Feb 2012 23:15:23 +0100 From: "Mattias Andersson" <mattias@centaurix.com>
On Fri, 03 Feb 2012 20:26:01 +0100, Quanah Gibson-Mount <quanah@zimbra.com> wrote: > --On Tuesday, January 31, 2012 10:41 AM +0000 mattias@centaurix.com > wrote: > >> On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc@symas.com> wrote: >> >>> Mattias Andersson wrote: >>>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc@symas.com> wrote: >>>> >>>>> Please provide a full gdb backtrace from the assertion failure. I've >>>>> reproduced this configuration locally but see no crash using >>>>> ldapsearch. >>>>> I don't have the Softerra browser. >>>> >>>> Ok, see attachment. The problem is not reproducible with ldapsearch. >>> >>> Please see if the attached patch alters the behavior. Thanks. >> >> I'm getting an error that MozNSS is not found when I run ./configure. >> >> Mattias > > Hi Mattias, > > Any update? We would like to get a fix for this into OpenLDAP 2.4.29 if > possible. Ok, I didn't apply the patch yet, but now I'm getting a different error than before (before I was using OpenLDAP 2.4.25 from the Ubuntu package repository): cornelian build_unix # /usr/local/libexec/slapd -d 256 -f /etc/ldap/slapd.conf 4f2c5a69 @(#) $OpenLDAP: slapd 2.4.28 (Feb 1 2012 02:31:50) $ root@cornelian:/root/openldap/openldap-2.4.28/servers/slapd 4f2c5a69 hdb_db_open: database "dc=rss,dc=chalmers,dc=se": unclean shutdown detected; attempting recovery. 4f2c5a69 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable 4f2c5a69 slapd starting 4f2c5ac2 conn=1000 fd=12 ACCEPT from IP=127.0.0.1:39354 (IP=0.0.0.0:389) 4f2c5ac2 conn=1000 op=0 BIND dn="" method=128 4f2c5ac2 conn=1000 op=0 RESULT tag=97 err=0 text= 4f2c5ac2 conn=1000 op=1 SRCH base="dc=chalmers,dc=se" scope=2 deref=0 filter="(objectClass=*)" 4f2c5ac2 conn=1000 op=1 SRCH attr=1.1 /usr/local/libexec/slapd: symbol lookup error: /usr/local/libexec/openldap/back_ldap-2.4.so.2: undefined symbol: ldap_get_message_ber This error also happens with ldapsearch. Mattias
Date: Fri, 03 Feb 2012 14:32:30 -0800 From: Quanah Gibson-Mount <quanah@zimbra.com> To: Mattias Andersson <mattias@centaurix.com>, openldap-its@openldap.org Subject: Re: ~*~ [spam] Re: (ITS#7143) Assertion error (crash); using relay backend and translucent ove
--On Friday, February 03, 2012 11:15 PM +0100 Mattias Andersson <mattias@centaurix.com> wrote: > On Fri, 03 Feb 2012 20:26:01 +0100, Quanah Gibson-Mount > <quanah@zimbra.com> wrote: > >> --On Tuesday, January 31, 2012 10:41 AM +0000 mattias@centaurix.com >> wrote: >> >>> On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc@symas.com> wrote: >>> >>>> Mattias Andersson wrote: >>>>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc@symas.com> wrote: >>>>> >>>>>> Please provide a full gdb backtrace from the assertion failure. I've >>>>>> reproduced this configuration locally but see no crash using >>>>>> ldapsearch. >>>>>> I don't have the Softerra browser. >>>>> >>>>> Ok, see attachment. The problem is not reproducible with ldapsearch. >>>> >>>> Please see if the attached patch alters the behavior. Thanks. >>> >>> I'm getting an error that MozNSS is not found when I run ./configure. >>> >>> Mattias >> >> Hi Mattias, >> >> Any update? We would like to get a fix for this into OpenLDAP 2.4.29 if >> possible. > > Ok, I didn't apply the patch yet, but now I'm getting a different error > than before (before I was using OpenLDAP 2.4.25 from the Ubuntu package > repository): > > cornelian build_unix # /usr/local/libexec/slapd -d 256 -f > /etc/ldap/slapd.conf > 4f2c5a69 @(#) $OpenLDAP: slapd 2.4.28 (Feb 1 2012 02:31:50) $ Why are you running 2.4.28? I specifically said to download the current source from RE24, which at this time includes the patch for your issue. When you rebuild, you must replace all the openldap packages, including the OpenLDAP libraries, not just the slapd binary, etc. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
To: openldap-its@openldap.org, "Quanah Gibson-Mount" <quanah@zimbra.com> Subject: Re: ~*~ [spam] Re: (ITS#7143) Assertion error (crash); using relay backend and translucent ove From: "Mattias Andersson" <mattias@centaurix.com> Date: Sat, 04 Feb 2012 00:42:10 +0100
On Fri, 03 Feb 2012 23:32:30 +0100, Quanah Gibson-Mount <quanah@zimbra.com> wrote: > --On Friday, February 03, 2012 11:15 PM +0100 Mattias Andersson > <mattias@centaurix.com> wrote: > >> On Fri, 03 Feb 2012 20:26:01 +0100, Quanah Gibson-Mount >> <quanah@zimbra.com> wrote: >> >>> --On Tuesday, January 31, 2012 10:41 AM +0000 mattias@centaurix.com >>> wrote: >>> >>>> On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc@symas.com> wrote: >>>> >>>>> Mattias Andersson wrote: >>>>>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc@symas.com> >>>>>> wrote: >>>>>> >>>>>>> Please provide a full gdb backtrace from the assertion failure. >>>>>>> I've >>>>>>> reproduced this configuration locally but see no crash using >>>>>>> ldapsearch. >>>>>>> I don't have the Softerra browser. >>>>>> >>>>>> Ok, see attachment. The problem is not reproducible with ldapsearch. >>>>> >>>>> Please see if the attached patch alters the behavior. Thanks. >>>> >>>> I'm getting an error that MozNSS is not found when I run ./configure. >>>> >>>> Mattias >>> >>> Hi Mattias, >>> >>> Any update? We would like to get a fix for this into OpenLDAP 2.4.29 >>> if >>> possible. >> >> Ok, I didn't apply the patch yet, but now I'm getting a different error >> than before (before I was using OpenLDAP 2.4.25 from the Ubuntu package >> repository): >> >> cornelian build_unix # /usr/local/libexec/slapd -d 256 -f >> /etc/ldap/slapd.conf >> 4f2c5a69 @(#) $OpenLDAP: slapd 2.4.28 (Feb 1 2012 02:31:50) $ > > Why are you running 2.4.28? I specifically said to download the current > source from RE24, which at this time includes the patch for your issue. > When you rebuild, you must replace all the openldap packages, including > the OpenLDAP libraries, not just the slapd binary, etc. Ok, I downloaded the current source from RE24 (snapshot), but I'm still getting the error that I reported initially: cornelian openldap-ad04676 # /usr/local/libexec/slapd -d 256 -f /etc/ldap/slapd.conf 4f2c6fe0 @(#) $OpenLDAP: slapd 2.4.29 (Feb 4 2012 00:34:39) $ root@cornelian:/root/openldap/openldap-ad04676/servers/slapd 4f2c6fe0 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable 4f2c6fe0 slapd starting 4f2c6fe7 conn=1000 fd=12 ACCEPT from IP=83.185.96.215:52240 (IP=0.0.0.0:389) 4f2c6fe7 conn=1000 op=0 BIND dn="" method=128 4f2c6fe7 conn=1000 op=0 RESULT tag=97 err=0 text= 4f2c6fe7 conn=1000 op=1 SRCH base="dc=chalmers,dc=se" scope=0 deref=0 filter="(objectClass=*)" 4f2c6fe7 conn=1000 op=1 SRCH attr=1.1 4f2c6fe7 conn=1000 op=1: back-relay for DN="dc=chalmers,dc=se" would call self. slapd: attr.c:236: attr_dup2: Assertion `j < i' failed. Aborted Mattias
To: openldap-its@openldap.org, "Quanah Gibson-Mount" <quanah@zimbra.com> Subject: Re: ~*~ [spam] Re: (ITS#7143) Assertion error (crash); using relay backend and translucent ove Date: Sat, 04 Feb 2012 00:47:42 +0100 From: "Mattias Andersson" <mattias@centaurix.com>
On Sat, 04 Feb 2012 00:42:10 +0100, Mattias Andersson <mattias@centaurix.com> wrote: > On Fri, 03 Feb 2012 23:32:30 +0100, Quanah Gibson-Mount Ok, I downloaded > the current source from RE24 (snapshot), but I'm still getting the error > that I reported initially: I can confirm that the source does indeed include the patch, so the patch did not fix the problem. Mattias
Date: Fri, 03 Feb 2012 15:51:06 -0800 From: Quanah Gibson-Mount <quanah@zimbra.com> To: Mattias Andersson <mattias@centaurix.com>, openldap-its@openldap.org Subject: Re: ~*~ [spam] Re: ~*~ [spam] Re: (ITS#7143) Assertion error (crash); using relay backend and
--On Saturday, February 04, 2012 12:47 AM +0100 Mattias Andersson <mattias@centaurix.com> wrote: > On Sat, 04 Feb 2012 00:42:10 +0100, Mattias Andersson > <mattias@centaurix.com> wrote: > >> On Fri, 03 Feb 2012 23:32:30 +0100, Quanah Gibson-Mount Ok, I downloaded >> the current source from RE24 (snapshot), but I'm still getting the >> error that I reported initially: > > I can confirm that the source does indeed include the patch, so the patch > did not fix the problem. Thanks for the confirmation, unfortunate that patch didn't work. Investigation will continue. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Date: Fri, 03 Feb 2012 16:59:49 -0800 From: Howard Chu <hyc@symas.com> To: mattias@centaurix.com CC: openldap-its@openldap.org Subject: Re: ~*~ [spam] Re: (ITS#7143) Assertion error (crash); using relay backend and translucent ove
mattias@centaurix.com wrote: > On Sat, 04 Feb 2012 00:42:10 +0100, Mattias Andersson > <mattias@centaurix.com> wrote: > >> On Fri, 03 Feb 2012 23:32:30 +0100, Quanah Gibson-Mount Ok, I downloaded >> the current source from RE24 (snapshot), but I'm still getting the error >> that I reported initially: > > I can confirm that the source does indeed include the patch, so the patch > did not fix the problem. OK, we need to know exactly what the difference is between the ldapsearch query and the browser query. Can you please run slapd -d7 and record first the ldapsearch query and then the browser query and post the output for each of those? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
To: "Howard Chu" <hyc@symas.com> Cc: openldap-its@openldap.org Subject: Re: ~*~ [spam] Re: (ITS#7143) Assertion error (crash); using relay backend and translucent ove Date: Sat, 04 Feb 2012 02:37:52 +0100 From: "Mattias Andersson" <mattias@centaurix.com>
------------jL0Q7OrKgMl1NhGUUvXpqG Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Sat, 04 Feb 2012 01:59:49 +0100, Howard Chu <hyc@symas.com> wrote: > mattias@centaurix.com wrote: >> On Sat, 04 Feb 2012 00:42:10 +0100, Mattias Andersson >> <mattias@centaurix.com> wrote: >> >>> On Fri, 03 Feb 2012 23:32:30 +0100, Quanah Gibson-Mount Ok, I >>> downloaded >>> the current source from RE24 (snapshot), but I'm still getting the >>> error >>> that I reported initially: >> >> I can confirm that the source does indeed include the patch, so the >> patch >> did not fix the problem. > > OK, we need to know exactly what the difference is between the > ldapsearch query and the browser query. Can you please run slapd -d7 and > record first the ldapsearch query and then the browser query and post > the output for each of those? Attached the output from the two queries. Mattias ------------jL0Q7OrKgMl1NhGUUvXpqG Content-Disposition: attachment; filename=slapd-ldapsearch.log Content-Type: application/octet-stream; name="slapd-ldapsearch.log" Content-Transfer-Encoding: Base64 NGYyYzg5Zjggc2xhcGQgc3RhcnR1cDogaW5pdGlhdGVkLg0KNGYyYzg5ZjggYmFj a2VuZF9zdGFydHVwX29uZTogc3RhcnRpbmcgImNuPWNvbmZpZyINCjRmMmM4OWY4 IGNvbmZpZ19iYWNrX2RiX29wZW4NCjRmMmM4OWY4IGNvbmZpZ19idWlsZF9lbnRy eTogImNuPWNvbmZpZyINCjRmMmM4OWY4IGNvbmZpZ19idWlsZF9lbnRyeTogImNu PW1vZHVsZXswfSINCjRmMmM4OWY4IGNvbmZpZ19idWlsZF9lbnRyeTogImNuPXNj aGVtYSINCjRmMmM4OWY4ID4+PiBkbk5vcm1hbGl6ZTogPGNuPXswfWNvcmU+DQo0 ZjJjODlmOCA8PDwgZG5Ob3JtYWxpemU6IDxjbj17MH1jb3JlPg0KNGYyYzg5Zjgg Y29uZmlnX2J1aWxkX2VudHJ5OiAiY249ezB9Y29yZSINCjRmMmM4OWY4ID4+PiBk bk5vcm1hbGl6ZTogPGNuPXsxfWNvc2luZT4NCjRmMmM4OWY4IDw8PCBkbk5vcm1h bGl6ZTogPGNuPXsxfWNvc2luZT4NCjRmMmM4OWY4IGNvbmZpZ19idWlsZF9lbnRy eTogImNuPXsxfWNvc2luZSINCjRmMmM4OWY4ID4+PiBkbk5vcm1hbGl6ZTogPGNu PXsyfW5pcz4NCjRmMmM4OWY4IDw8PCBkbk5vcm1hbGl6ZTogPGNuPXsyfW5pcz4N CjRmMmM4OWY4IGNvbmZpZ19idWlsZF9lbnRyeTogImNuPXsyfW5pcyINCjRmMmM4 OWY4ID4+PiBkbk5vcm1hbGl6ZTogPGNuPXszfWluZXRvcmdwZXJzb24+DQo0ZjJj ODlmOCA8PDwgZG5Ob3JtYWxpemU6IDxjbj17M31pbmV0b3JncGVyc29uPg0KNGYy Yzg5ZjggY29uZmlnX2J1aWxkX2VudHJ5OiAiY249ezN9aW5ldG9yZ3BlcnNvbiIN CjRmMmM4OWY4IGNvbmZpZ19idWlsZF9lbnRyeTogIm9sY0RhdGFiYXNlPXstMX1m cm9udGVuZCINCjRmMmM4OWY4IGNvbmZpZ19idWlsZF9lbnRyeTogIm9sY0RhdGFi YXNlPXswfWNvbmZpZyINCjRmMmM4OWY4IGNvbmZpZ19idWlsZF9lbnRyeTogIm9s Y0RhdGFiYXNlPXsxfWhkYiINCjRmMmM4OWY4IGNvbmZpZ19idWlsZF9lbnRyeTog Im9sY0RhdGFiYXNlPXsyfXJlbGF5Ig0KNGYyYzg5ZjggY29uZmlnX2J1aWxkX2Vu dHJ5OiAib2xjT3ZlcmxheT17MH1yd20iDQo0ZjJjODlmOCBjb25maWdfYnVpbGRf ZW50cnk6ICJvbGNPdmVybGF5PXsxfXRyYW5zbHVjZW50Ig0KNGYyYzg5ZjggPT0+ IHRyYW5zbHVjZW50X2NmYWRkDQo0ZjJjODlmOCBjb25maWdfYnVpbGRfZW50cnk6 ICJvbGNEYXRhYmFzZT17MH1sZGFwIg0KNGYyYzg5ZjggY29uZmlnX2J1aWxkX2Vu dHJ5OiAib2xjT3ZlcmxheT17Mn1nbHVlIg0KNGYyYzg5ZjggYmFja2VuZF9zdGFy dHVwX29uZTogc3RhcnRpbmcgImRjPXJzcyxkYz1jaGFsbWVycyxkYz1zZSINCjRm MmM4OWY4IGhkYl9kYl9vcGVuOiAiZGM9cnNzLGRjPWNoYWxtZXJzLGRjPXNlIg0K NGYyYzg5ZjggaGRiX2RiX29wZW46IGRhdGFiYXNlICJkYz1yc3MsZGM9Y2hhbG1l cnMsZGM9c2UiOiBkYmVudl9vcGVuKC92YXIvbGliL2xkYXApLg0KNGYyYzg5Zjgg aGRiX21vbml0b3JfZGJfb3BlbjogbW9uaXRvcmluZyBkaXNhYmxlZDsgY29uZmln dXJlIG1vbml0b3IgZGF0YWJhc2UgdG8gZW5hYmxlDQo0ZjJjODlmOCBiYWNrZW5k X3N0YXJ0dXBfb25lOiBzdGFydGluZyAiZGM9Y2hhbG1lcnMsZGM9c2UiDQo0ZjJj ODlmOCA9PT4gdHJhbnNsdWNlbnRfZGJfb3Blbg0KNGYyYzg5ZjggYmFja2VuZF9z dGFydHVwX29uZTogc3RhcnRpbmcgImRjPWNoYWxtZXJzLGRjPXNlIg0KNGYyYzg5 ZjggbGRhcF9iYWNrX2RiX29wZW46IFVSST1sZGFwOi8vbGRhcC5jaGFsbWVycy5z ZQ0KNGYyYzg5Zjggc2xhcGQgc3RhcnRpbmcNCjRmMmM4OWZlIHNsYXBfbGlzdGVu ZXJfYWN0aXZhdGUoNyk6IA0KNGYyYzg5ZmUgPj4+IHNsYXBfbGlzdGVuZXIobGRh cDovLy8pDQo0ZjJjODlmZSBjb25uZWN0aW9uX2dldCgxMikNCjRmMmM4OWZlIGNv bm5lY3Rpb25fZ2V0KDEyKTogZ290IGNvbm5pZD0xMDAwDQo0ZjJjODlmZSBjb25u ZWN0aW9uX3JlYWQoMTIpOiBjaGVja2luZyBmb3IgaW5wdXQgb24gaWQ9MTAwMA0K YmVyX2dldF9uZXh0DQpsZGFwX3JlYWQ6IHdhbnQ9OCwgZ290PTgNCiAgMDAwMDog IDMwIDBjIDAyIDAxIDAxIDYwIDA3IDAyICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDAuLi4uYC4uICAgICAgICAgIA0KbGRhcF9yZWFkOiB3YW50PTYsIGdvdD02 DQogIDAwMDA6ICAwMSAwMyAwNCAwMCA4MCAwMCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAuLi4uLi4gICAgICAgICAgICANCmJlcl9nZXRfbmV4dDog dGFnIDB4MzAgbGVuIDEyIGNvbnRlbnRzOg0KNGYyYzg5ZmUgb3AgdGFnIDB4NjAs IHRpbWUgMTMyODMxODk3NA0KYmVyX2dldF9uZXh0DQpsZGFwX3JlYWQ6IHdhbnQ9 OCBlcnJvcj1SZXNvdXJjZSB0ZW1wb3JhcmlseSB1bmF2YWlsYWJsZQ0KNGYyYzg5 ZmUgY29ubj0xMDAwIG9wPTAgZG9fYmluZA0KYmVyX3NjYW5mIGZtdCAoe2ltdCkg YmVyOg0KYmVyX3NjYW5mIGZtdCAobX0pIGJlcjoNCjRmMmM4OWZlID4+PiBkblBy ZXR0eU5vcm1hbDogPD4NCjRmMmM4OWZlIDw8PCBkblByZXR0eU5vcm1hbDogPD4s IDw+DQo0ZjJjODlmZSBkb19iaW5kOiB2ZXJzaW9uPTMgZG49IiIgbWV0aG9kPTEy OA0KNGYyYzg5ZmUgc2VuZF9sZGFwX3Jlc3VsdDogY29ubj0xMDAwIG9wPTAgcD0z DQo0ZjJjODlmZSBzZW5kX2xkYXBfcmVzdWx0OiBlcnI9MCBtYXRjaGVkPSIiIHRl eHQ9IiINCjRmMmM4OWZlIHNlbmRfbGRhcF9yZXNwb25zZTogbXNnaWQ9MSB0YWc9 OTcgZXJyPTANCmJlcl9mbHVzaDI6IDE0IGJ5dGVzIHRvIHNkIDEyDQpsZGFwX3dy aXRlOiB3YW50PTE0LCB3cml0dG
Date: Tue, 14 Feb 2012 17:32:51 -0800 From: Howard Chu <hyc@symas.com> To: Mattias Andersson <mattias@centaurix.com> CC: openldap-its@openldap.org Subject: Re: ~*~ [spam] Re: (ITS#7143) Assertion error (crash); using relay backend and translucent ove
Mattias Andersson wrote: > On Sat, 04 Feb 2012 01:59:49 +0100, Howard Chu<hyc@symas.com> wrote: >> OK, we need to know exactly what the difference is between the >> ldapsearch query and the browser query. Can you please run slapd -d7 and >> record first the ldapsearch query and then the browser query and post >> the output for each of those? > > Attached the output from the two queries. Thanks. The difference is that the softerra browser was searching with attrsOnly set true, so all of the returned attributes had no values. Setting this option in ldapsearch allowed the issue to be reproduced. This is now fixed in git master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
______________ © Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org
