openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Start a nNew thread

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

Re: (ITS#6612) Back SQL / Mysql / InnoDB
by masarati＠aero.polimi.it 28 Aug '10

28 Aug '10

The requested feature has been added to HEAD code; please test and report. Thanks, p.

1 0

Re: (ITS#6631) back-sql attribute order incorrect
by masarati＠aero.polimi.it 28 Aug '10

28 Aug '10

> Also, that portion of the code has been recently modified (to allow 64-bit > integer keys); could you test with back-sql code from HEAD? It should > build and work straight with 2.3.43 code. I need to partly amend myself: that improvement requires long long parsing capabilities that were added to liblutil, so you'll probably be better off pulling the entire HEAD from the CVS to test it. p.

1 0

ITS#6630 dupent
by masarati＠aero.polimi.it 28 Aug '10

28 Aug '10

I've recently committed an overlay that implements the (expired) <draft-ietf-ldapext-ldapv3-dupent-08.txt> (ITS#6630); it's in contrib/slapd-modules/dupent/; configuration is pretty straightforward: load the module, and add overlay dupent in the database you want dupent to be enabled. I've only tested it as database specific, although it should also work as a global overlay. Could anybody with access to a dupent-capable client please test it and report (through the ITS, in case)? I'm not 100% sure about the request/response encoding/decoding. Thanks, p.

1 0

Re: (ITS#6631) back-sql attribute order incorrect
by masarati＠aero.polimi.it 27 Aug '10

27 Aug '10

> slapd log: > backsql_add_attr("radiuslogin=xyzzy2,ou=Dialup,ou=External,o=Integra"): > executing "UPDATE radiusaccount SET radiuslogin=? WHERE id=?" val[0], id=1411 > > MySQL log: > 173 Query UPDATE radiusaccount SET radiuslogin=1411 WHERE id='xyzzy2' > Note that this appears to be a logging issue rather than a functional one. > = > The parameter order changes according to the param_order field, but the > sl= > apd log always indicates the order as if param_order=3D0 I'm not sure I understand this report. Can you please make the example more esplicative? Also, please note that "id" in the update procedure is the name of a specific field in the RDBMS, while "id" in slapd's log is a generic name for the key that is being used. The name coincidence is purely incidental. Also, that portion of the code has been recently modified (to allow 64-bit integer keys); could you test with back-sql code from HEAD? It should build and work straight with 2.3.43 code. Thanks, p.

1 0

Re: (ITS#6631) back-sql attribute order incorrect
by david.stults＠integratelecom.com 26 Aug '10

26 Aug '10

Note that this appears to be a logging issue rather than a functional one. = The parameter order changes according to the param_order field, but the sl= apd log always indicates the order as if param_order=3D0 On Aug 26, 2010, at 11:38 AM, <openldap-its(a)OpenLDAP.org> <openldap-its@Ope= nLDAP.org> wrote: >=20 > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** >=20 > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6631. >=20 > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. >=20 > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6631) > in the subject will automatically be attached to the issue report. >=20 > mailto:openldap-its@openldap.org?subject=3D(ITS#6631) >=20 > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=3D6631 >=20 > Please remember to retain your issue tracking number (ITS#6631) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. >=20 > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. >=20 > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ >=20 > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >=20

1 0

(ITS#6631) back-sql attribute order incorrect
by david.stults＠integratelecom.com 26 Aug '10

26 Aug '10

Full_Name: David Stults Version: 2.4.23 OS: CentOS 5.5 URL: Submission from: (NULL) (64.122.164.12) When executing the add_proc SQL query, back-sql claims to provide the attributes in a particular order, but reality is reversed: slapd log: backsql_add_attr("radiuslogin=xyzzy2,ou=Dialup,ou=External,o=Integra"): executing "UPDATE radiusaccount SET radiuslogin=? WHERE id=?" val[0], id=1411 MySQL log: 173 Query UPDATE radiusaccount SET radiuslogin=1411 WHERE id='xyzzy2'

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