openldap-bugs March 2011

openldap-bugs@openldap.org

47 participants
119 discussions

(ITS#6858) segfault on schema modification in cn=config
by zerbe＠phil.uni-duesseldorf.de 09 Mar '11

09 Mar '11

Full_Name: Sebastian Zerbe Version: 2.4.23-7 OS: Debian GNU/Linux 6.0 URL: ftp://ftp.openldap.org/incoming/sebastian-zerbe-110309.tar.gz Submission from: (NULL) (134.99.58.27) Trying to modify the local schema cn={5}philfak,cn=schema,cn=config with the given ldif-file modify_phil_schema.ldif using "ldapmodify -x -D cn=admin,cn=config -W -f modify_phil_schema.ldif" results in a slapd crash with kernel log entries like these: [3451954.217075] slapd[2593]: segfault at 70 ip 080bd73f sp ae5f9910 error 4 in slapd[8048000+11b000] [3451972.088717] slapd[5716]: segfault at 70 ip 080bd73f sp b1bfe910 error 4 in slapd[8048000+11b000] [3452718.916547] slapd[5830]: segfault at 70 ip 080bd73f sp b1992910 error 4 in slapd[8048000+11b000] Further debugging is nearly impossible. If slapd is running in gdb it does not crash (but the modifications do not take place either)...

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by quanah＠zimbra.com 08 Mar '11

08 Mar '11

--On March 4, 2011 11:14:46 PM +0000 dhawes(a)vt.edu wrote: > Tested, and working. Thanks for the fix. We're still seeing this happen sporadically with slapindex -q <attribute> i.e., reindexing a single attribute instead of the entire DB Thread 2 (Thread 0x96591ba0 (LWP 10652)): #0 0xffffe410 in __kernel_vsyscall () No symbol table info available. #1 0xb7dd21e6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #2 0xb7f4b5d8 in ldap_pvt_thread_cond_wait (cond=0xb776bf80, mutex=0xb776bf50) at thr_posix.c:277 No locals. #3 0xb77376f4 in bdb_tool_trickle_task (ctx=0x965912bc, ptr=0x82eb728) at tools.c:1242 env = 0x82eb728 wrote = -1208699249 #4 0xb7f4a33c in ldap_int_thread_pool_wrapper (xpool=0x81bda78) at tpool.c:685 pool = 0x81bda78 task = 0x82ee038 work_list = 0x81bdaf8 ctx = {ltu_id = 2522422176, ltu_key = {{ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0xb7f9b049, ltk_free = 0xb7dcc732}, { ltk_key = 0x0, ltk_data = 0xb7fa7ff4, ltk_free = 0xb7bffd80}, {ltk_key = 0x0, ltk_data = 0x96591388, ltk_free = 0xb7f963d0 <do_lookup_x+640>}, {ltk_key = 0x0, ltk_data = 0xb7dcc75a, ltk_free = 0}, { ltk_key = 0x0, ltk_data = 0xb7dcb324, ltk_free = 0x69cb120}, {ltk_key = 0x0, ltk_data = 0xd696910, ltk_free = 0xe}, {ltk_key = 0x0, ltk_data = 0xb7a874a0, ltk_free = 0xb7a8ffe0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x2, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0xb7fa7ff4}, {ltk_key = 0x0, ltk_data = 0x96591414, ltk_free = 0x96591428}, { ltk_key = 0x0, ltk_data = 0x96591414, ltk_free = 0xb7fa8830}, {ltk_key = 0x0, ltk_data = 0xb7bf7dd8, ltk_free = 0x1}, {ltk_key = 0x0, ltk_data = 0x1, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0xb7f272a0, ltk_free = 0xb7dcb69d}, {ltk_key = 0x0, ltk_data = 0x1000000, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0xb7a8f000, ltk_free = 0xb7bf7508}, {ltk_key = 0x0, ltk_data = 0xb7dcb324, ltk_free = 0xb7f272a0}, {ltk_key = 0x0, ltk_data = 0xb7f9a24d, ltk_free = 0xb7f27448}, {ltk_key = 0x0, ltk_data = 0x1, ltk_free = 0x1}}} kctx = 0x0 i = 32 keyslot = 522 hash = 5777930 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #5 0xb7dce35b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #6 0xb7b43c0e in clone () from /lib/libc.so.6 No symbol table info available. Thread 1 (Thread 0xb7a826b0 (LWP 10610)): #0 0xffffe410 in __kernel_vsyscall () No symbol table info available. #1 0xb7dd21e6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #2 0xb7f4b5d8 in ldap_pvt_thread_cond_wait (cond=0x81bda94, mutex=0x81bda7c) at thr_posix.c:277 No locals. #3 0xb7f49fe7 in ldap_pvt_thread_pool_destroy (tpool=0xbf995780, run_pending=0) at tpool.c:582 pool = 0x81bda78 pptr = 0x81bda78 task = 0x0 #4 0xb7f49332 in ldap_int_thread_pool_shutdown () at tpool.c:181 pool = 0x81bda78 #5 0xb7f48aa0 in ldap_pvt_thread_destroy () at threads.c:70 No locals. #6 0x080af918 in slap_destroy () at init.c:273 rc = 0 #7 0x080ff5f2 in slap_tool_destroy () at slapcommon.c:865 rc = 0 #8 0x080ffb9b in slapindex (argc=1, argv=0xbf9959bc) at slapindex.c:107 id = 4294967295 rc = 0 progname = 0x813ae0a "slapindex" ad = 0x8239440 adv = 0xbf9959bc __PRETTY_FUNCTION__ = "slapindex" #9 0x08057783 in main (argc=7, argv=0xbf9959a4) at main.c:403 i = 3 no_detach = 0 rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 g_argc = 7 g_argv = 0xbf9959a4 configfile = 0x0 configdir = 0x0 serverName = 0xbf997206 "slapindex" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x811c33f "" l = 134548137 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __PRETTY_FUNCTION__ = "main" --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6461) back-sql quote characters in query
by atze_80＠web.de 08 Mar '11

08 Mar '11

Can confirm this with openldap 2.4.24. Using ldap search filters like this: (cn=blabla' or '1'='1) is at least causing my postgres to eat all CPU cycles it can get (LDAP data is based on complex view). I do not have write access enabled for that particular openLDAP installation, but I also assume that SQL Injection is possible. Beside being an obviuos malfunction, this should be considered a security issue. atze

1 0

Re: (ITS#6856) OpenLDAP 2.4.23 / db 4.7.25 lockup 100% CPU
by hyc＠symas.com 07 Mar '11

07 Mar '11

requate(a)univention.de wrote: > Full_Name: Arvid Requate > Version: 2.4.23 > OS: Debian Lenny > URL: http://apt.univention.de/download/temp/openldap/trace_openldap_2.4.23_db_4.… > Submission from: (NULL) (82.198.197.8) > > > With OpenLDAP 2.4.23 and bdb 4.7.25 we seem to hit something like a race > condition that can be triggered by concurrent ldapdelete and search_s > operations. > Though a bit simmilar, this condition does no quite match the details of > ITS#5707. The URL provides a tar archive containing three gdb traces and > corresponding slapd log output (loglevel: trace args stats) of three cases of > lockup, where slapd hangs consuming 100% of CPU after a couple of modifications > with the shell script contained in the tar archive and remains unresponsive > until restartet.The number of successful operations varies between the test > runs. > > Berkeley DB 4.7.25 (May 15, 2008) was built with Oracle patches for Bugs #16415 > and #16541 and configure options "--enable-posixmutexes > --with-mutex=POSIX/pthreads". > > The test machine is a single processor/single core 686 VM running Linux 2.6.32 > 686 bigmem. The concurrent searches are performed by a separate process that > gets informed about ldap modifications (via file) by an slapd overlay module > called 'translog'. To me the traces do not seem to indicate a problem in the > overlay code (i.e. there is no reference to the on_response function > "translog_response" in the traces). > > Maybe there is some obvious point here we are missing? More debug details can be > provided if necessary. Try again using 2.4.24. There was a bug with back-bdb delete fixed recently (ITS#6577) so the relevant code has changed since .23. Also try a newer BerkeleyDB. We've had other deadlocks with 4.7 that no longer occur in 4.8. -- -- 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

(ITS#6857) chain overlay change FLAGS of underlying database
by rhafer＠suse.de 07 Mar '11

07 Mar '11

Full_Name: Ralf Haferkamp Version: RE24, HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.38.247) The chain-overlay adds SLAP_DBFLAG_NOLASTMOD to the flags of the database for which chaining is to be configured. Example: -------------------- database hdb suffix o=test rootdn o=test rootpw secret directory /tmp/ldap overlay chain chain-return-error TRUE chain-uri ldap://ldap.server ------------------- With the above configuration slapd will no longer maintain the "modifyTimeStamp", "modifiersName", etc. Attributes for write operations to the "o=test" database anymore. Note: This bug is only present when using a slapd.conf base configuration. Fix is almost ready.

1 0

(ITS#6856) OpenLDAP 2.4.23 / db 4.7.25 lockup 100% CPU
by requate＠univention.de 07 Mar '11

07 Mar '11

Full_Name: Arvid Requate Version: 2.4.23 OS: Debian Lenny URL: http://apt.univention.de/download/temp/openldap/trace_openldap_2.4.23_db_4.… Submission from: (NULL) (82.198.197.8) With OpenLDAP 2.4.23 and bdb 4.7.25 we seem to hit something like a race condition that can be triggered by concurrent ldapdelete and search_s operations. Though a bit simmilar, this condition does no quite match the details of ITS#5707. The URL provides a tar archive containing three gdb traces and corresponding slapd log output (loglevel: trace args stats) of three cases of lockup, where slapd hangs consuming 100% of CPU after a couple of modifications with the shell script contained in the tar archive and remains unresponsive until restartet.The number of successful operations varies between the test runs. Berkeley DB 4.7.25 (May 15, 2008) was built with Oracle patches for Bugs #16415 and #16541 and configure options "--enable-posixmutexes --with-mutex=POSIX/pthreads". The test machine is a single processor/single core 686 VM running Linux 2.6.32 686 bigmem. The concurrent searches are performed by a separate process that gets informed about ldap modifications (via file) by an slapd overlay module called 'translog'. To me the traces do not seem to indicate a problem in the overlay code (i.e. there is no reference to the on_response function "translog_response" in the traces). Maybe there is some obvious point here we are missing? More debug details can be provided if necessary.

1 0

Re: (ITS#6491) LDAP Error code 80 - Dn index delete failed
by apm＠one.com 07 Mar '11

07 Mar '11

I see this symptom too with both these versions: OpenLDAP 2.4.21, BDB 4.8.26 OpenLDAP 2.4.23, BDB 4.8.30 ldapdelete -r failes with: ldap_delete: Other (e.g., implementation specific) error (80) additional info: DN index delete failed I've copied the database files to a similar machine for debugging. Here's the output for slapd -d1 when doing so: ============================================================= do_bind: SASL/EXTERNAL bind: dn="cn=config" sasl_ssf=0 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 11 <== slap_sasl_bind: rc=0 connection_get(11): got connid=1001 connection_read(11): checking for input on id=1001 ber_get_next ber_get_next: tag 0x30 len 86 contents: op tag 0x63, time 1299502775 ber_get_next conn=1001 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <o=xxx,dc=example,dc=com> <<< dnPrettyNormal: <o=xxx,dc=example,dc=com>, <o=xxx,dc=example,dc=com> ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: => bdb_search bdb_dn2entry("o=xxx,dc=example,dc=com") search_candidates: base="o=xxx,dc=example,dc=com" (0x0025d3ca) scope=1 => bdb_dn2idl("o=xxx,dc=example,dc=com") <= bdb_dn2idl: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) bdb_search_candidates: failed (rc=-30988) bdb_search: no candidates send_ldap_result: conn=1001 op=1 p=3 send_ldap_response: msgid=2 tag=101 err=0 ber_flush2: 14 bytes to sd 11 connection_get(11): got connid=1001 connection_read(11): checking for input on id=1001 ber_get_next ber_get_next: tag 0x30 len 49 contents: op tag 0x4a, time 1299502775 ber_get_next conn=1001 op=2 do_delete ber_scanf fmt (m) ber: >>> dnPrettyNormal: <o=xxx,dc=example,dc=com> <<< dnPrettyNormal: <o=xxx,dc=example,dc=com>, <o=xxx,dc=example,dc=com> bdb_dn2entry("o=xxx,dc=example,dc=com") bdb_dn2entry("o=xxx,dc=example,dc=com") bdb_entry_get: rc=0 bdb_dn2entry("o=xxx,dc=example,dc=com") => bdb_dn2id_delete 0x25d3ca: "o=xxx,dc=example,dc=com" => bdb_idl_delete_key: c_get lo failed: DB_BUFFER_SMALL: User memory too small for return value (-30999) => bdb_dn2id_delete 0x25d3ca: subtree (o=xxx,dc=example,dc=com) delete failed: -30999 <= bdb_dn2id_delete 0x25d3ca: -30999 <=- bdb_delete: dn2id failed: DB_BUFFER_SMALL: User memory too small for return value (-30999) send_ldap_result: conn=1001 op=2 p=3 send_ldap_response: msgid=3 tag=107 err=80 ber_flush2: 36 bytes to sd 11 connection_get(11): got connid=1001 connection_read(11): checking for input on id=1001 ber_get_next ber_get_next: tag 0x30 len 5 contents: op tag 0x42, time 1299502775 ber_get_next ber_get_next on fd 11 failed errno=0 (Success) conn=1001 op=3 do_unbind connection_get(11): got connid=1001 connection_get(11): got connid=1001 connection_close: conn=1001 sd=11 ============================================================================= Doing an ldapsearch for the entry takes some time, but does finish. Looking at the -d1 output there's a lot of "bdb_search: <number> scope not okay" messages. There's about 5 million objects in the database. I only know of this one object on this server which has this problem. I have another server with another object with the same problem. Other objects can be deleted just fine. Looking at the slapcat output, there's only the base "o=xxx" object. There's no subordinate objects to this object. /Peter

1 0

Re: (ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by raphael.ouazana＠linagora.com 07 Mar '11

07 Mar '11

Hi, Le Ven 4 mars 2011 23:02, hyc(a)symas.com a écrit : > raphael.ouazana(a)linagora.com wrote: >> Le Mer 2 mars 2011 17:52, masarati(a)aero.polimi.it a ?crit : >>> >>>> The following patch >>> >>> Please upload patches according to >>> <http://www.openldap.org/devel/contributing.html#submitting>. >> >> Sorry, it seems to be my fault. Here it is: >> ftp://ftp.openldap.org/incoming/raphael-ouazana-110302-sssvlv-fix-free_sort… > > Thanks for the patch. While you're at it, would you be able to create a > test > script for sssvlv to use in our test suite? Sorry, no time for that for the moment. Furthermore I don't think this bug is reproducible with current OpenLDAP client tools. Regards, Raphaël Ouazana.

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by dhawes＠vt.edu 04 Mar '11

04 Mar '11

On 03/04/2011 05:56 PM, hyc(a)symas.com wrote: > dhawes(a)vt.edu wrote: >> On 03/04/2011 04:08 PM, hyc(a)symas.com wrote: >>> This indicates that the trickle task is still waiting for a signal on its >>> condition variable. Which is a bit odd since bdb_tool_entry_close() already >>> signals it before slap_tool_destroy() is called. >>> >>> It might be illuminating to run slapadd under gdb with a breakpoint on >>> bdb_tool_entry_close(), and singlestep through the first few lines of that >>> function where it issues the signal, and see if the trickle task actually >>> reacts or not. >> >> Setting a breakpoint on bdb_tool_entry_close() and then either >> continuing or stepping through the function allows slapadd to exit cleanly. > > A fix for this is now in HEAD, please test. > back-bdb/tools.c 1.140 > Tested, and working. Thanks for the fix.

1 0

Re: (ITS#6817) idassert-bind with SASL issues
by hyc＠symas.com 04 Mar '11

04 Mar '11

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: >>> Full_Name: Pierangelo Masarati >>> Version: HEAD/re24 >>> OS: irrelevant >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (2.40.14.92) >>> Submitted by: ando >>> >>> >>> When idassert-bind is configured to use SASL bind, an "authcID" needs to >>> be >>> provided, while the "binddn" is not needed. However, if a "binddn" is >>> not >>> provided as well, in some cases the proxiedAuthz control may be used >>> incorrectly. The need to configure the "binddn" is not documented, so >>> this ITS >>> is minimally addressed by documenting this requirement. >> >> I tripped over this change while investigating #6711. Adding this >> requirement >> is certainly not the right solution; SASL Binds ordinarily don't require a >> BindDN and requiring it here just makes things confusing. > > I understand the fix I'm suggesting can sound counter-intuitive. The > documentation should clearly indicate that the binddn in case of SASL is > for *local* and *internal* issues, and will not be part of the > authentication process. As an alternative, lc_bound_ndn could receive a > dummy DN (e.g. "cn=auth") to merely indicate a successful bind (or receive > the actual identity from the remote server using the authid control along > with the bind or performing a whoami extop later, as already implemented). Using a dummy DN here sounds OK. -- -- 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

← Newer
1
...
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2011