- openldap-bugs - openldap.org

(ITS#5566) ACL Documentation Update
by fkhan＠emergen.biz 17 Jun '08

17 Jun '08

Full_Name: Faraz Khan Version: 2.4.7 OS: Linux Debian Etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.133.78.60) Documentation update: OpenLdap 2.4 allows the use of the ADD and Zap ACLs (in addition to write) to finely control whether an ADD or a Zap is allowed. Write = Add + Zap This is not documented anywhere- was told to me by Pierangelo Masarati

1 0

Re: (ITS#5565) slapd crashes due to SIGPIPE
by hyc＠symas.com 17 Jun '08

17 Jun '08

jwm(a)horde.net wrote: > Full_Name: John Morrissey > Version: RE23-20080612 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4830:120d:0:21f:5bff:fee9:da92) > > > The fix for ITS 5469 stopped the assertion failures that caused slapd to crash, > but slapd continues to crash every few days due to receipt of SIGPIPEs. That is not possible; slapd explicitly ignores SIGPIPE. > We had > been running 2.3.41 plus the fix for ITS 5469, but upgraded to RE23 as of about > a week ago to make sure a fix wasn't already present. Below is a representative > backtrace. This trace is not indicative of a crash. You have to tell gdb not to stop when SIGPIPE is received in order to get an accurate view of the program behavior: "handle SIGPIPE nostop" -- -- 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#5565) slapd crashes due to SIGPIPE
by jwm＠horde.net 17 Jun '08

17 Jun '08

