openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#7526) Segfault in slapd-meta during olcDbUri modify
by masarati＠aero.polimi.it 12 Feb '13

12 Feb '13

> Full_Name: John Madden > Version: 2.4.32 > OS: Linux / RHEL6/64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (168.91.17.188) > > > slapd-meta frontend to another slapd, perform an ldapmodify on the > olcDbUri > (incidentally while troubleshooting incorrect proxy behavior) results in a > segfault. Your backtrace looks useless; however, I could reproduce the problem. A(n almost blind) fix is coming. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7526) Segfault in slapd-meta during olcDbUri modify
by jmadden＠ivytech.edu 12 Feb '13

12 Feb '13

Full_Name: John Madden Version: 2.4.32 OS: Linux / RHEL6/64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (168.91.17.188) slapd-meta frontend to another slapd, perform an ldapmodify on the olcDbUri (incidentally while troubleshooting incorrect proxy behavior) results in a segfault. (gdb) attach 5979 Attaching to process 5979 Reading symbols from /usr/local/libexec/slapd...(no debugging symbols found)...done. Reading symbols from /usr/local/BerkeleyDB.5.1/lib/libdb-5.1.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/BerkeleyDB.5.1/lib/libdb-5.1.so Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] [New Thread 0x7f9dc6485700 (LWP 6928)] [New Thread 0x7f9dc6c86700 (LWP 6927)] [New Thread 0x7f9dc7487700 (LWP 5980)] Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libsasl2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libsasl2.so.2 Reading symbols from /usr/lib64/libssl.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libssl.so.10 Reading symbols from /usr/lib64/libcrypto.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libcrypto.so.10 Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libgssapi_krb5.so.2 Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols found)...done. Loaded symbols for /lib64/libkrb5.so.3 Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libcom_err.so.2 Reading symbols from /lib64/libk5crypto.so.3...(no debugging symbols found)...done. Loaded symbols for /lib64/libk5crypto.so.3 Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libz.so.1 Reading symbols from /lib64/libfreebl3.so...(no debugging symbols found)...done. Loaded symbols for /lib64/libfreebl3.so Reading symbols from /lib64/libkrb5support.so.0...(no debugging symbols found)...done. Loaded symbols for /lib64/libkrb5support.so.0 Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libkeyutils.so.1 Reading symbols from /lib64/libselinux.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libselinux.so.1 Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libnss_files.so.2 Reading symbols from /lib64/libnss_dns.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libnss_dns.so.2 Reading symbols from /usr/lib64/sasl2/libcrammd5.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libcrammd5.so Reading symbols from /usr/lib64/sasl2/libanonymous.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so Reading symbols from /usr/lib64/sasl2/libplain.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libplain.so Reading symbols from /usr/lib64/sasl2/libsasldb.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libsasldb.so Reading symbols from /lib64/libdb-4.7.so...(no debugging symbols found)...done. Loaded symbols for /lib64/libdb-4.7.so Reading symbols from /usr/lib64/sasl2/liblogin.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/liblogin.so Reading symbols from /usr/lib64/sasl2/libdigestmd5.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libdigestmd5.so Reading symbols from /usr/lib64/sasl2/libgssapiv2.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libgssapiv2.so 0x00000033114080ad in pthread_join () from /lib64/libpthread.so.0 Missing separate debuginfos, use: debuginfo-install cyrus-sasl-gssapi-2.1.23-13.el6_3.1.x86_64 cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 cyrus-sasl-md5-2.1.23-13.el6_3.1.x86_64 cyrus-sasl-plain-2.1.23-13.el6_3.1.x86_64 db4-4.7.25-17.el6.x86_64 glibc-2.12-1.80.el6_3.6.x86_64 keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.9-33.el6_3.3.x86_64 libcom_err-1.41.12-12.el6.x86_64 libselinux-2.0.94-5.3.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-25.el6_3.1.x86_64 zlib-1.2.3-27.el6.x86_64 (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f9dc6c86700 (LWP 6927)] 0x0000000000516517 in ?? () (gdb) backtrace full #0 0x0000000000516517 in ?? () No symbol table info available. #1 0x0000000000412b2c in ?? () No symbol table info available. #2 0x0000000000438a8b in ?? () No symbol table info available. #3 0x00000000004393b6 in ?? () No symbol table info available. #4 0x00000000004212d9 in ?? () No symbol table info available. #5 0x0000000000421ab5 in ?? () No symbol table info available. #6 0x0000000000570da0 in ?? () No symbol table info available. #7 0x0000003311407851 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #8 0x0000003310ce811d in clone () from /lib64/libc.so.6 No symbol table info available. (gdb) info registers rax 0x19 25 rbx 0x7f9dc6c83340 140315621602112 rcx 0x0 0 rdx 0x19 25 rsi 0x7f9dc6c83340 140315621602112 rdi 0x7f9dc6c83340 140315621602112 rbp 0x1dbaf00 0x1dbaf00 rsp 0x7f9dc6c80bf0 0x7f9dc6c80bf0 r8 0x0 0 r9 0x7f9dc6c830c0 140315621601472 r10 0x84db78 8706936 r11 0x0 0 r12 0x1d55390 30757776 r13 0x7f9dc6c83340 140315621602112 r14 0x7f9db8112be0 140315374726112 r15 0x7f9db8112670 140315374724720 rip 0x516517 0x516517 eflags 0x10283 [ CF SF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) x/16i $pc => 0x516517: mov 0x0,%rdi 0x51651f: test %rdi,%rdi 0x516522: je 0x515858 0x516528: callq 0x43b4e0 0x51652d: xor %ebp,%ebp 0x51652f: movq $0x0,0x0 0x51653b: jmpq 0x515745 0x516540: andl $0xfffffe7f,0x8 0x51654b: xor %ebp,%ebp 0x51654d: jmpq 0x515745 0x516552: andl $0xfffdffff,0x8 0x51655d: xor %ebp,%ebp 0x51655f: jmpq 0x515745 0x516564: movq $0x0,0x138(%rbp) 0x51656f: xor %ebp,%ebp 0x516571: jmpq 0x515745 (gdb) thread apply all backtrace Thread 4 (Thread 0x7f9dc7487700 (LWP 5980)): #0 0x0000003310ce8713 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000041e5fa in ?? () #2 0x0000003311407851 in start_thread () from /lib64/libpthread.so.0 #3 0x0000003310ce811d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7f9dc6c86700 (LWP 6927)): #0 0x0000000000516517 in ?? () #1 0x0000000000412b2c in ?? () #2 0x0000000000438a8b in ?? () #3 0x00000000004393b6 in ?? () #4 0x00000000004212d9 in ?? () #5 0x0000000000421ab5 in ?? () #6 0x0000000000570da0 in ?? () #7 0x0000003311407851 in start_thread () from /lib64/libpthread.so.0 #8 0x0000003310ce811d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7f9dc6485700 (LWP 6928)): #0 0x000000331140b43c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x0000000000570df5 in ?? () #2 0x0000003311407851 in start_thread () from /lib64/libpthread.so.0 #3 0x0000003310ce811d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f9dcb64e7c0 (LWP 5979)): #0 0x00000033114080ad in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000041b951 in ?? () #2 0x00000000004081c5 in ?? () #3 0x0000003310c1ecdd in __libc_start_main () from /lib64/libc.so.6 #4 0x0000000000406a69 in ?? () #5 0x00007fffe3969bc8 in ?? () #6 0x000000000000001c in ?? () #7 0x0000000000000005 in ?? () #8 0x00007fffe396bd7a in ?? () #9 0x00007fffe396bd93 in ?? () #10 0x00007fffe396bd96 in ?? () #11 0x00007fffe396bdbe in ?? () #12 0x00007fffe396bdc1 in ?? () #13 0x0000000000000000 in ?? ()

1 0

Re: (ITS#7525) Bad conversion to cn=config format
by masarati＠aero.polimi.it 12 Feb '13

12 Feb '13

Fixed in git master, please test. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7525) Bad conversion to cn=config format
by francesco.policastro＠selex-es.com 12 Feb '13

12 Feb '13

Full_Name: Francesco Policastro Version: 2.4.33 OS: RHEL 6.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.127.80.134) A slapd.conf using meta backend can include the following uri definition that is accepted as legal uri "ldap://server2.domain2.net/ou=org Unit,dc=second,dc=newco,dc=com" idassert-bind bindmethod=simple binddn="cn=ldap-2,cn=Users,dc=domain2,dc=net" credentials=secret3 chase-referrals no rebind-as-user true map objectclass groupOfNames * map objectclass person * suffixmassage "dc=second,dc=newco,dc=com" "dc=domain2,dc=net" subtree-include "ou=Users,ou=1stlocation,ou=org Unit,dc=second,dc=newco,dc=com" ... "slaptest -f slapd.conf" returns "config file testing succeeded" "slaptest -f slapd.conf -F slapd.d" converts to cn=config format "slaptest -F slapd.d" issues an error: 511a57ef olcDbURI: value #0: unable to parse URI #0 in "olcDbURI <protocol>://<server>[:port]/<naming context>". 511a57ef config error processing olcMetaSub={1}uri,olcDatabase={1}meta,cn=config: unable to parse URI #0 in "olcDbURI <protocol>://<server>[:port]/<naming context>" slaptest: bad configuration directory! I know that the offending words are in the "ou=org Unit" directive; in fact "ou=orgUnit" (with no space) works. The uri sintax permits to enclose the string in quotes and one assumes that spaces are legal. They are only in slapd.conf because the cn=config conversion does not accept them.

