- openldap-bugs - openldap.org

(ITS#8613) slapo-memberOf documentation update (Unsafe to use with replication)
by quanah＠openldap.org 09 Mar '17

09 Mar '17

Full_Name: Quanah Gibson-Mount Version: 2.3 and higher OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) The slapo-memberOf overlay is not safe to use in a replicated environment due to the way in which replication occurs. In particular, slapo-memberOf works fine as long as all user objects are created before any group objects. As soon as there are user objects that are members of a group where the user object was created after the group, breakage will occur if any consumer falls back into REFRESH mode. This is particularly trivial to reproduce by simply setting up a new empty consumer and allowing it to populate via REFRESH. This limitation should be clearly noted in the man page and the admin guide documentation. It is possible to set up slapo-dynlist to operate as a replacement for slapo-memberOf, and it is safe in a replicated environment. The tricky part of using slapo-dynlist is that membership information must be maintained by updating user objects rather than by updating group objects, which may be difficult for end users depending on how they perform group management. Example configuration: .... include "/opt/symas/etc/openldap/schema/memberof.schema" include "/opt/symas/etc/openldap/schema/dyngroup.schema" .... moduleload dynlist.la .... database mdb .... index memberOf ... overlay dynlist dynlist-attrset groupOfUrls memberURL member Then in the database: dn: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com objectClass: memberOfOC memberOf: cn=testgroup,ou=Group,dc=example,dc=com root@u16test:/opt/symas/etc/openldap# /opt/symas/bin/ldapsearch -x -LLL -H ldap:/// -D dc=example,dc=com -w secret -b dc=example,dc=com cn=testgroup dn: cn=testgroup,ou=Group,dc=example,dc=com objectClass: groupOfURLs cn: testgroup memberURL: ldap:///dc=example,dc=com??sub?(memberOf=cn=testgroup,ou=Group,dc=e xample,dc=com) member: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com The memberOf schema I came up with on the fly. It would need a different OID for the objectClass, and possibly a different objectClass name, as I stole those from ppolicy for testing purposes: attributetype ( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that the entry belongs to' EQUALITY distinguishedNameMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' ) objectclass ( 1.3.6.1.4.1.42.2.27.8.2.1 NAME 'memberOfOC' SUP top AUXILIARY MUST ( memberOf ) )

1 0

(ITS#8612) lmdb build fails on illumos / solaris
by lorban＠bitronix.be 06 Mar '17

06 Mar '17

Full_Name: Ludovic Orban Version: OS: OmniOS r151020 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a02:a03f:1cdc:c300:384b:af79:f57c:b134) Building lmdb on illumos fails with the following error: mdb.c: In function 'mdb_env_copythr': mdb.c:9036:6: error: too many arguments to function 'sigwait' sigwait(&set, &tmp); ^ In file included from mdb.c:132:0: /usr/include/signal.h:165:12: note: declared here extern int sigwait(sigset_t *); ^ This happens because to use sigwait on illumos, you have to add the -D_POSIX_PTHREAD_SEMANTICS switch to the compiler. Changing the Makefile THREADS line to add the switch solves the problem: THREADS = -pthread -D_POSIX_PTHREAD_SEMANTICS FYI, I haven't tested on sun/oracle solaris but I guess it suffers from the exact same problem.

1 0

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

06 Mar '17

--On Monday, March 06, 2017 5:24 PM +0000 mberg(a)synacor.com wrote: > Reading back over the report on ITS-8281, the reported behavior would > have been a collision of generating a new contextCSN as well as > duplicating the producer's SID. So it's generated contextCSN would > have masked the one it never committed from the original master. I'm not sure what you mean by duplicating the producer's SID. Both nodes had unique SID values. There were no duplicated SIDs. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8611) Option to block SSL renegotation after X attempts
by quanah＠openldap.org 06 Mar '17

06 Mar '17

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) Using SSL renegotiation is a common form of DoS attack against services. It should be possible to configure the max # of times a client can request the server renegotiate the SSL layer before being dropped. Alternatively, an option to completely disable SSL renegotiation in the slapd configuration may also be desirable.

1 0

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

06 Mar '17