Full_Name: John Morrissey Version: RE23-20080612 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4830:120d:0:21f:5bff:fee9:da92) The fix for ITS 5469 stopped the assertion failures that caused slapd to crash, but slapd continues to crash every few days due to receipt of SIGPIPEs. We had been running 2.3.41 plus the fix for ITS 5469, but upgraded to RE23 as of about a week ago to make sure a fix wasn't already present. Below is a representative backtrace. GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1212389152 (LWP 16459)] [New Thread -1883694160 (LWP 16466)] [New Thread -1879499856 (LWP 16465)] [New Thread -1875305552 (LWP 16464)] [New Thread -1538548816 (LWP 16463)] Failed to read a valid object file image from memory. 0xb7d14183 in pthread_join () from /lib/tls/libpthread.so.0 [New Thread -1917846608 (LWP 16495)] [New Thread -1931486288 (LWP 16496)] [New Thread -1935680592 (LWP 16497)] [New Thread -1939874896 (LWP 16498)] [New Thread -1944069200 (LWP 16499)] [New Thread -1948263504 (LWP 16500)] [New Thread -1952457808 (LWP 16501)] [New Thread -1956652112 (LWP 16502)] [New Thread -1960846416 (LWP 16503)] [New Thread -1965040720 (LWP 16504)] [New Thread -2121270352 (LWP 16587)] [New Thread 2132802480 (LWP 16724)] [New Thread 2079325104 (LWP 17194)] [New Thread 2032139184 (LWP 17346)] [New Thread 2027944880 (LWP 17347)] [New Thread 2023750576 (LWP 17348)] Program received signal SIGPIPE, Broken pipe. [Switching to Thread -2121270352 (LWP 16587)] 0xb7d18391 in __write_nocancel () from /lib/tls/libpthread.so.0 Thread 21 (Thread 2023750576 (LWP 17348)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x90bee38, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x46, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0xca, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x77cfe008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2023750576 i = 706 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 20 (Thread 2027944880 (LWP 17347)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x9579580, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x45, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0xc9, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x76bfb008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2027944880 i = 770 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 19 (Thread 2032139184 (LWP 17346)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x9447908, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x821d048, ltk_data = 0xcb, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x773fc008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x8217b18, ltk_data = 0x48, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2032139184 i = 579 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 18 (Thread 2079325104 (LWP 17194)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x96a2e18, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x43, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0xc3, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x7b1fe008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2079325104 i = 789 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 17 (Thread 2132802480 (LWP 16724)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x9a85110, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x3f, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0xb9, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x7e4fe008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2132802480 i = 585 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 16 (Thread -2121270352 (LWP 16587)): #0 0xb7d18391 in __write_nocancel () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f7117b in sb_stream_write (sbiod=0x752a7210, buf=0x7cd5c0f0, len=991) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/liblber/sockbuf.c:521 __PRETTY_FUNCTION__ = "sb_stream_write" #2 0xb7f7031a in sb_debug_write (sbiod=0x81a1a700, buf=0x7cd5c0f0, len=991) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/liblber/sockbuf.c:820 ret = <value optimized out> ebuf = "®◊\203\201\024\004∑\001\000\000\000»◊\203\201¡Â∑\214\203\201\001\000\000\000ÿ◊\203\201¡Â∑Ù\237∑\020\000∞\215∞\220E\177ÿ◊\203\201\214\203\201\002\000\000\000¯◊\203\201\206Â∑Ù\237∑\020\000∞\215\000|\006v¯◊\203\201\" ∑\020\000∞\215\000|\006vÃ=∑ﬂ\003\000\000\214\203\201\030ÿ\203\201\032Û∑\000|\006v&ÿ\203\201\002\000\000" #3 0xb7f706fa in ber_int_sb_write (sb=0x805e85c8, buf=0x7cd5c0f0, len=991) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/liblber/sockbuf.c:431 ret = 2094383344 __PRETTY_FUNCTION__ = "ber_int_sb_write" #4 0xb7f6e271 in ber_flush (sb=0x805e85c8, ber=0x8183dc8c, freeit=0) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/liblber/io.c:232 towrite = 991 rc = <value optimized out> __PRETTY_FUNCTION__ = "ber_flush" #5 0x0807bc50 in send_ldap_ber (conn=0x90395258, ber=0x8183dc8c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/result.c:169 err = <value optimized out> sd = 135491153 bytes = <value optimized out> #6 0x0807dd19 in slap_send_search_entry (op=0x8249e30, rs=0x818ff244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/result.c:1137 a_flags = 0x1 <Address 0x1 out of bounds> berbuf = {buffer = "\002\000\001\000\000\000\000\000ˇˇˇˇ\000\000\000\000\000\000\000\000¿||\203∆|\000\000\000\000¿|`\004$\b(\203\201÷\b\b0\236$\b@ÍÎ\177®m\024\b\000\000\000\000\004\000\000\000\000\000\000\000\030\203\201Ê\037§∑Tﬁ\031\b\f\203\201\f\203\201\030Î˙∑\bﬂ\031\b\000\000\000\000Pl\024\bÿ\031\bhÍÎ\177®m\024\b(\203\201©]\a\b®m\024\b®m\024\b\177\023\000\000\234\202§∑\234\202§∑®m\024\b®\203\201<∞\b\bhÍÎ\177®m\024\b®m\024\b\000\000\000\000\004", '\0' <repeats 11 times>, "|ÍÎ\177|ÍÎ\177@"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = (BerElement *) 0x8183dc8c a = (Attribute *) 0x8 i = 1 j = <value optimized out> rc = <value optimized out> edn = 0x7bf73fe9 "uid=frro,dc=example,dc=net,ou=example,ou=services,o=example" userattrs = 1 acl_state = {as_recorded = 3, as_vd_acl = 0x0, as_vi_acl = 0x0, as_vd_acl_mask = 0, as_vd_acl_matches = {{rm_so = 0, rm_eo = 0} <repeats 100 times>}, as_vd_acl_count = 0, as_vd_access = 0x0, as_vd_access_count = 0, as_result = 1, as_vd_ad = 0x8147818} attrsonly = 0 ad_entry = (AttributeDescription *) 0x814ad90 e_flags = (char **) 0x0 #7 0xb7a36c47 in bdb_search (op=0x8249e30, rs=0x818ff244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/search.c:879 tmp = <value optimized out> bdb = (struct bdb_info *) 0x819dda0 id = 22974 cursor = 22974 candidates = {4294967295, 1, 1313262, 1313262, 129256, 148982, 223840, 230794, 237887, 289589, 317961, 341644, 367994, 378937, 378938, 453353, 465641, 490658, 503779, 667838, 668870, 671656, 724757, 753641, 764925, 777799, 792698, 812499, 812975, 812987, 814369, 817151, 877121, 898662, 983276, 1112627, 1119375, 1153429, 1254426, 1259766, 1266923, 490658, 502854, 503779, 503780, 528024, 540294, 555215, 568268, 656373, 666293, 667838, 668117, 668249, 668870, 670958, 671656, 671658, 671659, 700279, 708367, 718093, 718369, 724757, 724761, 724780, 724786, 724824, 724825, 724826, 724827, 724828, 724829, 724830, 724831, 738243, 738244, 753641, 758836, 758920, 764925, 764935, 777799, 778136, 784632, 792698, 793162, 800788, 803042, 803175, 803252, 803278, 803279, 808236, 808237, 808238, 808239, 808240, 808241, 808242, 808243, 808244, 808245, 808246, 808247, 808248, 808249, 808250, 808251, 808252, 808253, 808254, 808255, 808256, 808257, 808259, 808260, 808261, 808262, 808263, 808264, 808265, 809986, 812499, 812561, 812580, 812581, 812583, 812975, 812987, 813382, 814369, 817151, 817178, 817202, 819246, 821181, 827140, 840827, 861880, 861882, 873796, 875019, 877121, 898662, 905424, 905652, 905765, 914437, 916170, 931884, 931885, 931886, 931887, 931888, 931889, 931890, 932267, 932567, 933299, 933300, 933303, 933312, 937699, 939581, 939839, 939840, 939841, 945216, 947697, 950353, 950568, 957598, 957615, 958338, 960887, 962469, 962649, 974914, 976521, 978098, 981242, 983276, 992317, 1003794, 1004230, 1009998, 1009999, 1010000, 1010001, 1010002, 1010003, 1010004, 1010005, 1010006, 1010145, 1010190, 1010505, 1011375, 1091234...} scopes = {0 <repeats 63708 times>, 3083069555, 0, 0, 3083012398, 135256458, 135256458, 0, 3083902964, 135256453, 5, 2173683752, 3082911727, 2173683788, 135256453, 5, 0, 0, 0, 2173683604, 3082910637, 0, 0, 2173683712, 0 <repeats 12 times>, 2173683936, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4294967295, 25, 135256458, 135256451, 2173683604, 0, 11, 0 <repeats 16 times>, 1931476992, 20, 0 <repeats 29 times>, 135256452, 0, 0, 4294967295, 0, 0, 0, 2173684080, 0 <repeats 20 times>, 1858376075, 2173684964, 134914208, 2173684964, 2173682712, 134914251, 2222693328, 135575384, 0, 0, 0, 135575720, 2173682744, 135122385, 2173684964, 135575704, 0, 2173684964, 2173685080, 2173685084, 2173682776, 134911775, 135557712, 2173684964, 134914208, 0, 2173685080, 2173685084, 2173685000, 134906653, 2173682900, 0, 1032, 0, 0, 0, 0, 0, 2222693328, 0, 0, 2222693330, 0, 0, 0, 0, 0, 2, 135575504, 0 <repeats 32 times>, 135911368, 2173687244, 135822104, 2173683016, 134712206, 2173687244, 2173687824, 2173685096, 134802567, 2173687672, 0 <repeats 14 times>, 135911368, 2173687244, 135556520, 135821720, 134712206, 2173687244, 2173687824, 2173685192, 134802567, 2173687672, 0, 5119, 0 <repeats 15 times>...} e = (Entry *) 0x1 base = {e_id = 1, e_name = {bv_len = 593113393, bv_val = 0x30303030 <Address 0x30303030 out of bounds>}, e_nname = {bv_len = 10, bv_val = 0x7c04b408 "o=example"}, e_attrs = 0x30303030, e_ocflags = 0, e_bv = {bv_len = 3086412783, bv_val = 0x7ff70d80 "0\025\n\001\001\004\020\210¥æy\035\020'\236y©\200\\¿'"}, e_private = 0x821f418} e_root = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} matched = (Entry *) 0x0 ei = (EntryInfo *) 0x84012780 ei_root = {bei_parent = 0x0, bei_id = 0, bei_lockpad = 0, bei_state = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0} realbase = {bv_len = 10, bv_val = 0x7c04b408 "o=example"} manageDSAit = 2 tentries = 1313262 lastid = 4294967295 locker = 169 lock = {off = 288056, ndx = 642, gen = 153211, mode = DB_LOCK_READ} ltid = (DB_TXN *) 0x0 #8 0x080c57e0 in overlay_op_walk (op=0x8249e30, rs=0x818ff244, which=op_search, oi=0x819ed18, on=0x819f0e8) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/backover.c:650 sc_next = <value optimized out> rc = 32768 #9 0x080c5bde in over_op_func (op=0x8249e30, rs=0x818ff244, which=op_search) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/backover.c:702 oi = (slap_overinfo *) 0x819ed18 on = (slap_overinst *) 0x819f0e8 be = (BackendDB *) 0x819dc98 db = {bd_info = 0xb7a489c0, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x819e028, be_nsuffix = 0x819e040, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 18, bv_val = 0x819d880 "cn=root,o=example"}, be_rootndn = {bv_len = 18, bv_val = 0x819e300 "cn=root,o=example"}, be_rootpw = {bv_len = 20, bv_val = 0x819e078 "{crypt}bo3zUPoqIZwko"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x819d900, be_acl = 0x818c9e8, be_dfltaccess = ACL_READ, be_replica = 0x819e680, be_replogfile = 0x819b958 "/var/lib/ldap/replog", be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x82257d0, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0x819dd68, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xb7a48660, be_private = 0x819dda0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x0, sc_response = 0x80c5550 <over_back_response>, sc_cleanup = 0, sc_private = 0x819ed18} rc = -32 __PRETTY_FUNCTION__ = "over_op_func" #10 0x0806f852 in fe_op_search (op=0x8249e30, rs=0x818ff244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/search.c:355 entry = (Entry *) 0x11 bd = (BackendDB *) 0x813f120 #11 0x0807015b in do_search (op=0x8249e30, rs=0x818ff244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/search.c:217 base = {bv_len = 10, bv_val = 0x7d8ede07 "o=example"} siz = 2 i = 2098471528 #12 0x0806d5cb in connection_operation (ctx=0x818ff2c8, arg_v=0x8249e30) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/connection.c:1133 curelm = <value optimized out> rc = <value optimized out> rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x814fefe4, sr_un = {sru_sasl = {r_sasldata = 0x7febea40}, sru_extended = {r_rspoid = 0x7febea40 "æY", r_rspdata = 0x22}, sru_search = {r_entry = 0x7febea40, r_attr_flags = 34, r_operational_attrs = 0x7ff58880, r_attrs = 0x813ff0e4, r_nentries = 18048, r_v2ref = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = (Connection *) 0x90395258 memctx = (void *) 0x8240460 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #13 0xb7f80eff in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:478 ctx = (ldap_int_thread_ctx_t *) 0x7f2a5738 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8240460, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x3e, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0xa9, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x80bfe008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2173696944 i = 699 hash = <value optimized out> #14 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #15 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 15 (Thread -1965040720 (LWP 16504)): #0 bdb_idl_next (ids=0x87df1008, cursor=0x8ad3bae8) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/idl.c:1283 No locals. #1 0xb7a3e374 in bdb_idl_union (a=0x87df1008, b=0x87cf1008) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/idl.c:1155 ida = 2035086 idb = 2075672 cursora = 66972 cursorb = 1 cursorc = 66972 #2 0xb7a39b78 in inequality_candidates (op=0x8db15bd8, ava=0x8a7fc1f4, ids=0x87df1008, tmp=0x87cf1008, gtorlt=165) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/filterindex.c:1063 db = (DB *) 0x82257e0 rc = 0 mask = 4 prefix = {bv_len = 8, bv_val = 0x8147df8 "entryCSN"} keys = (struct berval *) 0x8a7fc31c mr = <value optimized out> cursor = (DBC *) 0x8225d78 #3 0xb7a3ae77 in bdb_filter_candidates (op=0x8db15bd8, f=0x8a7fc1e4, ids=0x87df1008, tmp=0x87cf1008, stack=0x87e71008) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/filterindex.c:168 rc = <value optimized out> #4 0xb7a3a0d8 in list_candidates (op=0x8db15bd8, flist=0x8a7fc1e4, ftype=160, ids=0x87d71008, tmp=0x87cf1008, save=0x87df1008) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/filterindex.c:503 rc = 0 f = (Filter *) 0x8a7fc1e4 #5 0xb7a3a902 in bdb_filter_candidates (op=0x8db15bd8, f=0x8a7fc1d4, ids=0x87d71008, tmp=0x87cf1008, stack=0x87df1008) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/filterindex.c:183 rc = <value optimized out> #6 0xb7a3a0d8 in list_candidates (op=0x8db15bd8, flist=0x8adfbf74, ftype=160, ids=0x8ad3be7c, tmp=0x87cf1008, save=0x87d71008) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/filterindex.c:503 rc = 0 f = (Filter *) 0x8a7fc1d4 #7 0xb7a3a902 in bdb_filter_candidates (op=0x8db15bd8, f=0x8adfbf98, ids=0x8ad3be7c, tmp=0x87cf1008, stack=0x87d71008) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/filterindex.c:183 rc = <value optimized out> #8 0xb7a3588f in bdb_search (op=0x8db15bd8, rs=0x8adfd244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/back-bdb/search.c:1124 reqcookie = <value optimized out> bdb = (struct bdb_info *) 0x819d478 id = <value optimized out> cursor = <value optimized out> candidates = {4294967295, 1, 2080041, 1313249, 37648, 55686, 74393, 101230, 123347, 126534, 129256, 132836, 136049, 139750, 142174, 146626, 148982, 185595, 223840, 230794, 237887, 289589, 289590, 289591, 290042, 301562, 317960, 317961, 341643, 341644, 367994, 372843, 378937, 378938, 390817, 424400, 424401, 453353, 464904, 465641, 490657, 490658, 502854, 503779, 503780, 528024, 540294, 555215, 568268, 656373, 666293, 667838, 668117, 668249, 668870, 670958, 671656, 671658, 671659, 700279, 708367, 718093, 718369, 724757, 724761, 724780, 724786, 724824, 724825, 724826, 724827, 724828, 724829, 724830, 724831, 738243, 738244, 753641, 758836, 758920, 764925, 764935, 777799, 778136, 784632, 792698, 793162, 800788, 803042, 803175, 803252, 803278, 803279, 808236, 808237, 808238, 808239, 808240, 808241, 808242, 808243, 808244, 808245, 808246, 808247, 808248, 808249, 808250, 808251, 808252, 808253, 808254, 808255, 808256, 808257, 808259, 808260, 808261, 808262, 808263, 808264, 808265, 809986, 812499, 812561, 812580, 812581, 812583, 812975, 812987, 813382, 814369, 817151, 817178, 817202, 819246, 821181, 827140, 840827, 861880, 861882, 873796, 875019, 877121, 898662, 905424, 905652, 905765, 914437, 916170, 931884, 931885, 931886, 931887, 931888, 931889, 931890, 932267, 932567, 933299, 933300, 933303, 933312, 937699, 939581, 939839, 939840, 939841, 945216, 947697, 950353, 950568, 957598, 957615, 958338, 960887, 962469, 962649, 974914, 976521, 978098, 981242, 983276, 992317, 1003794, 1004230, 1009998, 1009999, 1010000, 1010001, 1010002, 1010003, 1010004, 1010005, 1010006, 1010145, 1010190, 1010505, 1011375, 1091234...} scopes = {0 <repeats 63708 times>, 3083069555, 0, 0, 3083012398, 135256458, 135256458, 0, 3083902964, 135256453, 5, 2329913384, 3082911727, 2329913420, 135256453, 5, 0, 0, 0, 2329913236, 3082910637, 0, 0, 2329913344, 0 <repeats 12 times>, 2329913568, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4294967295, 25, 135256458, 135256451, 2329913236, 0, 11, 0 <repeats 16 times>, 1931476992, 20, 0 <repeats 29 times>, 135256452, 0, 0, 4294967295, 0, 0, 0, 2329913712, 0 <repeats 20 times>, 1858376075, 2329914596, 134914208, 2329914596, 2329912344, 134914251, 161455880, 135575384, 0, 0, 0, 135575720, 2329912376, 135122385, 2329914596, 135575704, 0, 2329914596, 2329914712, 2329914716, 2329912408, 134911775, 135557712, 2329914596, 134914208, 0, 2329914712, 2329914716, 2329914632, 134906653, 2329912532, 0, 1032, 0, 0, 0, 0, 0, 161455880, 0, 0, 161455882, 0, 0, 0, 0, 0, 2, 135575504, 0 <repeats 32 times>, 135911368, 2329916876, 135822104, 2329912648, 134712206, 2329916876, 2329917456, 2329914728, 134802567, 2329917304, 0 <repeats 14 times>, 135911368, 2329916876, 135556520, 135821720, 134712206, 2329916876, 2329917456, 2329914824, 134802567, 2329917304, 0, 5119, 0 <repeats 15 times>...} e = <value optimized out> base = {e_id = 1, e_name = {bv_len = 593114419, bv_val = 0x30303030 <Address 0x30303030 out of bounds>}, e_nname = {bv_len = 6, bv_val = 0x8077c970 "cn=log"}, e_attrs = 0x30303030, e_ocflags = 0, e_bv = {bv_len = 3086412783, bv_val = 0x0}, e_private = 0x8225420} e_root = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} matched = (Entry *) 0x0 ei = (EntryInfo *) 0x8225420 ei_root = {bei_parent = 0x0, bei_id = 0, bei_lockpad = 0, bei_state = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0} realbase = {bv_len = 6, bv_val = 0x8077c970 "cn=log"} manageDSAit = 2 tentries = <value optimized out> lastid = 4294967295 locker = 52 lock = {off = 0, ndx = 386, gen = 30592, mode = DB_LOCK_READ} ltid = (DB_TXN *) 0x0 #9 0x080c57e0 in overlay_op_walk (op=0x8db15bd8, rs=0x8adfd244, which=op_search, oi=0x819d960, on=0x819da60) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/backover.c:650 sc_next = <value optimized out> rc = 32768 #10 0x080c5bde in over_op_func (op=0x8db15bd8, rs=0x8adfd244, which=op_search) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/backover.c:702 oi = (slap_overinfo *) 0x819d960 on = (slap_overinst *) 0x819da60 be = (BackendDB *) 0x819d370 db = {bd_info = 0xb7a489c0, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x819d728, be_nsuffix = 0x819d740, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 14, bv_val = 0x819d5e0 "cn=root,cn=log"}, be_rootndn = {bv_len = 14, bv_val = 0x819d7c8 "cn=root,cn=log"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x819d7b8, be_acl = 0x818c9e8, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8217800, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0x819d440, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xb7a48660, be_private = 0x819d478, be_next = {stqe_next = 0x819dc98}} cb = {sc_next = 0x0, sc_response = 0x80c5550 <over_back_response>, sc_cleanup = 0, sc_private = 0x819d960} rc = 66972 __PRETTY_FUNCTION__ = "over_op_func" #11 0x0806f852 in fe_op_search (op=0x8db15bd8, rs=0x8adfd244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/search.c:355 entry = (Entry *) 0x36 bd = (BackendDB *) 0x813f120 #12 0x0807015b in do_search (op=0x8db15bd8, rs=0x8adfd244) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/search.c:217 base = {bv_len = 6, bv_val = 0x7a8f4e0f "cn=log"} siz = 2 i = 135910464 #13 0x0806d5cb in connection_operation (ctx=0x8adfd2c8, arg_v=0x8db15bd8) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/connection.c:1133 curelm = <value optimized out> rc = <value optimized out> rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = (Connection *) 0x90395dd8 memctx = (void *) 0x8436bc8 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #14 0xb7f80eff in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:478 ctx = (ldap_int_thread_ctx_t *) 0x8db10070 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8436bc8, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x34, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0x70, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x87cf1008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2329926576 i = 756 hash = <value optimized out> #15 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #16 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 14 (Thread -1960846416 (LWP 16503)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8db13408, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x38, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0x67, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x88cf3008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2334120880 i = 565 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 13 (Thread -1956652112 (LWP 16502)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8a600470, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x39, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0x7a, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x864ee008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2338315184 i = 629 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 12 (Thread -1952457808 (LWP 16501)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8db11ab0, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x35, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0x9b, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x854ec008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2342509488 i = 693 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 11 (Thread -1948263504 (LWP 16500)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8438b90, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x3d, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0x9a, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x85ced008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2346703792 i = 757 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 10 (Thread -1944069200 (LWP 16499)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8a600498, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x3c, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0x60, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x895f5008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2350898096 i = 566 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 9 (Thread -1939874896 (LWP 16498)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8436b20, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x3a, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0x68, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x884f2008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2355092400 i = 630 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 8 (Thread -1935680592 (LWP 16497)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8435218, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x37, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0x73, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x86cef008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2359286704 i = 694 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 7 (Thread -1931486288 (LWP 16496)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8436b48, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x3b, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x821d048, ltk_data = 0x71, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x874f0008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2363481008 i = 758 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 6 (Thread -1917846608 (LWP 16495)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8437a28, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x821d048, ltk_data = 0x5f, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x8cdfe008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x8217b18, ltk_data = 0x36, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2377120688 i = 743 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 5 (Thread -1538548816 (LWP 16463)): #0 0xb7d18189 in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7d14f6d in _L_mutex_lock_29 () from /lib/tls/libpthread.so.0 No symbol table info available. #2 0xa44b6258 in ?? () No symbol table info available. #3 0xb7f6d846 in ber_get_next (sb=0x90395268, len=0x90395258, ber=0x404f) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/liblber/io.c:504 sblen = <value optimized out> buf = "\000\000" tlen = 2419675752 __PRETTY_FUNCTION__ = "ber_get_next" #4 0xb7f816bd in ldap_pvt_thread_mutex_lock (mutex=0x90395268) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:333 No locals. #5 0x0806bc51 in connection_get (s=35) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/connection.c:308 sd = <value optimized out> c = (Connection *) 0x90395258 __PRETTY_FUNCTION__ = "connection_get" #6 0x0806d99e in connection_read (s=35) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/connection.c:1308 rc = <value optimized out> c = <value optimized out> __PRETTY_FUNCTION__ = "connection_read" #7 0x0806a3f1 in slapd_daemon_task (ptr=0x0) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/daemon.c:2468 r = 1 w = <value optimized out> l = 4 last_idle_check = 0 ebadf = 0 #8 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #9 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 4 (Thread -1875305552 (LWP 16464)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x823ef08, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8217b18, ltk_data = 0x1c, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x8ee90008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x821d048, ltk_data = 0x42, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2419661744 i = 404 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 3 (Thread -1879499856 (LWP 16465)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8254340, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x821d048, ltk_data = 0x46, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x8dc8c008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x8217b18, ltk_data = 0x32, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2415467440 i = 595 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 2 (Thread -1883694160 (LWP 16466)): #0 0xb7d15c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f81033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8246938, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x821d048, ltk_data = 0x34, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0xb7a34800, ltk_data = 0x8e48d008, ltk_free = 0xb7a348d0 <search_stack_free>}, {ltk_key = 0x8217b18, ltk_data = 0x33, ltk_free = 0xb7a412e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2411273136 i = 531 hash = <value optimized out> #3 0xb7d130bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca801e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 1 (Thread -1212389152 (LWP 16459)): #0 0xb7d14183 in pthread_join () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81894 in ldap_pvt_thread_join (thread=2756418480, thread_return=0x0) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/thr_posix.c:193 No locals. #2 0x08067b06 in slapd_daemon () at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/daemon.c:2579 listener_tid = 2756418480 rc = 0 #3 0x0805a309 in main (argc=9, argv=0xbf8f7694) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/main.c:859 save_errno = <value optimized out> fp = <value optimized out> i = 9 no_detach = 0 rc = 1 urls = 0x8140008 "ldap:/// ldaps:///" username = 0x8140030 "gidNumber" groupname = 0x8140020 "\202ﬁ∑∞\213∑" sandbox = 0x0 syslogUser = 160 configfile = 0x8140040 "/etc/ldap/slapd.conf.master" configdir = 0x0 serverName = <value optimized out> scp = <value optimized out> scp_entry = <value optimized out> debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 l = <value optimized out> slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 __PRETTY_FUNCTION__ = "main" #0 0xb7d18391 in __write_nocancel () from /lib/tls/libpthread.so.0

