openldap-bugs March 2017

openldap-bugs@openldap.org

31 participants
112 discussions

(ITS#8610) ldaps not usable with DNS SRV
by Silvio.Wanka＠fiege.com 06 Mar '17

06 Mar '17

Full_Name: Silvio Wanka Version: openldap-client-2.4.44 OS: FreeBSD 10.3-RELEASE-p16 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.138.118.158) Hi, if I use "ldap:///dc%3Dexample%2Cdc%3Dorg" on a test system all works properly but I must use LDAPS on a DMZ system and so I try "ldaps:///dc%3Dexample%2Cdc%3Dorg" but this search for a ldap DNS SRV record which of course returns the normal ldap port not the ldaps port. This can't work, because a firewall is between. Is this normal (by design) or an bug? There is also an old discussion on your site: http://www.openldap.org/lists/openldap-technical/201203/msg00027.html. IMO should OpenSSL either support DNS SRV lookup for each scheme or for none. TIA, Silvio

1 0

(ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 04 Mar '17

04 Mar '17

Full_Name: Paul B. Henson Version: 2.4.44 + ITS 8432 patch OS: Linux (Gentoo) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (96.251.22.157) As discussed in: https://www.openldap.org/lists/openldap-technical/201702/msg00077.html I'm getting random segfaults with openldap 2.4.44 (with the ITS 8432 patch applied) with the following backtrace: (gdb) bt full #0 0x0000000000485c61 in modify_add_values (e=e@entry=0x7f50727fb480, mod=mod@entry=0x7f50600019a0, permissive=0, text=text@entry=0x7f50727fb9a0, textbuf=textbuf@entry=0x7f50727fb4d0 "modify/delete: eduPersonAffiliation: n o such attribute", textlen=textlen@entry=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/mods.c:61 rc = <optimized out> op = 0x4fe045 "add" a = <optimized out> pmod = {sm_desc = <optimized out>, sm_values = 0x0, sm_nvalues = 0x0, sm _numvals = <optimized out>, sm_op = <optimized out>, sm_flags = <optimized out>, sm_type = {bv_len = <optimized out>, bv_val = <optimized out>}} __PRETTY_FUNCTION__ = "modify_add_values" #1 0x00007f526dfccd0c in mdb_modify_internal (op=op@entry=0x7f50727fc600, tid=tid@entry=0x1088a90, modlist=0x7f5060001960, e=e@entry=0x7f50727fb480, text=text@entry=0x7f50727f b9a0, textbuf=textbuf@entry=0x7f50727fb4d0 "modify/delete: eduPersonAffiliation: n o such attribute", textlen=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/back-mdb/mod ify.c:137 rc = <optimized out> err = <optimized out> mod = 0x7f50600019a0 ml = 0x7f50600019a0 save_attrs = 0x7f5060004270 ap = 0x7f5272f53010 glue_attr_delete = <optimized out> got_delete = 0 __PRETTY_FUNCTION__ = "mdb_modify_internal" #2 0x00007f526dfce134 in mdb_modify (op=0x7f50727fc600, rs=0x7f50727fb980) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/back-mdb/mod ify.c:624 mdb = 0x7f5272f53010 e = 0x7f5060004220 manageDSAit = <optimized out> textbuf = "modify/delete: eduPersonAffiliation: no such attribute\000\37 7\037\000\000\000\000\000\000\000@\003\315\000\000\000\000\000\200\271\177rP\177 \000\000\021\000\000\000\000\000\000\000.,\020`P\177\000\000 \360o\315\000\000\000\000\000\360\002\315\000\000\000\000\000\037\000\000\000\00 0\000\000\000\000\306\177rP\17 7\000\000\300\064\000`P\177\000\000\000\000\000\000\000\000\000\000\360o\315\000 \000\000\000\000 T\315\000\000 \000\000\000\000\306\177rP\177\000\000\270\232N\000\000\000\000\000 l\315\000\000\000\000\000\350\064\000`P\17 7\000\000\000\306\177rP\177\000\000\000\000\000\000\000\000\000\000"... txn = 0x1088a90 opinfo = {moi_oe = {oe_next = {sle_next = 0x7f50727fb930}, oe_key = 0x7f 5272f53010}, moi_txn = 0x1088a90, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7f50727fb430 dummy = {e_id = 66196, e_name = {bv_len = 40, bv_val = 0x7f50600041e8 "uid=aapriest,ou=user,dc=csupomona,dc=edu"}, e_nname = {bv_len = 40, bv_val = 0x7f5060004d18 "uid=aapriest,ou=user,dc=csupomona,dc=edu"}, e_attrs = 0xd202e8, e_ocflags = 256, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x7f50 60004220} preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x0, 0x0, 0x0, 0x0, 0x7f50727fb250} num_ctrls = 0 numads = 55 #3 0x000000000049c2ea in overlay_op_walk (op=op@entry=0x7f50727fc600, rs=0x7f50727fb980, which=op_modify, oi=0xcd6a40, on=<optimized out>) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/backover.c:6 77 func = <optimized out> rc = <optimized out> #4 0x000000000049c441 in over_op_func (op=0x7f50727fc600, rs=<optimized out>, which=<optimized out>) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/backover.c:7 30 oi = <optimized out> on = <optimized out> be = 0xcd0ac0 db = {bd_info = 0x7f526e1e6d40 <bi>, bd_self = 0xcd0ac0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\0 01\000\000\001", '\000' <repea ts 14 times>, "\001", be_flags = 563464, 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, ss s_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 64}, be_s uffix = 0xcd0880, be_nsuffix = 0xca5c90, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_sc hemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 31, bv_val = 0xcd02f0 "cn=ldapr oot,dc=csupomona,dc=edu"}, be_rootndn = {bv_len = 31, bv_val = 0xcd0340 "cn=ldaproot,dc=csupomona ,dc=edu"}, be_rootpw = { bv_len = 38, bv_val = 0xca49a0 "{SSHA}XXXXXXXXXXXXXXXXXXXXXXX"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0xca5840, be_acl = 0xcd1c80, be_dfltaccess = ACL_READ, be_ extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_p ending_csn_list = 0xf85dc0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nuse rs = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}} , __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0xcd 75c0, be_pb = 0x0, be_cf_ocs = 0x7f526e1e68c0 <mdbocs>, be_private = 0x7f5272f53010, be_n ext = {stqe_next = 0x0}} cb = {sc_next = 0x7f50727fb950, sc_response = 0x49b650 <over_back_respon se>, sc_cleanup = 0x0, sc_writewait = 0x0, sc_private = 0xcd6a40} sc = <optimized out> rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #5 0x000000000048d938 in syncrepl_message_to_op (si=si@entry=0xcd8520, op=op@entry=0x7f50727fc600, msg=0x7f5060102940) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/syncrepl.c:2 394 oes = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x48cd60 <syncrepl_mes sage_to_op>}, oe_si = 0xcd8520} ber = 0x7f50604b5390 modlist = 0x7f5060496f60 ls = 0x778940 <accesslog_sc> rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_mat ched = 0x0, sr_text = 0x7f50727fb4d0 "modify/delete: eduPersonAffiliation: no such attribute", sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0 , r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasld ata = 0x0}, sru_extended = { r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} cb = {sc_next = 0x7f5060003490, sc_response = 0x48c8d0 <null_callback>, sc_cleanup = 0x0, sc_writewait = 0x0, sc_private = 0x0} text = 0x0 txtbuf = "@\277\177rP\177\000\000\020\274\177rP\177\000\000X\371P\000\00 0\000\000\000\266P\246rR\177\0 00\000@\277\177rP\177\000\000X\371P\000\000\000\000\000\240\272\177rP\177\000\00 0\060\275\246rR\177\000\000X\3 71P\000\000\000\000\000@^\246rR\177\000\000\000\000\000\000\000\000\000\000\002\ 000\000\000P\177\000\000\020\0 00\000\000\000\000\000\000\260\272\177rP\177\000\000\377\377\377\377\377\377\377 \377&\000\000\017\000\000\000\ 000\020\t\020\230P\177\000\000x\215I`P\177\000\000\177\215I`P\177\000\000\000\27 5\177rP\177\000\000p\234\305\0 00\000\000\000\000@\275\177rP\177\000\000 \205\315\000\000\000\000\000\313\343I\000\000\000\000\000\020", '\00 0' <repeats 23 times>... bdn = {bv_len = 40, bv_val = 0x7f50600013ac "uid=aapriest,ou=user,dc=csu pomona,dc=edu"} dn = {bv_len = 40, bv_val = 0x7f5060001c48 "\360!"} ndn = {bv_len = 40, bv_val = 0x7f5060001cd8 "\340\034"} bv = {bv_len = 0, bv_val = 0x0} bv2 = {bv_len = 0, bv_val = 0x0} bvals = 0x7f506049fb80 rdn = {bv_len = 0, bv_val = 0x0} sup = {bv_len = 0, bv_val = 0x0} prdn = {bv_len = 0, bv_val = 0x0} nrdn = {bv_len = 0, bv_val = 0x0} psup = {bv_len = 0, bv_val = 0x0} nsup = {bv_len = 0, bv_val = 0x0} rc = 0 deleteOldRdn = 0 freeReqDn = 1 do_graduate = 1 #6 0x00000000004915d7 in do_syncrep2 (op=op@entry=0x7f50727fc600, si=si@entry=0xcd8520) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/syncrepl.c:1 013 match = <optimized out> syncUUID = {{bv_len = 16, bv_val = 0x7f506049fb47 "~\373\337l\214\335IȻ\346\230\350\r\n", <inc omplete sequence \316>}, { bv_len = 0, bv_val = 0x0}} cookie = {bv_len = 15, bv_val = 0x7f506049fb59 "rid=003,sid=003"} rctrls = 0x7f506049abe0 rctrlp = <optimized out> bdn = {bv_len = 44, bv_val = 0x7f506000135a "reqStart=20161225113103.000 003Z,cn=accesslog"} si_tag = <optimized out> entry = <optimized out> punlock = -1 syncstate = 1 retdata = 0x0 retoid = 0x78 <error: Cannot access memory at address 0x78> syncUUIDs = 0x0 len = 15 berbuf = { buffer = "\002\000\001", '\000' <repeats 29 times>, "@\373I`P\177\000\ 000h\373I`P\177\000\000h\373I` P\177", '\000' <repeats 26 times>, "п\177rP\177\000\000\000\000\000\000R\177\000\000\001\000\000\000\000\000\0 00\000dZ\023qR\177\000\000Dh,\200\207\001\305\345\000\000\000\000\001\000\000\00 0\200\255J`P\177\000\000`\305\ 177rP\177\000\000\257X\244qR\177\000\000\031p-rR\177\000\000\000\000\000\000\000 \000\000\000\b\246\246rR\177\0 00\000\060", '\000' <repeats 15 times>, "\001\000\000\000\000\000\000\000d"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e- 319, palign = 0x10002 <error: Cannot access memory at address 0x10002>} ber = 0x7f50727fbf40 msg = 0x7f5060102940 syncCookie = {ctxcsn = 0x0, sids = 0x0, numcsns = 0, rid = 3, octet_str = {bv_len = 15, bv_val = 0x7f5060498d70 "rid=003,sid=003"}, sid = 3, sc_next = {stqe _next = 0x0}} syncCookie_req = {ctxcsn = 0x7f50604a6c10, sids = 0x7f50604996c0, numcsn s = 4, rid = 3, octet_str = { bv_len = 183, bv_val = 0x7f50604984e0 "rid=003,sid=000,csn=20161225102351.582901Z# 000000#000#000000;201612130230 51.387118Z#000000#001#000000;20160721062752.989665Z#000000#002#000000;2016072106 2824.859874Z#000000#003#000000 "}, sid = 0, sc_next = {stqe_next = 0x0}} rc = 0 err = 0 modlist = 0x0 m = 11 tout_p = 0x7f50727fbc00 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 empty = "empty" #7 0x0000000000495793 in do_syncrepl (ctx=ctx@entry=0x7f50727fcb90, arg=arg@entry=0xcd8a00) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/syncrepl.c:1 564 rtask = 0xcd8a00 si = 0xcd8520 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INV ALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __cou nt = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__ prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_star ttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = { bv_len = 0, bv_val = 0x503e42 ""}, c_peer_name = {bv_len = 0, bv_val = 0x503e42 ""}, c_listener = 0x506e00 <dummy_list>, c_sasl_bind_mech = {bv_len = 0, bv _val = 0x0}, c_sasl_dn = { bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0 x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = { bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, s ai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protoco l = 0, c_ops = { stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x 0, stqh_last = 0x0}, c_write1_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nu sers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}} , __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__d ata = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, _ _mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nu sers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}} , __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__d ata = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, _ _mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_i n_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_udp = 0 '\000', c_is_tls = 0 '\000', c_ needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0 , c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x 0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n _get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0x0, c_clientarg = 0 x0, c_send_ldap_result = 0x442d90 <slap_send_ldap_result>, c_send_search_entry = 0x4437d0 <slap_send_search_entry>, c_send_search_reference = 0x444d10 <slap_send_search_reference>, c_send_ldap_extended = 0x4434a0 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x443640 <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7f50727fc770, o_tag = 102, o_time = 14826654 63, o_tincr = 13, o_bd = 0x7f50727fb690, o_req_dn = {bv_len = 40, bv_val = 0x7f506049f2c0 "uid=aapriest,ou=user,dc=csupomona,dc=edu" }, o_req_ndn = {bv_len = 40, bv_val = 0x7f506049f300 "uid=aapriest,ou=user,dc=csupomona,dc=edu" }, o_request = {oq_add = { rs_modlist = 0x7f5060001960, rs_e = 0x1}, oq_bind = {rb_method = 1610619232, rb_cred = { bv_len = 1, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0} , rb_ssf = 0, rb_mech = { bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x7f5060001 960}, oq_modify = { rs_mods = {rs_modlist = 0x7f5060001960, rs_no_opattrs = 1 '\001' }, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x7f5060001960, rs_no_opattrs = 1 '\001'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_ nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 1610619232, rs_deref = 32592, rs_slimit = 1, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_ val = 0x0}}, oq_abandon = { rs_msgid = 1610619232}, oq_cancel = {rs_msgid = 1610619232}, oq_ extended = {rs_reqoid = { bv_len = 139983184730464, bv_val = 0x1 <error: Cannot access m emory at address 0x1>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs _reqoid = { bv_len = 139983184730464, bv_val = 0x1 <error: Cannot access memory at address 0x1>}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = { bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000 ', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 1 '\001', o_no_ subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 14 times>, "\002", '\000' <repeats 16 t imes>, o_controls = 0x7f50727fc8c0, o_authz = {sai_method = 0, sai_mech = { bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 31, bv_val = 0xcd02f0 "cn=ldaproot,dc=csupomona ,dc=edu"}, sai_ndn = { sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x7f5060004198, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x7f5060102c10 "20161225113103.634923Z#000000#000#000000" }, o_private = 0x0, o_extra = {slh_first = 0x7f50727fb430}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 3, oh_conn = 0x7f50727fc340, oh_msgid = 0, oh_protocol = 0, oh_tid = 139983495091968, oh_threadctx = 0x7f50727fcb90, oh_tmpmemct x = 0x7 oh_tmpmfuncs = 0x7787a0 <slap_sl_mfuncs>, oh_counters = 0x7ae000 <sl ap_counters>, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>, oh_exten sions = 0x0}, ob_controls = { 0x0 <repeats 17 times>, 0x7f50727fbd00, 0x0 <repeats 14 times>}} op = 0x7f50727fc600 rc = 0 dostop = 0 s = 16 i = <optimized out> defer = 1 fail = 0 freeinfo = 0 be = 0xcd0ac0 #8 0x0000000000433037 in connection_read_thread (ctx=0x7f50727fcb90, argv=0x10) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/connection.c :1296 rc = <optimized out> cri = {op = 0x0, func = 0x4954b0 <do_syncrepl>, arg = 0xcd8a00, ctx = <o ptimized out>, nullop = <optimized out>} s = <optimized out> #9 0x00007f5272c83a32 in ldap_int_thread_pool_wrapper (xpool=0xc63a40) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/libraries/libldap_r/tpool. c:696 pool = 0xc63a40 task = 0x7f50a8000a20 work_list = <optimized out> ctx = {ltu_id = 139983495091968, ltu_key = {{ltk_key = 0x430810 <conn_co unter_init>, ltk_data = 0x7f5060000d20, ltk_free = 0x4308f0 <conn_counter_destr oy>}, { ltk_key = 0x486ac0 <slap_sl_mem_init>, ltk_data = 0x7f5060000e30, ltk_free = 0x486990 <slap_sl_mem_destroy>}, {ltk_key = 0x445cd0 <s lap_op_free>, ltk_data = 0x7f50a0113e10, ltk_free = 0x445c30 <slap_op_q_destroy> }, {ltk_key = 0xf85de0, ltk_data = 0x7f5060102fd0, ltk_free = 0x7f526dfda950 <mdb_reader_f ree>}, { ltk_key = 0x7f526dfd07d0 <search_stack>, ltk_data = 0x7f5070ffc010 , ltk_free = 0x7f526dfd08e0 <search_stack_free>}, {ltk_key = 0x7f526 dfd0730 <scope_chunk_get>, ltk_data = 0x7f5060104e60, ltk_free = 0x7f526dfd08b0 <scope_chunk_ free>}, {ltk_key = 0xd7f560, ltk_data = 0x7f50604ab8f0, ltk_free = 0x7f526dfda950 <mdb_reader_f ree>}, {ltk_key = 0x0, ltk_data = 0x7f506c40fff0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_da ta = 0x0, ltk_free = 0x0} <repeats 24 times>}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"

1 0

Re: (ITS#8575) Argon2 Password hashing contrib module
by quanah＠symas.com 03 Mar '17

03 Mar '17

--On Thursday, January 26, 2017 1:36 PM +0000 simon(a)slevermann.de wrote: > This patch adds a password hashing module for the argon2 function to the > contrib/slapd-modules/passwd/ modules. Argon2 is a relatively new hash > function which has won the Password Hashing Competition > (https://password-hashing.net) Discussed with Simon in IRC, he is going to look at making the modifications necessary so that this module can also use libsodium. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by quanah＠symas.com 03 Mar '17

03 Mar '17

--On Friday, March 03, 2017 9:57 PM +0000 quanah(a)symas.com wrote: > Your context for points 1-3 are invalid as the entire issue was around > N-way MMR (and their individual serverID contextCSNs) so non-master > replicas are beside the point. In addition, a correct setup via the most > recent tools would include replicas pulling from all masters, vs a single > master. So there is no replica only pulling from an "active" or > "passive" master in a correct setup. Replicas pull from *all* masters > when deployed correctly. See also > <https://bugzilla.zimbra.com/show_bug.cgi?id=95200> For background on ITS#8281, the context was: 2 (or more) MMR nodes fully populated with X number of entries. Add a new MMR node (with no database populated) While the MMR node is in REFRESH mode, stop/start slapd on that node. The interuption in the REFRESH phase results in the DB not fully replicating (Stopped at the point in which slapd was stopped). This is clearly described in the initial report, where only 625/15000 users got replicated due to stopping slapd. The discussion about what to do when there's no contextCSN generated yet on a new system, where it is single master/consumer was an orthogonal but related discussion, in relation to the value of generating a contextCSN at startup or not. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by quanah＠symas.com 03 Mar '17

03 Mar '17

--On Friday, March 03, 2017 9:36 PM +0000 mberg(a)synacor.com wrote: > I'm not precisely sure how this relates to 8281, since that seemed to > be fixed by not generating an initial contextCSN for newly initialized > databases and telling consumers to smeg off if they tried to connect > before a contextCSN was written (presumably by a successful REFRESH in > a newly initialized MMR provider, or an initial write in a single- > master provider). See <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=cd8f…>, where the code was clearly modified to push the contextCSN's through where before they were not. The entire issue around ITS#8281 was REFRESH mode in MMR failing if the server was stopped and restarted midstream while doing the refresh, with the wrong CSN value being stored. The changes in ITS#8281 ensure it maintains the correct CSN value internally. Your context for points 1-3 are invalid as the entire issue was around N-way MMR (and their individual serverID contextCSNs) so non-master replicas are beside the point. In addition, a correct setup via the most recent tools would include replicas pulling from all masters, vs a single master. So there is no replica only pulling from an "active" or "passive" master in a correct setup. Replicas pull from *all* masters when deployed correctly. See also <https://bugzilla.zimbra.com/show_bug.cgi?id=95200> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by mberg＠synacor.com 03 Mar '17

03 Mar '17

On Thu, 2017-03-02 at 16:49 -0800, Quanah Gibson-Mount wrote: > --On Thursday, March 02, 2017 10:36 PM +0000 mberg(a)synacor.com wrote: > > > I'm not sure if there is any guard against writing an older > > contextCSN > > than is currently stored, but this could theoretically rewind the > > stored contextCSN on A if there is any latency in replication from > > B. > > Older contextCSNs will be ignored. And it is accurate to then have > a contextCSN for each server in the system. That was part of the > initial problem in 8281. I still see no evidence of incorrect > behavior. ;) I'm well aware that there will be a contextCSN for each SID in the system. The questionable part was the apparent overwriting of the contextCSN on another server. I seem to be unable to reproduce that today, so I'm not sure if I fat-fingered something. However there would seem to be a couple possibilities here: 1) The contextCSN written as an accesslog entry is read by the other server and applied, which would be wrong since it should represent the most recent entryCSN seen for that SID, or 2) The contextCSN written as an accesslog entry is read by the other server and ignored, which would waste IOPS and increase latency, or 3) The contextCSN written as an accesslog entry has some non-obvious function, and replicas reading from the active master would be at a disadvantage since these entries are only being written on the passive master. I'm not precisely sure how this relates to 8281, since that seemed to be fixed by not generating an initial contextCSN for newly initialized databases and telling consumers to smeg off if they tried to connect before a contextCSN was written (presumably by a successful REFRESH in a newly initialized MMR provider, or an initial write in a single- master provider). This message and any attachment may contain information that is confidential and/or proprietary. Any use, disclosure, copying, storing, or distribution of this e-mail or any attached file by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender by reply email and delete the message and any attachments. Thank you.

1 0

(ITS#8608) Inversion in filter pcacheTemplate cannot be parsed
by danmer＠danmer.net 03 Mar '17

03 Mar '17

Full_Name: Tabolin Yuriy Version: 2.4.43 OS: FreeBSD 10.1-RELEASE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (149.126.18.58) I use openldap 2.4.43 with pcache overlay. Inversion assertions in pcacheTemplate filter cannot be parsed and slapd cannot start. For example this works fine: overlay pcache pcache mdb 100000 1 1000 60 pcacheAttrset 0 * pcacheTemplate (objectClass=) 0 3600 3600 But this not: overlay pcache pcache mdb 100000 1 1000 60 pcacheAttrset 0 * pcacheTemplate (!(objectClass=)) 0 3600 3600 There is written in man slapo-pcache "A template is defined by a filter string and an index identifying a set of attributes. The template string for a query can be obtained by removing assertion values from the RFC 4515 representation of its search filter." RFC4515 have defined exclamation mark ("!") as inversion in filter.

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by quanah＠symas.com 02 Mar '17

02 Mar '17

--On Thursday, March 02, 2017 10:36 PM +0000 mberg(a)synacor.com wrote: > I'm not sure if there is any guard against writing an older contextCSN > than is currently stored, but this could theoretically rewind the > stored contextCSN on A if there is any latency in replication from B. Older contextCSNs will be ignored. And it is accurate to then have a contextCSN for each server in the system. That was part of the initial problem in 8281. I still see no evidence of incorrect behavior. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by mberg＠synacor.com 02 Mar '17

02 Mar '17

Storing the update to the contextCSN to the root object makes sense, but propagating that update through the accesslog? Even if it were intended behavior, shouldn't the server receiving the update directly generate a similar access log entry, rather than just the server applying it from the accesslog. But practically speaking, the contextCSN on a given server should presumably reflect the most recent entryCSN that particular server has applied, and this would seem to break that. To illustrate I added a third contextCSN to my lab servers, with a stale CSN on ldap01-a: [zimbra@ldap01-a ~ldapsearch -LLL -D uid=zimbra,cn=admins,cn=zimbra -H ldapi:/// -w ******** -s base contextCSN dn: contextCSN: 20170302203943.550330Z#000000#001#000000 contextCSN: 20170302175436.282737Z#000000#002#000000 contextCSN: 20160302175436.282737Z#000000#003#000000 [zimbra@ldap01-b ~]$ ldapsearch -LLL -D uid=zimbra,cn=admins,cn=zimbra -H ldapi:/// -w ******** -s base contextCSN dn: contextCSN: 20170302203943.550330Z#000000#001#000000 contextCSN: 20170302175436.282737Z#000000#002#000000 contextCSN: 20170302175436.282737Z#000000#003#000000 Wrote a new entry on ldap01-a (which is SID 001). The change propagated to ldap01-b, wrote an auditModify to the accesslog with its new contextCSNs: dn: reqStart=20170302214742.843377Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20170302214742.843377Z reqEnd: 20170302214742.844297Z reqType: modify reqSession: 100 reqAuthzID: cn=config reqDN: reqResult: 0 reqMod: contextCSN:= 20170302214737.049475Z#000000#001#000000 reqMod: contextCSN:= 20170302175436.282737Z#000000#002#000000 reqMod: contextCSN:= 20170302175436.282737Z#000000#003#000000 reqEntryUUID: e1475404-93d7-1036-989f-315f78f5905f entryUUID: 9bceae9e-93dd-1036-8a51-85a9c542cb5f creatorsName: cn=config createTimestamp: 20170302214737Z entryCSN: 20170302214737.049475Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20170302214737Z Which was subsequently read by ldap01-a: Mar 2 16:47:42 ldap01-a slapd[9577]: syncprov_search_response: cookie=rid=100,sid=001,csn=20170302214737.049475Z#000000#001#000000 And now it has an updated contextCSN for 003 despite receiving no update for that SID: [zimbra@ldap01-a ~]$ ldapsearch -LLL -D uid=zimbra,cn=admins,cn=zimbra -H ldapi:/// -w ******** -s base contextCSN dn: contextCSN: 20170302214737.049475Z#000000#001#000000 contextCSN: 20170302175436.282737Z#000000#002#000000 contextCSN: 20170302175436.282737Z#000000#003#000000 I'm not sure if there is any guard against writing an older contextCSN than is currently stored, but this could theoretically rewind the stored contextCSN on A if there is any latency in replication from B. This message and any attachment may contain information that is confidential and/or proprietary. Any use, disclosure, copying, storing, or distribution of this e-mail or any attached file by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender by reply email and delete the message and any attachments. Thank you.

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by quanah＠symas.com 02 Mar '17

02 Mar '17

--On Thursday, March 02, 2017 6:46 PM +0000 mberg(a)synacor.com wrote: > In order to rule out the possibility that this was introduced by any > patched Zimbra applied I built out a new package from stock OpenLDAP > sources and was able to reproduce with both 2.4.44 and 2.4.43, but not > with 2.4.42 and earlier. Hi Matt, I don't see any indication of a bug here. Zimbra uses "" (empty DN) as its root, which shares other responsibilities with the overal DIT. So it's simply logging an update of the contextCSN to its root entry. This change in behavior was made to resolve the issue I reported in ITS#8281. Closing this report. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2017