openldap-bugs

openldap-bugs@openldap.org

20960 discussions

(ITS#6638) ldapseach segfault on OSX
by quanah＠zimbra.com 02 Sep '10

02 Sep '10

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: Mac OSX 10.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) When querying AD from a mac, we found that we can segfault ldapsearch. This segfault does not happen when running the same query from linux. Here is the backtrace: (gdb) thr apply all bt full Thread 1 (core thread 0): #0 0x00007fff80697180 in strlen () No symbol table info available. #1 0x000000010008ae22 in ber_put_string (ber=0x100401480, str=0x686372616573 <Address 0x686372616573 out of bounds>, tag=18446744073709551615) at encode.c:273 No locals. #2 0x000000010008be20 in ber_printf (ber=0x100401480, fmt=0x10005f5e4 "s{") at encode.c:575 ap = {{ gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x7fff5fbfeb00, reg_save_area = 0x7fff5fbfea40 }} s = 0x686372616573 <Address 0x686372616573 out of bounds> ss = (char **) 0x0 bv = (struct berval *) 0x0 bvp = (struct berval **) 0x7fff8069dc3b rc = 0 i = 584234 len = 140734799800880 #3 0x00000001000586d8 in ldap_create_deref_control_value (ld=0x100401130, ds=0x100400130, value=0x100016a20) at deref.c:68 j = 1 ber = (BerElement *) 0x100401480 tag = 18 i = 1 __func__ = "\000\000\000\000\000\000\000Critical extension is una" #4 0x0000000100003a28 in main (argc=13, argv=0x7fff5fbff4f8) at ldapsearch.c:1090 i = 0 filtpattern = 0x7fff5fbff739 "(CN=SE-EMEA-OEM)" attrs = (char **) 0x7fff5fbff558 line = '\0' <repeats 504 times>, "ï¿œï¿œï¿œ_ï¿œ\000\000ï¿œï¿œ_ï¿œ\000\000\006\003ï¿œï¿œï¿œ\000\000\000ï¿œ_ï¿œ\000\000ï¿œ&ï¿œ_ï¿œ", '\0' <repeats 18 times>, "ï¿œï¿œï¿œ_ï¿œ\000\000\020ï¿œ_ï¿œ\000\000ï¿œï¿œ_ï¿œ\000\000ï¿œ\005ï¿œ_ï¿œ\000\000ï¿œï¿œ~L\000\000\000\000=ï¿œ\002\000ï¿œ\000\000ï¿œ\000\000\000Ì¹ï¿œT\035ï¿œ_ï¿œï¿œdYhMï¿œ6T{ï¿œbjï¿œ\033\020v:ï¿œ*ï¿œb7\003a/ï¿œMï¿œï¿œï¿œï¿œï¿œï¿œ8ï¿œLï¿œï¿œXï¿œ\025Cï¿œÔ¶&Úxï¿œ6cï¿œOï¿œï¿œDpb*\030\tdï¿œï¿œï¿œ^biï¿œ}ï¿œï¿œ&ï¿œyï¿œfï¿œq"... fp = (FILE *) 0x0 rc = 0 rc1 = 0 i = 0 first = 0 ld = (LDAP *) 0x100401130 seber = (BerElement *) 0x0 vrber = (BerElement *) 0x0 syncber = (BerElement *) 0x0 syncbvalp = (struct berval *) 0x0 err = 0 Search was: /opt/zimbra/openldap/bin/ldapsearch -LLL -D ... -w ... -H ldap://...:3268 -x -E deref=member:mail "(CN=test)" mail Segmentation fault (core dumped)

1 0

objectClass index from slapd.conf is not working
by tim stone 02 Sep '10

02 Sep '10

Hello, I've a strange behavior while using index objectClass for searching. In my slapd.conf I have defined the index in the database section: index objectClass eq Other indexes follows in the config. All of them working fine. If I search via ldapsearch like: ldapsearch -x -h localhost -w password -D"cn=admin,ou=root" -b"ou=root" "(objectclass=Guest)" I can find following Message in the syslog (loglevel -1): Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_equality_candidates (objectClass) Sep 1 14:02:52 LDAP01 slapd[17856]: => key_read Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_index_read: failed (-30989) Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=0, first=0, last=0 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=0 first=0 last=0 Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_filter_candidates Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_equality_candidates (objectClass) Sep 1 14:02:52 LDAP01 slapd[17856]: => key_read Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_index_read 355545 candidates Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=-1, first=228, last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_list_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_list_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: bdb_search_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: => test_filter Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: <= test_filter 5 Sep 1 14:02:52 LDAP01 slapd[17856]: bdb_search: 112277 does not match filter Sep 1 14:02:52 LDAP01 slapd[17856]: entry_decode: "cn=Aaa,cn=Bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: <= entry_decode(cn=Aaa,cn=Bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_dn2id("cn=aaa,cn=bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_dn2id: got id=0x1b696 Sep 1 14:02:52 LDAP01 slapd[17856]: => test_filter Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856] ... all other entires following... As result, the entires are found, but not in the index and the search takes a very long time. Afther this, I have rebuild the complete database via slapcat/slapadd, rebuild the index for objetClass, but nothing helped. In tried the test above on: * OpenSuSE 11.1 and openLDAP 2.4.21 and 2.4.23 (linked against libdb-4.5) * OpenSuSE 11.0 and openLDAP 2.4.9 (linked against libdb-4.5) * Debian Lenny and openLDAP 2.4.11 (linked against libdb-4.2) with different databases and a search against a objectClass. If I try another index (not objectClass) from the slapd.conf the index works, example: ldapsearch -x -h localhost -w password -D"cn=admin,ou=root" -b"ou=root" "(Pk=1234-234)" Sep 1 14:03:44 LDAP01 slapd[17856]: => bdb_equality_candidates (Pk) Sep 1 14:03:44 LDAP01 slapd[17856]: => key_read Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_index_read 1 candidates Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=1, first=112838, last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_list_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_list_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: bdb_search_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: => test_filter Sep 1 14:03:44 LDAP01 slapd[17856]: EQUALITY Sep 1 14:03:44 LDAP01 slapd[17856]: <= test_filter 6 Sep 1 14:03:44 LDAP01 slapd[17856]: => send_search_entry: conn 1002 dn="cn=Fff,cn=Eee,... Sep 1 14:03:44 LDAP01 slapd[17856]: <= send_search_entry: conn 1002 exit. Sep 1 14:03:44 LDAP01 slapd[17856]: send_ldap_result: conn=1002 op=1 p=3 Sep 1 14:03:44 LDAP01 slapd[17856]: send_ldap_response: msgid=2 tag=101 err=0 Sep 1 14:03:44 LDAP01 slapd[17856]: connection_get(12): got connid=1002 Sep 1 14:03:44 LDAP01 slapd[17856]: connection_read(12): checking for input on id=1002 Sep 1 14:03:44 LDAP01 slapd[17856]: op tag 0x42, time 1283342624 Sep 1 14:03:44 LDAP01 slapd[17856]: conn=1002 op=2 do_unbind Sep 1 14:03:44 LDAP01 slapd[17856]: connection_close: conn=1002 sd=12 Why does only the objectClass index not work? The only difference I can see, is that all other indexes are based on "normal" attributes. I don't know, if it is necessary, but for objectClass I can't find a attribute definition in the schema. In the core.schema is the attribute definition for objectClass deactivated (aka #)... Kindly regards Tim Stone

2 1

Re: (ITS#6637) valgrind issues in SSL code
by hyc＠symas.com 31 Aug '10

31 Aug '10

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.23 > OS: Linux 2.6 > URL: http://www.stanford.edu/~quanah/valgrind.txt > Submission from: (NULL) (75.111.45.108) > > > Numerous > ==30949== Conditional jump or move depends on uninitialised value(s) > and > Use of uninitialised value of size 8 > > errors. See: > http://www.stanford.edu/~quanah/valgrind.txt All irrelevant. OpenSSL is intentionally written to use uninit'd bytes in its random number generators etc., and none of this is an OpenLDAP issue anyway. Closing this ITS. -- -- 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#6339) ldapsearch -V doesn't exist after version info
by matheus.morais＠gmail.com 31 Aug '10

31 Aug '10

--0016364ec88477ac37048f173de5 Content-Type: text/plain; charset=ISO-8859-1 Hi there, <quote> That's... bizarre. Even slapd doesn't behave that way. Nor any other program comes immediately to mind. </quote> Even sounds like an strange behave, as Quanah said, this information should be included on ldapsearch man page IMHO. I believe that the following patch could close this BUG: --- openldap/doc/man/man1/ldapsearch.1.orig 2010-08-31 01:25:23.000000000 -0300 +++ openldap/doc/man/man1/ldapsearch.1 2010-08-31 01:37:50.000000000 -0300 @@ -7,6 +7,8 @@ .SH SYNOPSIS .B ldapsearch [\c +.BR \-V [ V ]] +[\c .BR \-n ] [\c .BR \-c ] @@ -107,6 +109,11 @@ Option \fI\-L\fP controls the format of the output. .SH OPTIONS .TP +.BR \-V [ V ] +Prints the ldapsearch version and proceeds with the search. +.B \-VV +Prints the ldapsearch version and quit. +.TP .B \-n Show what would be done, but don't actually perform the search. Useful for debugging in conjunction with \fB\-v\fP. Please review it. Thanks, Matheus Morais --0016364ec88477ac37048f173de5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi there, <quote> That's... bizarre. Even slapd doesn&#39= ;t behave that way. Nor any other program comes immediately to mind. </= quote> Even sounds like an strange behave, as Quanah said, this i= nformation should be included on ldapsearch man page IMHO. I believe that the following patch could close this BUG: --- ope= nldap/doc/man/man1/ldapsearch.1.orig=A0=A0=A0 2010-08-31 01:25:23.000000000= -0300 +++ openldap/doc/man/man1/ldapsearch.1=A0=A0=A0 2010-08-31 01:37:= 50.000000000 -0300 @@ -7,6 +7,8 @@ =A0.SH SYNOPSIS =A0.B ldapsearch =A0[\c +.BR \-= V [ V ]] +[\c =A0.BR \-n ] =A0[\c =A0.BR \-c ] @@ -107,6 +10= 9,11 @@ =A0Option \fI\-L\fP controls the format of the output. =A0.SH= OPTIONS =A0.TP +.BR \-V [ V ] +Prints the ldapsearch version and proceeds wit= h the search. +.B \-VV +Prints the ldapsearch version and quit. +.= TP =A0.B \-n =A0Show what would be done, but don't actually perfo= rm the search.=A0 Useful for =A0debugging in conjunction with \fB\-v\fP. Please review it. <br= >Thanks, Matheus Morais --0016364ec88477ac37048f173de5--

1 0

(ITS#6637) valgrind issues in SSL code
by quanah＠OpenLDAP.org 31 Aug '10

31 Aug '10

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: Linux 2.6 URL: http://www.stanford.edu/~quanah/valgrind.txt Submission from: (NULL) (75.111.45.108) Numerous ==30949== Conditional jump or move depends on uninitialised value(s) and Use of uninitialised value of size 8 errors. See: http://www.stanford.edu/~quanah/valgrind.txt --Quanah

1 0

Re: (ITS#6633) test030-relay: Passwd ExOp failed (1)!
by michael＠stroeder.com 29 Aug '10

29 Aug '10

Seems to be fixed now.

1 0

Re: (ITS#6634) potential leak when ARG_BERVAL|ARG_OFFSET
by masarati＠aero.polimi.it 29 Aug '10

29 Aug '10

> Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.72.165.149) > Submitted by: ando > > > config_get_vals() in the above case first duplicates the berval from the > pointer; then assigns it to "bv"; finally, it calls value_add_one(), which > further duplicates the berval. When ARG_STRING, instead, after the string > is > turned into a berval, ber_bvarray_add() is called. > > As far as I could tell, this only occurs for olcDbDirectory of back-ldif. Things seem to be a little bit more complicated: - when ARG_OFFSET && ARG_STRING, copy the string, then ber_bvarray_add() - when ARG_MAGIC && ARG_STRING, ber_bvarray_add() - when ARG_OFFSET && ARG_BERVAL, don't copy the string, value_add_one() - when ARG_MAGIC && ARG_BERVAL, value_add_one() A fix is coming. p.

1 0

(ITS#6635) when an undefined attribute is used in a presence filter, the temporary description can leak
by masarati＠aero.polimi.it 29 Aug '10

29 Aug '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.149) Submitted by: ando A fix is coming. p.

1 0

(ITS#6634) potential leak when ARG_BERVAL|ARG_OFFSET
by masarati＠aero.polimi.it 29 Aug '10

29 Aug '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.149) Submitted by: ando config_get_vals() in the above case first duplicates the berval from the pointer; then assigns it to "bv"; finally, it calls value_add_one(), which further duplicates the berval. When ARG_STRING, instead, after the string is turned into a berval, ber_bvarray_add() is called. As far as I could tell, this only occurs for olcDbDirectory of back-ldif. p.

1 0

Re: (ITS#6633) test030-relay: Passwd ExOp failed (1)!
by masarati＠aero.polimi.it 29 Aug '10

29 Aug '10

*should* be fixed. Unnoticed side effect of ITS#6632 hack. Thanks, p.

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