1 0

(ITS#7524) Seg fault of slapd with back-meta traffic
by jorge.perez.burgos＠ericsson.com 12 Feb '13

12 Feb '13

Full_Name: Jorge Perez Burgos Version: 2.4.32 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.243) PROBLEM Sending high load traffic to several slapd servers that are proxying the traffic to only one slapd. It can seen that in this situation originating servers crash sporadically. POSSIBLE SOLUTION In back-meta/conn.c in the method meta_back_retry it seems that the binding flag is not set properly in the following situation: /* restore the "binding" flag, in case */ if ( binding ) { LDAP_BACK_CONN_BINDING_SET( msc ); } if ( rc == LDAP_SUCCESS ) { quarantine = 0; rc = meta_back_single_dobind( op, rs, mcp, candidate, sendok, mt->mt_nretries, 0 ); Setting the binding flag before calling meta_back_single_dobind seems to solve the issue (LDAP_BACK_CONN_BINDING_SET( msc );) CORE DUMP TRACE This is the backtrace of the core dumped. Program terminated with signal 6, Aborted. #0 0x00002ad023473f45 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00002ad023473f45 in raise () from /lib64/libc.so.6 #1 0x00002ad023475340 in abort () from /lib64/libc.so.6 #2 0x00002ad02346d486 in __assert_fail () from /lib64/libc.so.6 #3 0x000000000051cfe1 in meta_back_bind_op_result (op=0x69d2580, rs=0x2aab95e57c70, mc=0x2aab62a44740, candidate=2, msgid=1, sendok=<value optimized out>, dolock=0) at bind.c:392 #4 0x000000000051d130 in meta_back_proxy_authz_bind (mc=0x2aab62a44740, candidate=2, op=0x69d2580, rs=0x2aab95e57c70, sendok=LDAP_BACK_DONTSEND, dolock=0) at bind.c:1590 #5 0x000000000051d37b in meta_back_single_dobind (op=0x69d2580, rs=0x2aab95e57c70, mcp=0x2aab95e56920, candidate=2, sendok=LDAP_BACK_DONTSEND, nretries=<value optimized out>, dolock=0) at bind.c:605 #6 0x000000000052714d in meta_back_retry (op=0x69d2580, rs=0x2aab95e57c70, mcp=0x2aab95e56920, candidate=2, sendok=LDAP_BACK_DONTSEND) at conn.c:769 #7 0x00000000004db025 in meta_back_search (op=0x69d2580, rs=0x2aab95e57c70) at search.c:1154 #8 0x00000000004636d9 in fe_op_search (op=0x69d2580, rs=0x2aab95e57c70) at search.c:402 #9 0x00000000004c4e02 in overlay_op_walk (op=0x69d2580, rs=0x2aab95e57c70, which=op_search, oi=0x8088000, on=0x0) at backover.c:671 #10 0x00000000004c5307 in over_op_func (op=0x69d2580, rs=0x2aab95e57c70, which=op_search) at backover.c:723 #11 0x0000000000463ee5 in do_search (op=0x69d2580, rs=0x2aab95e57c70) at search.c:247 #12 0x0000000000460f45 in connection_operation (ctx=0x2aab95e57e50, arg_v=<value optimized out>) at connection.c:1308 #13 0x0000000000461e05 in connection_read_thread (ctx=0x2aab95e57e50, argv=<value optimized out>) at connection.c:1444 #14 0x000000000055cb7c in ldap_int_thread_pool_wrapper (xpool=0x8028000) at tpool.c:688 #15 0x00002ad022ec92a3 in start_thread () from /lib64/libpthread.so.0 #16 0x00002ad02350549d in clone () from /lib64/libc.so.6

1 0

(ITS#7523) ldap valsort control is not documented
by quanah＠OpenLDAP.org 11 Feb '13

11 Feb '13

Full_Name: Quanah Gibson-Mount Version: 2.4.33 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.196.25.250) The slapo-valsort(5) man page does not mention the fact that the LDAP_CONTROL_VALSORT (1.3.6.1.4.1.4203.666.5.14 can be specified to allow the returning of the values with weights present.

1 0

(ITS#7522) Admin Guide: bugs in example
by openldap＠laimbock.com 10 Feb '13

10 Feb '13

Full_Name: Patrick Laimbock Version: RE24 OS: CentOS 6.3 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.210.175.192) In the OpenLDAP Admin Guide on page 38 it says: 34. olcSuffix: "dc=example,dc=com" 35. olcDbDirectory: /usr/local/var/openldap-data 36. olcRootDN: "cn=Manager,dc=example,dc=com" 37. olcRootPW: secret 38. olcDbIndex: uid pres,eq 39. olcDbIndex: cn,sn,uid pres,eq,approx,sub When I try to slapadd that example config I get the following errors: 5117a0af str2entry: invalid value for attributeType olcSuffix #0 (syntax 1.3.6.1.4.1.1466.115.121.1.12) 5117a1ea str2entry: invalid value for attributeType olcRootDN #0 (syntax 1.3.6.1.4.1.1466.115.121.1.12) /etc/openldap34/slapd.d: line 1: duplicate index definition for attr "uid" When I remove the quotes from the olcSuffix (line 34) and olcRootDN (line 36) entries and remove the double uid from either line 38 or line 39 then the slapadd action is successful.

1 0

Re: (ITS#7503) slapcat: retry a few times when retrieving an entry
by balint＠balintreczey.hu 07 Feb '13

07 Feb '13

Hi Howard, Thank you! I have updated the Debian bug report [1]. Cheers, Balint [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673038 2013/2/7 Howard Chu <hyc(a)symas.com>: > I've committed an alternate fix for this to git master, filed against > ITS#6365. Please test and let us know your results, thanks. > The patch is in commit 853b9d1335d27e280751e9cfb8ca6b5356ffec73 > > -- > -- 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#7503) slapcat: retry a few times when retrieving an entry
by hyc＠symas.com 07 Feb '13

07 Feb '13

I've committed an alternate fix for this to git master, filed against ITS#6365. Please test and let us know your results, thanks. The patch is in commit 853b9d1335d27e280751e9cfb8ca6b5356ffec73 -- -- 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#7521) Passwords with either a comma or period don't authenticate against AD LDAP
by hyc＠symas.com 06 Feb '13

06 Feb '13

quanah(a)zimbra.com wrote: > --On Wednesday, February 06, 2013 6:33 PM +0000 TCera(a)sjrwmd.com wrote: > >> --_000_EE54DB3B9E0D63489B0845CE62912E8C3BAD846ABY2PRD0511MB441_ >> Content-Type: text/plain; charset="us-ascii" >> Content-Transfer-Encoding: quoted-printable >> >> xwiki uses jldap. >> >> http://www.openldap.org/jldap/ > > JLDAP is written in java, and does not use the OpenLDAP C libraries. If > you are going to use Java, I highly recommend you look at the unboundID SDK. > > I would also note that PHP's LDAP Support is known to be utterly broken. > There is no indication anywhere here in your report that indicates a bug > with the OpenLDAP software. If he could reproduce the issue using OpenLDAP's command line tools, there would be reason to suspect libldap. But no such problem occurs for me using e.g. ldapsearch. 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

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