Reading back over the report on ITS-8281, the reported behavior would have been a collision of generating a new contextCSN as well as duplicating the producer's SID. So it's generated contextCSN would have masked the one it never committed from the original master. However, the point still stands that the contextCSN entry is *not* being written to the access log by the first server (A) here. It is only being written by the second server (B). So in the scenario that is supposed to be addressed by the fix - a second MMR node with an uninitialized database is in its initial refresh, it wouldn't be receiving contextCSN updates through the access log because they simply aren't there. To me the logical behaviour would be that a new node would remain without a recorded contextCSN until it receives the sync cookie along with the refreshDone message. Sending an explicit contextCSN update after every single accesslog entry seems an awfully expensive and unintuitive approach to fixing a refresh issue. TL;DR: The objection raised in scenario #3 stands if you are initializing a new MMR node, since. Or in a single master + replica scenario. Or to rephrase, if these entries are intended and necessary, shouldn't they be generated on the original server as well? 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#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 05 Mar '17

05 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 04 Mar '17

04 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 03 Mar '17

03 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

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

02 Mar '17

Full_Name: Matthew Berg Version: 2.4.43+ OS: CentOS 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.97.88.240) While debugging replication issues in a Zimbra installation, I discovered a significant number of accesslog entries with an empty reqDN and specifying values for contextCSN; e.g. dn: reqStart=20170302180943.186147Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20170302180943.186147Z reqEnd: 20170302180943.190880Z reqType: modify reqSession: 100 reqAuthzID: cn=config reqDN: reqResult: 0 reqMod: contextCSN:= 20170227211132.933390Z#000000#000#000000 reqMod: contextCSN:= 20170302180943.182601Z#000000#001#000000 reqMod: contextCSN:= 20170302175436.282737Z#000000#002#000000 entryUUID: 27b9f34c-93bf-1036-9636-3fa0e78444ec creatorsName: cn=config createTimestamp: 20170302180943Z entryCSN: 20170302180943.182601Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20170302180943Z I was able to reproduce this behavior in a test lab with two freshly installed servers and no existing data. Given two servers, A and B, a write to A will result in the expected audit object being written to the access log on A, but when B applies the change it logs an additional auditModify (likewise B will cause the same additional entry on A). This particular environment was running a patched build of 2.4.44. I audited our other production environments and did not see the same behavior with prior builds (primarily 2.4.39). 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.

1 0

(ITS#8606) Document the keepalive parameter in the admin guide
by quanah＠openldap.org 02 Mar '17

02 Mar '17

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) The keepalive parameter to syncrepl was added after the current replication documents were written, and needs to be added to the admin guide.

1 0