1 0

Re: (ITS#5561) SEGV using TLS/SASL
by hyc＠symas.com 17 Jun '08

17 Jun '08

lea.anthony(a)meirion-dwyfor.ac.uk wrote: > Full_Name: Lea Anthony > Version: 2.3.40 > OS: Arch Linux > URL: http://pastebin.com/f6b680f22 > Submission from: (NULL) (194.82.229.100) > > > I have TLS setup as follows: > > TLSCertificateFile /etc/openldap/certs/cert.pem > TLSCertificateKeyFile /etc/openldap/certs/key.pem > TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 > > The server starts fine and doing "ldapsearch -x -ZZ" will do an anonymous bind > fine. > > However, doing "ldapsearch -ZZ" will cause a segfault on the server. The > pastebin URL contains the post SSL negotiation debug lines from "slapd -d -1". I'm unable to reproduce this crash. Please provide a stack trace. http://www.openldap.org/faq/data/cache/59.html -- -- 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#5564) Use largest contextCSN to determine staleness?
by hyc＠symas.com 17 Jun '08

17 Jun '08

rein(a)OpenLDAP.org wrote: > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. > > --8323329-1817437300-1213728437=:15378 > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > On Mon, 16 Jun 2008, rein(a)OpenLDAP.org wrote: > > rein(a)OpenLDAP.org wrote: > >> A fix that seems to solve this is that syncprov_findbase(FIND_CSN) >> should search for entries whose entryCSN value is less than the >> largest contextCSN presented by the client. All the test scripts >> succeed if I try this, but I'm not convinced that this is the correct >> fix. Would it not be more correct to ignore the entire CSN set >> presented by the consumer when it has been determined as stale. > > After looking a bit more on this I'm more convinced that the alternative > fix is the correct. A patch that implements this is attached, all tests > succeed with it. Howard, can you approve or comment on it? This patch looks OK to me, go ahead and commit. -- -- 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#5564) Use largest contextCSN to determine staleness?
by rein＠OpenLDAP.org 17 Jun '08

17 Jun '08

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1817437300-1213728437=:15378 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Mon, 16 Jun 2008, rein(a)OpenLDAP.org wrote: rein(a)OpenLDAP.org wrote: > A fix that seems to solve this is that syncprov_findbase(FIND_CSN) > should search for entries whose entryCSN value is less than the > largest contextCSN presented by the client. All the test scripts > succeed if I try this, but I'm not convinced that this is the correct > fix. Would it not be more correct to ignore the entire CSN set > presented by the consumer when it has been determined as stale. After looking a bit more on this I'm more convinced that the alternative fix is the correct. A patch that implements this is attached, all tests succeed with it. Howard, can you approve or comment on it? Rein --8323329-1817437300-1213728437=:15378 Content-Type: TEXT/x-diff; name=ITS-5564.patch Content-Transfer-Encoding: BASE64 Content-ID: <alpine.DEB.1.00.0806172047070.15378(a)monster.tollevik.no> Content-Description: Content-Disposition: attachment; filename=ITS-5564.patch SW5kZXg6IHNlcnZlcnMvc2xhcGQvb3ZlcmxheXMvc3luY3Byb3YuYw0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9mL0NWU1JPT1QvZHJp ZnQvT3BlbkxEQVAvc2VydmVycy9zbGFwZC9vdmVybGF5cy9zeW5jcHJvdi5j LHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4zMA0KZGlmZiAtdSAtdSAtcjEu MzAgc3luY3Byb3YuYw0KLS0tIHNlcnZlcnMvc2xhcGQvb3ZlcmxheXMvc3lu Y3Byb3YuYwkxMyBKdW4gMjAwOCAxMzo0OTozNiAtMDAwMAkxLjMwDQorKysg c2VydmVycy9zbGFwZC9vdmVybGF5cy9zeW5jcHJvdi5jCTE3IEp1biAyMDA4 IDEzOjA3OjUxIC0wMDAwDQpAQCAtMjMyMyw2ICsyMzIzLDE1IEBADQogCQkJ CXNlbmRfbGRhcF9lcnJvciggb3AsIHJzLCBMREFQX1NZTkNfUkVGUkVTSF9S RVFVSVJFRCwgInN5bmMgY29va2llIGlzIHN0YWxlIiApOw0KIAkJCQlyZXR1 cm4gcnMtPnNyX2VycjsNCiAJCQl9DQorCQkJaWYgKCBzcnMtPnNyX3N0YXRl LmN0eGNzbiApIHsNCisJCQkJYmVyX2J2YXJyYXlfZnJlZV94KCBzcnMtPnNy X3N0YXRlLmN0eGNzbiwgb3AtPm9fdG1wbWVtY3R4ICk7DQorCQkJCXNycy0+ c3Jfc3RhdGUuY3R4Y3NuID0gTlVMTDsNCisJCQl9DQorCQkJaWYgKCBzcnMt PnNyX3N0YXRlLnNpZHMgKSB7DQorCQkJCXNsYXBfc2xfZnJlZSggc3JzLT5z cl9zdGF0ZS5zaWRzLCBvcC0+b190bXBtZW1jdHggKTsNCisJCQkJc3JzLT5z cl9zdGF0ZS5zaWRzID0gTlVMTDsNCisJCQl9DQorCQkJc3JzLT5zcl9zdGF0 ZS5udW1jc25zID0gMDsNCiAJCX0gZWxzZSB7DQogCQkJZ290c3RhdGUgPSAx Ow0KIAkJCS8qIElmIGNoYW5nZWQgYW5kIGRvaW5nIFByZXNlbnQgbG9va3Vw LCBzZW5kIFByZXNlbnQgVVVJRHMgKi8NCg== --8323329-1817437300-1213728437=:15378--

1 0

Re: (ITS#5556) ldapadd/slapadd create objects without RDN
by joshua＠itsecureadmin.com 17 Jun '08

17 Jun '08

> Well, pre-2.4.9 versions would reject the Add operation... Is it > 2.4.10 built from the OpenLDAP source, or some prepackaged binary? I built RPMs from the source, without any patches: DB: ../dist/configure \ --enable-shared \ --disable-static \ --program-prefix=slapd \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --libexecdir=/usr/sbin \ --datadir=/var/lib \ --sysconfdir=/etc \ --localstatedir=/var/lib \ --libdir=/usr/lib \ --includedir=/usr/include \ --mandir=/usr/share/man \ --disable-posixmutexes \ --with-mutex=x86/gcc-assembly \ OL: ./configure \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --libexecdir=/usr/sbin \ --datadir=/var/lib \ --sysconfdir=/etc \ --localstatedir=/var/lib \ --libdir=/usr/lib \ --includedir=/usr/include \ --mandir=/usr/share/man \ --enable-backends=mod \ --enable-cleartext \ --enable-crypt \ --enable-ipv6 \ --enable-ldap \ --enable-local \ --enable-modules \ --enable-overlays=mod \ --enable-slapd \ --enable-rewrite \ --enable-syslog \ --with-tls \ --with-threads \ > Maybe an overlay or something interferes with auto-adding the naming > attrs? Please post your slapd.conf too, after removing passwords etc. My sanitized slapd.conf: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/corba.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/krb5-kdc.schema include /etc/openldap/schema/kerberosobject.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/autofs.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/kolab.schema include /etc/openldap/schema/evolutionperson.schema include /etc/openldap/schema/calendar.schema include /etc/openldap/schema/sudo.schema include /etc/openldap/schema/dnszone.schema include /etc/openldap/schema/dhcp.schema include /etc/openldap/schema/postfix-mail.schema access to dn.exact="" by * read access to dn.subtree="cn=Subschema" by * read access to dn.subtree="ou=people,dc=openldap,dc=example,dc=com" by group="cn=replicator accounts,ou=group,dc=openldap,dc=example,dc=com" read by peername.ip=10.12.31.6 anonymous read by peername.ip=10.12.31.7 anonymous read access to dn.subtree="ou=vmail,dc=openldap,dc=example,dc=com" by group="cn=replicator accounts,ou=group,dc=openldap,dc=example,dc=com" read by peername.ip=10.12.31.6 anonymous read by peername.ip=10.12.31.7 anonymous read access to dn.subtree="ou=idmap,dc=openldap,dc=example,dc=com" by group="cn=idmap admins,ou=group,dc=openldap,dc=example,dc=com" write by group="cn=replicator accounts,ou=group,dc=openldap,dc=example,dc=com" read by users read by * auth access to attrs=userPassword,sambaLMPassword,sambaNTPassword by self write by group="cn=replicator accounts,ou=group,dc=openldap,dc=example,dc=com" read by anonymous auth by * none access to * by group="cn=admins,ou=group,dc=openldap,dc=example,dc=com" write by group="cn=replicator accounts,ou=group,dc=openldap,dc=example,dc=com" read by self read by anonymous auth pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args #sizelimit unlimited #timelimit unlimited modulepath /usr/sbin/openldap moduleload ppolicy.la moduleload syncprov.la moduleload back_bdb.la moduleload back_monitor.la TLSRandFile /dev/random TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile /etc/pki/tls/certs/server01.crt TLSCertificateKeyFile /etc/pki/tls/private/server01.key TLSCACertificateFile /etc/pki/tls/certs/domain-server01.crt security ssf=128 loglevel 256 database config rootdn cn=config rootpw secret #serverid 1 ldap://server03.example.com #serverid 2 ldap://server01.example.com #syncrepl rid=001 # provider=ldap://server01.example.com # binddn="cn=config" # bindmethod=simple # credentials=secret # searchbase="cn=config" # type=refreshAndPersist # starttls=yes # tls_reqcert=never # retry="5 5 300 5" # timeout=5 #syncrepl rid=002 # provider=ldap://server03.example.com # binddn="cn=config" # bindmethod=simple # credentials=secret # searchbase="cn=config" # type=refreshAndPersist # starttls=yes # tls_reqcert=never # retry="5 5 300 5" # timeout=5 #mirrormode true #overlay syncprov #syncprov-checkpoint 100 10 #syncprov-sessionlog 100 database monitor rootdn cn=monitor rootpw secret database bdb suffix "dc=openldap,dc=example,dc=com" rootdn "cn=manager,dc=openldap,dc=example,dc=com" rootpw secret directory /var/lib/ldap serverid 3 ldap://server01.example.com serverid 4 ldap://server03.example.com cachesize 10000 checkpoint 256 5 syncrepl rid=003 provider=ldap://server01.example.com binddn="uid=replicator,ou=service-accounts,dc=openldap,dc=example,dc=com" bindmethod=simple credentials=secret searchbase="dc=openldap,dc=example,dc=com" type=refreshAndPersist starttls=yes tls_reqcert=never interval=00:00:00:10 retry="5 5 300 5" timeout=5 syncrepl rid=004 provider=ldap://server03.example.com binddn="uid=replicator,ou=service-accounts,dc=openldap,dc=example,dc=com" bindmethod=simple credentials=secret searchbase="dc=openldap,dc=example,dc=com" type=refreshAndPersist starttls=yes tls_reqcert=never interval=00:00:00:10 retry="5 5 300 5" timeout=5 mirrormode true overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 index objectClass eq index cn,mail,surname,givenname eq,subinitial index uidNumber,gidNumber,memberuid,member,uniqueMember eq index uid eq,subinitial index sambaSID,sambaDomainName,displayName eq index entryCSN,entryUUID eq index mailid eq limits group="cn=replicator accounts,ou=group,dc=openldap,dc=example,dc=com" size=unlimited time=unlimited Thanks! -- Josh Miller, RHCE

1 0

Re: (ITS#5556) ldapadd/slapadd create objects without RDN
by joshua＠itsecureadmin.com 17 Jun '08

17 Jun '08

> joshua(a)itsecureadmin.com wrote: > >> When adding an object with slapadd or ldapadd, it is possible to create >> an >> object which does not have an RDN, and therefore not searchable by RDN. > > Can't reproduce. Works as expected here (adding entry without naming > attributes/distinguished values results in automatically generating that > data, both by slapadd and ldapadd). Can you confirm software versions? To confirm versions: [root@server01 ldifs]# ldapadd -V ldapadd: @(#) $OpenLDAP: ldapmodify 2.4.10 (Jun 12 2008 11:02:00) $ joshm@server03.sky.dom:/home/SKY/joshm/redhat/BUILD/openldap-2.4.10/clients/tools (LDAP library: OpenLDAP 20410) ldap_sasl_interactive_bind_s: Confidentiality required (13) [root@server01 ldifs]# slapd -V @(#) $OpenLDAP: slapd 2.4.10 (Jun 12 2008 11:03:43) $ joshm@server03.sky.dom:/home/SKY/joshm/redhat/BUILD/openldap-2.4.10/servers/slapd I'm running on CentOS 5.1 with DB 4.6 -- I built these RPMs. Thanks, -- Josh Miller, RHCE

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by ando＠sys-net.it 17 Jun '08

17 Jun '08

andrew.findlay(a)skills-1st.co.uk wrote: > On Mon, Jun 16, 2008 at 08:06:17PM +0200, Pierangelo Masarati wrote: > >> Ah, OK. Note that since some point in 2.3, authorization is described >> by a specific syntax <http://www.openldap.org/faq/data/cache/1254.html>, >> which should probably be advertised a bit more (and moved out from the >> experimental OID arc). > > If that is used *everywhere* for authorisation then there could well > be more doc errors to correct. I am fairly sure I saw one place where > the docs specifically exclude some of those forms. Yes, I believe in some cases some of the variants of the syntax are not allowed. This is true, for example, in SASL identity mapping, which does not allow the regex, subtree, children, onelevel, group and users styles, only the base and uri forms are allowed (provided the latter only returns a single match). > I notice that '*' excludes anonymous in this spec. There is an > undocumented option to 'allow' that seems relevant: proxy_authz_anon - Why undocumented? It is documented (in 2.4, at least; it does not exist for 2.3). > would allowing this cause anon to be included in '*' generally or is > it not that simple? '*' implies a non-empty value; to include anonymous, use "dn.regex:.*", or "dn.subtree:". p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 17 Jun '08

17 Jun '08

On Mon, Jun 16, 2008 at 08:06:17PM +0200, Pierangelo Masarati wrote: > Ah, OK. Note that since some point in 2.3, authorization is described > by a specific syntax <http://www.openldap.org/faq/data/cache/1254.html>, > which should probably be advertised a bit more (and moved out from the > experimental OID arc). If that is used *everywhere* for authorisation then there could well be more doc errors to correct. I am fairly sure I saw one place where the docs specifically exclude some of those forms. I notice that '*' excludes anonymous in this spec. There is an undocumented option to 'allow' that seems relevant: proxy_authz_anon - would allowing this cause anon to be included in '*' generally or is it not that simple? Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by ando＠sys-net.it 16 Jun '08

16 Jun '08

Andrew Findlay wrote: > I was referring to documentation, where the only bit of the admin > guide that really talks about proxy authorisation is the SASL section. Ah, OK. Note that since some point in 2.3, authorization is described by a specific syntax <http://www.openldap.org/faq/data/cache/1254.html>, which should probably be advertised a bit more (and moved out from the experimental OID arc). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 16 Jun '08

16 Jun '08

On Mon, Jun 16, 2008 at 07:29:12PM +0200, Pierangelo Masarati wrote: > Not sure what you mean there, but I believe the fact that the > implementation is in saslauth.c is for mere historical reasons. Right > now, authorization code is independent from SASL, and is used by a > number of features: SASL authz, RFC 4370, identity assertion, dgIdentity > and more. I was referring to documentation, where the only bit of the admin guide that really talks about proxy authorisation is the SASL section. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by ando＠sys-net.it 16 Jun '08

16 Jun '08

andrew.findlay(a)skills-1st.co.uk wrote: > It might be better still to factor out the concept of proxy > authorisation and its control from the SASL authz mechanism, as it > applies also to the LDAP Proxied Authorization Control. > I have not done this as I was unsure where best to put it. Not sure what you mean there, but I believe the fact that the implementation is in saslauth.c is for mere historical reasons. Right now, authorization code is independent from SASL, and is used by a number of features: SASL authz, RFC 4370, identity assertion, dgIdentity and more. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 16 Jun '08

16 Jun '08

On Mon, Jun 16, 2008 at 02:29:21PM +0000, Andrew Findlay wrote: > Thus I think my original report was wrong. This is a documentation > issue, not a bug. I have uploaded a suggested set of patches to make the behaviour clearer: ftp://ftp.openldap.com/incoming/andrew.findlay-20080616.patch The patch is against 2.4.10 It might be better still to factor out the concept of proxy authorisation and its control from the SASL authz mechanism, as it applies also to the LDAP Proxied Authorization Control. I have not done this as I was unsure where best to put it. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5561) SEGV using TLS/SASL
by lea.anthony＠meirion-dwyfor.ac.uk 16 Jun '08

16 Jun '08

------------------- slapd.conf --------------------------- include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/misc.schema password-hash {md5} pidfile /var/run/slapd.pid argsfile /var/run/slapd.args TLSCertificateFile /etc/openldap/certs/cert.pem TLSCertificateKeyFile /etc/openldap/certs/key.pem TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 loglevel -1 database bdb suffix "dc=meirion-dwyfor,dc=ac,dc=uk" rootdn "cn=Manager,dc=meirion-dwyfor,dc=ac,dc=uk" directory /var/lib/openldap/openldap-data index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUID eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub ------------------- ldap.conf ------------------------ BASE dc=meirion-dwyfor,dc=ac,dc=uk URI ldap://localhost TLS_CACERT /etc/openldap/certs/cacert.pem -------------------------------------------------------

1 0

(ITS#5564) Use largest contextCSN to determine staleness?
by rein＠OpenLDAP.org 16 Jun '08

16 Jun '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein Scenario: A syncrepl consumer replicates a backend DB where it has at least one entry that is up to date when it starts, but there are newer entries on the producer. The oldest contextCSN presented by the consumer is older than all entryCSN values in the replicated backend on the producer.. When syncprov_findcsn() is called with the FIND_CSN tag it will not find any entries whose entryCSN is <= the oldest csn presented by the consumer, and the cookie set will be determined as stale. Which again means that no present UUIDs will be sent to the consumer. The producer will, during the search that follows, skip sending entries whose entryCSN values are older or equal to a contextCSN with the same sid presented by the client. I.e the consumer will neither get these entries in a present UUID set nor as updated entries, and will therefore incorrectly remove them from its database. A fix that seems to solve this is that syncprov_findbase(FIND_CSN) should search for entries whose entryCSN value is less than the largest contextCSN presented by the client. All the test scripts succeed if I try this, but I'm not convinced that this is the correct fix. Would it not be more correct to ignore the entire CSN set presented by the consumer when it has been determined as stale? Hm, if the oldest contextCSN is from a server that is seldom updated this alternate fix could mean that a full reload would be performed every time the client starts with an outdated contextCSN set. Would the best fix be to do both, i.e search for entryCSN <= the largest csn presented by the client, and also ignore the csn set when it has been determined as stale? Rein Tollevik Basefarm AS

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 16 Jun '08

16 Jun '08

On Mon, Jun 16, 2008 at 02:45:43PM +0200, Hallvard B Furuseth wrote: > If non-anonymous access is needed, the slapd.access(5) manpage needs an > update too. (Or instead, to avoid duplicating text.) Currently it just > says: > > Auth (=x) privileges are also required on the authzTo attribute > of the authorizing identity and/or on the authzFrom attribute of > the authorized identity. > > but it doesn't mention to who needs that auth access. It is the authenticated ID that needs access in both cases. On further thought I think it is correct that the access is checked without reference to whether that ID has access to entry and parent entries, as (particularly in the case of authzFrom) the authenticated ID may not have any direct access to the entry whose ID it is about to assume. Thus, if principal A has authenticated and wishes to perform an operation using principal B's authorisation, the access required is: A needs auth access to authzTo in its own entry if that attribute is involved in giving A permission to act for B. A needs auth access to authzFrom in B's entry if that attribute is involved in giving A permission to act for B. The rules are the same whether using a SASL authorization identity or using a ProxyAuth control on an LDAP operation. Thus I think my original report was wrong. This is a documentation issue, not a bug. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5561) SEGV using TLS/SASL
by h.b.furuseth＠usit.uio.no 16 Jun '08

16 Jun '08

Please post your ldap.conf and slapd.conf, minus any passwords. > The pastebin URL contains the post SSL negotiation debug > lines from "slapd -d -1". No need to pastebin data as short as that. -- Hallvard

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by h.b.furuseth＠usit.uio.no 16 Jun '08

16 Jun '08

andrew.findlay(a)skills-1st.co.uk writes: > You are right: if I just grant 'auth' access to 'authzTo' the proxy > authorisation succeeds. The philisophy makes sense so I will try to > come up with a suitable patch to the Admin Guide describing how to use > it. At the moment the only note about this is in the ACL Examples > (7.2.5 at present) which says that authentication/authorization > is always done anonymously - obviously not entirely true. If non-anonymous access is needed, the slapd.access(5) manpage needs an update too. (Or instead, to avoid duplicating text.) Currently it just says: Auth (=x) privileges are also required on the authzTo attribute of the authorizing identity and/or on the authzFrom attribute of the authorized identity. but it doesn't mention to who needs that auth access. -- Hallvard

1 0

(ITS#5563) Seg. fault if URL used in ServerID without any listener
by rein＠OpenLDAP.org 16 Jun '08

16 Jun '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein Slapd will seg. fault if the URL form of ServerID is used without any active listeners. I stumbled upon this by adding "-d ?" to my regular command line. I.e not exactly a critical bug.. I'll commit a trivial fix shortly. Rein Tollevik Basefarm AS

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 16 Jun '08

16 Jun '08

On Sat, Jun 14, 2008 at 03:59:37PM +0200, Pierangelo Masarati wrote: > AFAIK, access to that attribute is checked using AUTH rather than read. > The idea is that ACLs should allow to fine-grain control who is > allowed to exploit the authorization feature while giving up as little > as possible (e.g. AUTH instead of READ). You are right: if I just grant 'auth' access to 'authzTo' the proxy authorisation succeeds. The philisophy makes sense so I will try to come up with a suitable patch to the Admin Guide describing how to use it. At the moment the only note about this is in the ACL Examples (7.2.5 at present) which says that authentication/authorization is always done anonymously - obviously not entirely true. I am still a bit worried about the logic of the access test, as in my enviroment I just had to grant the principal auth access to their own authzTo attribute to make proxy authorization work: the principal does not even have 'disclose' access to their own entry or the parent entry. Normally I would expect to need some level of access to everything in the DN before I could make use of an attribute in an entry. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5554) slapd.conf man page missing TLSCipherSuite
by ghenry＠suretecsystems.com 16 Jun '08

16 Jun '08

hyc(a)symas.com wrote: > ghenry(a)OpenLDAP.org wrote: >> Full_Name: Gavin Henry >> Version: HEAD >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> >> >> http://www.openldap.org/software/man.cgi?query=slapd.conf&sektion=5&apropos… >> missing TLSCipherSuite >> >> >> > No. The Admin Guide is missing the note about GnuTLS under the TLSCipherSuite > description. The note is present in slapd.conf(5). > Where would you like this to be mentioned in the Admin Guide, the only reference to TLSCipherSuite in the guide is in the TLS section, not in the config section. For now I've added: To obtain the list of ciphers in GNUtls use: > gnutls-cli -l in tls.sdf under the openssl cli part. -- Kind Regards, Gavin Henry. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP.

1 0

Re: (ITS#5562) SEGV using TLS/SASL
by lea.anthony＠meirion-dwyfor.ac.uk 16 Jun '08

16 Jun '08

Duplicate. Please close. ----- Original Message ----- From: openldap-its(a)OpenLDAP.org To: "lea anthony" <lea.anthony(a)meirion-dwyfor.ac.uk> Sent: Monday, June 16, 2008 10:00:49 AM (GMT) Europe/London Subject: Re: (ITS#5562) SEGV using TLS/SASL *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#5562. 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. 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#5562) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#5562) 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=5562 Please remember to retain your issue tracking number (ITS#5562) 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. 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. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

(ITS#5562) SEGV using TLS/SASL
by lea.anthony＠meirion-dwyfor.ac.uk 16 Jun '08

16 Jun '08

Full_Name: Lea Anthony Version: 2.3.40 OS: Arch Linux URL: http://pastebin.com/f6b680f22 Submission from: (NULL) (194.82.229.100) I have TLS setup as follows: TLSCertificateFile /etc/openldap/certs/cert.pem TLSCertificateKeyFile /etc/openldap/certs/key.pem TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 The server starts fine and doing "ldapsearch -x -ZZ" will do an anonymous bind fine. However, doing "ldapsearch -ZZ" will cause a segfault on the server. The pastebin URL contains the post SSL negotiation debug lines from "slapd -d -1".

1 0

(ITS#5561) SEGV using TLS/SASL
by lea.anthony＠meirion-dwyfor.ac.uk 16 Jun '08

16 Jun '08

Full_Name: Lea Anthony Version: 2.3.40 OS: Arch Linux URL: http://pastebin.com/f6b680f22 Submission from: (NULL) (194.82.229.100) I have TLS setup as follows: TLSCertificateFile /etc/openldap/certs/cert.pem TLSCertificateKeyFile /etc/openldap/certs/key.pem TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 The server starts fine and doing "ldapsearch -x -ZZ" will do an anonymous bind fine. However, doing "ldapsearch -ZZ" will cause a segfault on the server. The pastebin URL contains the post SSL negotiation debug lines from "slapd -d -1".

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs