openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by matheus.morais＠gmail.com 30 Aug '10

30 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 30 Aug '10

30 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

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

29 Aug '10

Full_Name: Michael Ströder Version: HEAD OS: Linux URL: Submission from: (NULL) (84.163.34.243) Please let me know if you need logs. $ ./run -b bdb test030 Cleaning up test run directory leftover from previous run. Running ./scripts/test030-relay for bdb... running defines.sh Testing virtual naming context mapping with relay ldap meta backend(s)... Using relay backend... Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Searching base="dc=example,dc=com"... Searching base="o=Example,c=US"... Searching base="o=Esempio,c=IT"... Searching base="o=Beispiel,c=DE"... Modifying database "o=Beispiel,c=DE"... Modifying database "o=Example,c=US"... Searching base="o=Example,c=US"... Searching base="o=Esempio,c=IT"... Searching filter="(objectClass=referral)" attrs="'*' ref" base="dc=example,dc=com"... base="o=Example,c=US"... base="o=Esempio,c=IT"... Searching filter="(seeAlso=cn=all staff,ou=Groups,o=Example,c=US)" attrs="seeAlso" base="o=Example,c=US"... Searching filter="(uid=example)" attrs="uid" base="o=Example,c=US"... Searching filter="(member=cn=Another Added Group,ou=Groups,o=Example,c=US)" attrs="member" base="o=Example,c=US"... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Changing password to database "o=Example,c=US"... Passwd ExOp failed (1)!

1 0

Re: (ITS#6632) Core dump in test030 when using back-ldap
by masarati＠aero.polimi.it 28 Aug '10

28 Aug '10

It is clearly slapo-rwm(5), whose cleanup function is not executed early enough when dealing with extended operations, since the latter delegate successful return to the frontend: modified logging... conn=1000 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1 conn=1000 op=1 PASSMOD id="cn=Added User,ou=Alumni Association,ou=People,o=Example,c=US" new ### conn=1000 op=1: passwd_extop: setting dn="cn=Added User,ou=Alumni Association,ou=People,o=Example,c=US" (0x4972608) ### conn=1000 op=1: rwm_extended: setting dn="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" (0x4972ed0) conn=1001 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1 conn=1001 op=1 PASSMOD id="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" new ### conn=1001 op=1: passwd_extop: setting dn="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" (0x4975ba8) ### conn=1001 op=1: passwd_extop: freeing dn="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" (0x4975ba8) ### conn=1000 op=1: passwd_extop: freeing dn="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" (0x4972ed0) ### conn=1000 op=1: rwm_op_rollback: freeing dn="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" (0x4972ed0) conn=1000 op=1 RESULT oid= err=0 text= ==23914== Thread 3: ==23914== Invalid read of size 1 ==23914== at 0x4006238: strlen (mc_replace_strmem.c:246) ==23914== by 0xCB184D: vfprintf (in /lib/libc-2.5.so) ==23914== by 0xCD1FD3: vsnprintf (in /lib/libc-2.5.so) ==23914== by 0x826B0C6: lutil_debug (debug.c:66) ==23914== by 0x80C8C85: do_extended (extended.c:185) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== Address 0x4972608 is 0 bytes inside a block of size 62 free'd ==23914== at 0x4004FDA: free (vg_replace_malloc.c:233) ==23914== by 0x826B139: ber_memfree_x (memory.c:152) ==23914== by 0x80F551F: slap_sl_free (sl_malloc.c:481) ==23914== by 0x80CA4C7: passwd_extop (passwd.c:326) ==23914== by 0x80C8F01: fe_extended (extended.c:225) ==23914== by 0x80C8C06: do_extended (extended.c:177) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== ==23914== Invalid read of size 1 ==23914== at 0x4006243: strlen (mc_replace_strmem.c:246) ==23914== by 0xCB184D: vfprintf (in /lib/libc-2.5.so) ==23914== by 0xCD1FD3: vsnprintf (in /lib/libc-2.5.so) ==23914== by 0x826B0C6: lutil_debug (debug.c:66) ==23914== by 0x80C8C85: do_extended (extended.c:185) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== Address 0x4972609 is 1 bytes inside a block of size 62 free'd ==23914== at 0x4004FDA: free (vg_replace_malloc.c:233) ==23914== by 0x826B139: ber_memfree_x (memory.c:152) ==23914== by 0x80F551F: slap_sl_free (sl_malloc.c:481) ==23914== by 0x80CA4C7: passwd_extop (passwd.c:326) ==23914== by 0x80C8F01: fe_extended (extended.c:225) ==23914== by 0x80C8C06: do_extended (extended.c:177) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== ==23914== Invalid read of size 4 ==23914== at 0xCE232C: mempcpy (in /lib/libc-2.5.so) ==23914== by 0xCB1375: vfprintf (in /lib/libc-2.5.so) ==23914== by 0xCD1FD3: vsnprintf (in /lib/libc-2.5.so) ==23914== by 0x826B0C6: lutil_debug (debug.c:66) ==23914== by 0x80C8C85: do_extended (extended.c:185) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== Address 0x4972608 is 0 bytes inside a block of size 62 free'd ==23914== at 0x4004FDA: free (vg_replace_malloc.c:233) ==23914== by 0x826B139: ber_memfree_x (memory.c:152) ==23914== by 0x80F551F: slap_sl_free (sl_malloc.c:481) ==23914== by 0x80CA4C7: passwd_extop (passwd.c:326) ==23914== by 0x80C8F01: fe_extended (extended.c:225) ==23914== by 0x80C8C06: do_extended (extended.c:177) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ### conn=1000 op=1: do_extended: freeing dn="cn=Added User,ou=Alumni Association,ou=People,o=Example,c=US" (0x4972608) ==23914== ==23914== Invalid free() / delete / delete[] ==23914== at 0x4004FDA: free (vg_replace_malloc.c:233) ==23914== by 0x826B139: ber_memfree_x (memory.c:152) ==23914== by 0x80F551F: slap_sl_free (sl_malloc.c:481) ==23914== by 0x80C8CE6: do_extended (extended.c:187) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== Address 0x4972608 is 0 bytes inside a block of size 62 free'd ==23914== at 0x4004FDA: free (vg_replace_malloc.c:233) ==23914== by 0x826B139: ber_memfree_x (memory.c:152) ==23914== by 0x80F551F: slap_sl_free (sl_malloc.c:481) ==23914== by 0x80CA4C7: passwd_extop (passwd.c:326) ==23914== by 0x80C8F01: fe_extended (extended.c:225) ==23914== by 0x80C8C06: do_extended (extended.c:177) ==23914== by 0x808ACB9: connection_operation (connection.c:1109) ==23914== by 0x8234F88: ldap_int_thread_pool_wrapper (tpool.c:685) ==23914== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==23914== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==23914== A fix (a hack, at least) is coming. p.

1 0

(ITS#6632) Core dump in test030 when using back-ldap
by masarati＠aero.polimi.it 28 Aug '10

28 Aug '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.166.16) Submitted by: ando When compiled with -DSLAP_NO_SL_MALLOC=1 test030 cores when performing passwd extop with back-ldap; a gdb stack backtrace is provided below. (gdb) bt #0 0x00115402 in __kernel_vsyscall () #1 0x001c4d20 in raise () from /lib/libc.so.6 #2 0x001c6631 in abort () from /lib/libc.so.6 #3 0x001fce6b in __libc_message () from /lib/libc.so.6 #4 0x00204b16 in _int_free () from /lib/libc.so.6 #5 0x00208070 in free () from /lib/libc.so.6 #6 0x0826ae7a in ber_memfree_x (p=0x8b84fe0, ctx=0x0) at ../../../ldap-src/libraries/liblber/memory.c:152 #7 0x080f537c in slap_sl_free (ptr=0x8b84fe0, ctx=0x8b15138) at ../../../ldap-src/servers/slapd/sl_malloc.c:481 #8 0x080c8c58 in do_extended (op=0x8b2cde0, rs=0xb79820e4) at ../../../ldap-src/servers/slapd/extended.c:184 #9 0x0808acba in connection_operation (ctx=0xb79821d0, arg_v=0x8b2cde0) at ../../../ldap-src/servers/slapd/connection.c:1109 #10 0x0808b1fa in connection_read_thread (ctx=0xb79821d0, argv=0xd) at ../../../ldap-src/servers/slapd/connection.c:1245 #11 0x08234cc9 in ldap_int_thread_pool_wrapper (xpool=0x8a53b28) at ../../../ldap-src/libraries/libldap_r/tpool.c:685 #12 0x0011b46b in start_thread () from /lib/libpthread.so.0 #13 0x0026cdbe in clone () from /lib/libc.so.6 The issue, according to valgrind, consists in a double-free, which does not surface when dealt with by the slab. conn=1021 fd=17 ACCEPT from IP=127.0.0.1:45744 (IP=127.0.0.1:9011) conn=1021 op=0 BIND dn="cn=Manager,o=Example,c=US" method=128 conn=1022 fd=22 ACCEPT from IP=127.0.0.1:45745 (IP=127.0.0.1:9011) conn=1022 op=0 BIND dn="cn=Manager,dc=example,dc=com" method=128 conn=1022 op=0 BIND dn="cn=Manager,dc=example,dc=com" mech=SIMPLE ssf=0 conn=1022 op=0 RESULT tag=97 err=0 text= conn=1021 op=0 BIND dn="cn=Manager,dc=example,dc=com" mech=SIMPLE ssf=0 conn=1021 op=0 RESULT tag=97 err=0 text= conn=1021 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1 conn=1021 op=1 PASSMOD id="cn=Added User,ou=Alumni Association,ou=People,o=Example,c=US" new conn=1022 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1 conn=1022 op=1 PASSMOD id="cn=Added User,ou=Alumni Association,ou=People,dc=example,dc=com" new conn=1021 op=1 RESULT oid= err=0 text= ==4946== ==4946== Thread 7: ==4946== Invalid free() / delete / delete[] ==4946== at 0x4004FDA: free (vg_replace_malloc.c:233) ==4946== by 0x826AE79: ber_memfree_x (memory.c:152) ==4946== by 0x80F537B: slap_sl_free (sl_malloc.c:481) ==4946== by 0x80C8C57: do_extended (extended.c:184) ==4946== by 0x808ACB9: connection_operation (connection.c:1109) ==4946== by 0x808B1F9: connection_read_thread (connection.c:1245) ==4946== by 0x8234CC8: ldap_int_thread_pool_wrapper (tpool.c:685) ==4946== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==4946== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==4946== Address 0x45DD018 is 0 bytes inside a block of size 62 free'd ==4946== at 0x4004FDA: free (vg_replace_malloc.c:233) ==4946== by 0x826AE79: ber_memfree_x (memory.c:152) ==4946== by 0x80F537B: slap_sl_free (sl_malloc.c:481) ==4946== by 0x80CA323: passwd_extop (passwd.c:321) ==4946== by 0x80C8E6E: fe_extended (extended.c:222) ==4946== by 0x80C8C05: do_extended (extended.c:177) ==4946== by 0x808ACB9: connection_operation (connection.c:1109) ==4946== by 0x808B1F9: connection_read_thread (connection.c:1245) ==4946== by 0x8234CC8: ldap_int_thread_pool_wrapper (tpool.c:685) ==4946== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==4946== by 0xD42DBD: clone (in /lib/libc-2.5.so) The issue *might* be related to slapo-rwm playing with the rewriting of the request dn/ndn, but it does not surface when the same test is performed using back-relay, which also uses slapo-rwm. 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