Re: (ITS#8586) load cert+chain from TLSCertificateFile
by quanah＠symas.com 01 Mar '17

01 Mar '17

--On Tuesday, February 14, 2017 3:16 AM +0000 ryan(a)nardis.ca wrote: > I found that useful in a setup very similar to what Andreas and Michael > describe: slapd with a server certificate issued by an external/public > CA, but trusting only a specific internal CA to authenticate clients. I found this to be a very common scenario while working for Zimbra. Many of the clients had a commercial sever cert but used their own CA for internal client cert auth. It would be extremely helpful for OpenLDAP to better support these types of configurations. --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#8605) spelling
by quanah＠symas.com 28 Feb '17

28 Feb '17

--On Sunday, February 26, 2017 8:20 AM +0000 jsoref(a)gmail.com wrote: > Full_Name: Josh Soref > Version: master > OS: > URL: > https://github.com/openldap/openldap/compare/master...jsoref:spelling?exp > and=1 Submission from: (NULL) (135.23.187.91) > > > This is a proposal of 144 changes. They should each be individually > applicable (although some may require earlier changes if they happen to > touch similar lines). > > Please don't expect me to submit 144 individual change requests, that > isn't reasonable. I am generally willing to provide 3-10 submissions, > preferably on the lower side. All you have to do is specify what you want > in them. Hi Josh, These look good, and I think it can be done as a single git-format-patch submission uploaded to the FTP server. Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8605) spelling
by jsoref＠gmail.com 26 Feb '17

26 Feb '17

Full_Name: Josh Soref Version: master OS: URL: https://github.com/openldap/openldap/compare/master...jsoref:spelling?expan… Submission from: (NULL) (135.23.187.91) This is a proposal of 144 changes. They should each be individually applicable (although some may require earlier changes if they happen to touch similar lines). Please don't expect me to submit 144 individual change requests, that isn't reasonable. I am generally willing to provide 3-10 submissions, preferably on the lower side. All you have to do is specify what you want in them.

1 0

(ITS#8604) back-config breaks on Solaris 8/9
by quanah＠openldap.org 24 Feb '17

24 Feb '17

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) Filing for historical purposes: The stdio library on this version of Solaris doesn't understand %z. Change the definition (slapd/config.c around line 58). In the not _WIN32 case, add #ifdef __sun #if _SIZEOF_SIZE_T_ == 4 #define Z "ll" #define LUTIL_ATOULX lutil_atoullx #else #define Z "l" #define LUTIL_ATOULX lutil_atoulx #else ... (existing defs: LUTIL_ATOULX -> lutil_atoulx, Z -> "z" #endif #endif Otherwise one will see: 54505a71 config_build_attrs: error 21 on olcDbCacheSize value #0 54505a71 config_build_entry: build "zu" failed: "" 54505a71 backend_startup_one (type=config, suffix="cn=config"): bi_db_open failed! (-1)

1 0

Re: (ITS#8590) LMDB: Suppress SIGPIPE in mdb_env_copythr on OS X
by lmb＠cloudflare.com 23 Feb '17

23 Feb '17

I should probably mention that this bug will make compacting copies lock up on OS X, since the copy thread blocks in sigwait forever if the process set SIG_IGN on SIGPIPE. Regards, Lorenz

1 0

Re: (ITS#8485) [PATCH] Adding support for encrypted server private keys
by ahnolds＠gmail.com 23 Feb '17

23 Feb '17

--001a11447608411b0a054928d3c2 Content-Type: text/plain; charset=UTF-8 I completely agree that this doesn't add any security when running slapd. However, when I originally wrote this patch, I was more targeting API usage, and in particular, client-side API usage. My goal was to allow a user to present an encrypted key (stored on disk) and a password (only held in memory), and use these to query a secure LDAP server. The issue of how the password got into memory is certainly beyond the scope of OpenLDAP in this case, but it certainly could be done securely in a way that wouldn't leave it exposed to a third-party with file-system access. For example (in the use case that motivated me originally), an sysadmin could input the password through an online form, submit said form to a Python webserver over HTTPS, the Python code could pass the password to OpenLDAP through a Python interface like python-ldap ( https://www.python-ldap.org/), and then use the LDAPS or STARTTLS connection to talk securely to some LDAP server elsewhere. All without an unencrypted keyfile or a password ever existing on disk, hence the added security. If you feel that supporting encrypted keyfiles in slapd is a bad design choice, I'm willing to rework the patch to drop that part and only keep the API-level support. Personally, I would argue that it doesn't hurt to support the feature, although perhaps my documentation changes could do a better job emphasizing the inherent security limitations. Let me know what you think (or if this discussion should take place on a list, let me know which/where). On Wed, Feb 22, 2017 at 1:11 PM, Howard Chu <hyc(a)symas.com> wrote: > ahnolds(a)gmail.com wrote: > >> Full_Name: Alec Cooper >> Version: HEAD of master branch >> OS: Ubuntu Linux 16.04 >> URL: ftp://ftp.openldap.org/incoming/Alec-Cooper-160827.patch >> Submission from: (NULL) (73.134.243.211) >> >> >> Adding support for encrypted server private keys. >> > > Thank you for your submission. I must compliment you on providing such a > comprehensive and well-written contribution. Unfortunately the feature > itself is clearly not useful. Perhaps you should have raised this topic on > the openldap-devel list for discussion before spending your time writing it. > > All your feature does is embed the encryption key in the filesystem, so an > encrypted private key is still no more secure than an unencrypted one. It > still just depends on setting proper file access permissions, and the > current documentation already makes that point. > > Indeed, all it does is give the false illusion of enhancing security, and > followups like balmerpeak92(a)gmail.com's shows that people will easily > fall for such illusions. > > I regret having to reject such a well written contribution, but we cannot > in good conscience accept a security feature that doesn't actually improve > security. > >> >> The meat of this patch is changes to tls2.c, tls_g.c, tls_m.c, and >> tls_o.c to >> send a password to the underlying TLS library. >> >> Changes to ldap.h, init.c and ldap-int.h expose the new >> LDAP_OPT_X_TLS_KEYPASSWORD in the main API. >> >> Changes in the contrib/ldapc++ directory expose the corresponding >> TlsOptions::KEYPASSWORD option in the C++ API. >> >> Changes in the servers directory expose equivalent options for servers as >> configuration file entries or environment variables. >> >> Changes in the doc directory add documentation about the new options and >> remove >> statements that indicated that encrypted keyfiles are not supported. >> >> New files in the test directory are for testing TLS connections, both in >> general >> and with encrypted keyfiles. Tests pass for OpenSSL and GnuTLS using PEM >> formatted certs and keys, and for MozNSS using cert/key databases. The >> new unit >> test (test065-tls) has been written to detect when using NSS, and use the >> cert/key databases in this case. I have been unable to get a working >> version of >> libnsspem, so I cannot test MozNSS with (or without) encrypted keyfiles - >> testing for this case would be welcome! >> >> Notice of origin: The attached patch file is derived from OpenLDAP >> Software. All >> of the modifications to OpenLDAP Software represented in the following >> patch >> were developed by Alec Cooper ahnolds(a)gmail.com. I have not assigned >> rights >> and/or interest in this work to any party. >> Rights statement: I, Alec Cooper, hereby place the following >> modifications to >> OpenLDAP Software (and only these modifications) into the public domain. >> Hence, >> these modifications may be freely used and/or redistributed for any >> purpose with >> or without attribution and/or other notice. >> >> The patch has been uploaded to the OpenLDAP FTP server and can be found at >> ftp://ftp.openldap.org/incoming/Alec-Cooper-160827.patch >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --001a11447608411b0a054928d3c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I completely agree that this doesn't add any security = when running slapd. However, when I originally wrote this patch, I was more= targeting API usage, and in particular, client-side API usage. My goal was= to allow a user to present an encrypted key (stored on disk) and a passwor= d (only held in memory), and use these to query a secure LDAP server. The i= ssue of how the password got into memory is certainly beyond the scope of O= penLDAP in this case, but it certainly could be done securely in a way that= wouldn't leave it exposed to a third-party with file-system access.<di= v> </div><div>For example (in the use case that motivated me originally)= , an sysadmin could input the password through an online form, submit said = form to a Python webserver over HTTPS, the Python code could pass the passw= ord to OpenLDAP through a Python interface like python-ldap (<a href=3D"htt= ps://www.python-ldap.org/">https://www.python-ldap.org/</a>), and then use = the LDAPS or STARTTLS connection to talk securely to some LDAP server elsew= here. All without an unencrypted keyfile or a password ever existing on dis= k, hence the added security.<div> </div><div>If you feel that supporting= encrypted keyfiles in slapd is a bad design choice, I'm willing to rew= ork the patch to drop that part and only keep the API-level support. Person= ally, I would argue that it doesn't hurt to support the feature, althou= gh perhaps my documentation changes could do a better job emphasizing the i= nherent security limitations. Let me know what you think (or if this discus= sion should take place on a list, let me know which/where).=C2=A0</div></di= v><div> </div></div><div class=3D"gmail_extra"> <div class=3D"gmail_q= uote">On Wed, Feb 22, 2017 at 1:11 PM, Howard Chu <<a = href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>></span= > wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:ahnolds@gmail.= com" target=3D"_blank">ahnolds(a)gmail.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Alec Cooper Version: HEAD of master branch OS: Ubuntu Linux 16.04 URL: <a href=3D"ftp://ftp.openldap.org/incoming/Alec-Cooper-160827.patch" r= el=3D"noreferrer" target=3D"_blank">ftp://ftp.openldap.org/incoming/Al= ec-Cooper-160827.patch</a> Submission from: (NULL) (73.134.243.211) Adding support for encrypted server private keys. </blockquote> Thank you for your submission. I must compliment you on providing such a co= mprehensive and well-written contribution. Unfortunately the feature itself= is clearly not useful. Perhaps you should have raised this topic on the op= enldap-devel list for discussion before spending your time writing it. All your feature does is embed the encryption key in the filesystem, so an = encrypted private key is still no more secure than an unencrypted one. It s= till just depends on setting proper file access permissions, and the curren= t documentation already makes that point. Indeed, all it does is give the false illusion of enhancing security, and f= ollowups like <a href=3D"mailto:balmerpeak92@gmail.com" target=3D"_blank">b= almerpeak92(a)gmail.com</a>'s shows that people will easily fall for such= illusions. I regret having to reject such a well written contribution, but we cannot i= n good conscience accept a security feature that doesn't actually impro= ve security. <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> The meat of this patch is changes to tls2.c, tls_g.c, tls_m.c, and tls_o.c = to send a password to the underlying TLS library. Changes to ldap.h, init.c and ldap-int.h expose the new LDAP_OPT_X_TLS_KEYPASSWORD in the main API. Changes in the contrib/ldapc++ directory expose the corresponding TlsOptions::KEYPASSWORD option in the C++ API. Changes in the servers directory expose equivalent options for servers as<b= r> configuration file entries or environment variables. Changes in the doc directory add documentation about the new options and re= move statements that indicated that encrypted keyfiles are not supported. New files in the test directory are for testing TLS connections, both in ge= neral and with encrypted keyfiles. Tests pass for OpenSSL and GnuTLS using PEM<br= > formatted certs and keys, and for MozNSS using cert/key databases. The new = unit test (test065-tls) has been written to detect when using NSS, and use the<b= r> cert/key databases in this case. I have been unable to get a working versio= n of libnsspem, so I cannot test MozNSS with (or without) encrypted keyfiles -<b= r> testing for this case would be welcome! Notice of origin: The attached patch file is derived from OpenLDAP Software= . All of the modifications to OpenLDAP Software represented in the following patc= h were developed by Alec Cooper <a href=3D"mailto:ahnolds@gmail.com" target= =3D"_blank">ahnolds(a)gmail.com</a>. I have not assigned rights and/or interest in this work to any party. Rights statement: I, Alec Cooper, hereby place the following modifications = to OpenLDAP Software (and only these modifications) into the public domain. He= nce, these modifications may be freely used and/or redistributed for any purpose= with or without attribution and/or other notice. The patch has been uploaded to the OpenLDAP FTP server and can be found at<= br> <a href=3D"ftp://ftp.openldap.org/incoming/Alec-Cooper-160827.patch" rel=3D= "noreferrer" target=3D"_blank">ftp://ftp.openldap.org/incoming/Alec-Co= oper-160827.patch</a> </blockquote> -- =C2=A0 -- Howard Chu =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas= .com</a> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= yc/</a> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= ct/</a> </blockquote></div> </div> --001a11447608411b0a054928d3c2--

1 0

Re: (ITS#8574) bconfig support for DNs that need escaping
by okuznik＠symas.com 22 Feb '17

22 Feb '17

On Wed, Feb 22, 2017 at 06:34:18PM +0000, Ond=C5=99ej Kuzn=C3=ADk wrote: > On Wed, Feb 22, 2017 at 05:42:39PM +0000, Howard Chu wrote: >> okuznik(a)symas.com wrote: >>> When an rdn under cn=3Dconfig needs escaping, incorrect value gets pa= ssed to the >>> attribute and, if the attribute is single-value, the entry is rejecte= d by >>> entry_naming_check(). >>>=20 >>> Patch against master is attached. >>=20 >> Why are you running the normalizer in a for-loop: >>=20 >> + for ( cnt =3D 0; rDN[cnt]; cnt++ ) { >>=20 >> but always setting value #0? >>=20 >> + free( a->a_vals[0].bv_val ); >> + ber_dupbv( &a->a_vals[0], &ava->la_value ); >>=20 >> If the RDN is actually a compound with multiple AVAs you need to conca= tenate >> them into a single value. Otherwise, if you don't intend to support co= mpound >> RDNs, there's no point in using a for-loop. Just return an error if th= ere's >> more than one AVA. >=20 > While X-ORDERED 'SIBLINGS' are required to the single-valued in the > draft and back-config doesn't actually use multi-valued rDNs, it might > break if the latter ever changes. An updated fix is here: >=20 > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170222-Deal-with-rDN-co= rrectly.patch >=20 > This will still pick the value if the rDN is multi-valued, this time > regardless of the attribute's position in the rDN. As pointed out by Howard, the patch was not against master (although my git doesn't complain anyway). The following patch is and also tests that the attribute we were asked to update is actually present in the rDN provided: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170222b-Deal-with-rDN-cor= rectly.patch

1 0

Re: (ITS#8574) bconfig support for DNs that need escaping
by okuznik＠symas.com 22 Feb '17

22 Feb '17

On Wed, Feb 22, 2017 at 05:42:39PM +0000, Howard Chu wrote: > okuznik(a)symas.com wrote: >> When an rdn under cn=config needs escaping, incorrect value gets passed to the >> attribute and, if the attribute is single-value, the entry is rejected by >> entry_naming_check(). >> >> Patch against master is attached. > > Why are you running the normalizer in a for-loop: > > + for ( cnt = 0; rDN[cnt]; cnt++ ) { > > but always setting value #0? > > + free( a->a_vals[0].bv_val ); > + ber_dupbv( &a->a_vals[0], &ava->la_value ); > > If the RDN is actually a compound with multiple AVAs you need to concatenate > them into a single value. Otherwise, if you don't intend to support compound > RDNs, there's no point in using a for-loop. Just return an error if there's > more than one AVA. While X-ORDERED 'SIBLINGS' are required to the single-valued in the draft and back-config doesn't actually use multi-valued rDNs, it might break if the latter ever changes. An updated fix is here: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170222-Deal-with-rDN-correc… This will still pick the value if the rDN is multi-valued, this time regardless of the attribute's position in the rDN. Ondrej

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs