openldap-bugs

openldap-bugs@openldap.org

1 participants
21002 discussions

Re: (ITS#8532) Blank subject name results in failed SSLHandshake
by quanah＠symas.com 21 Nov '16

21 Nov '16

--On Monday, November 21, 2016 8:50 PM +0000 graham.wells(a)gmail.com wrote: > Full_Name: Graham Wells > Version: 2.4.28 > OS: macOS 10.12.1 > URL: > Submission from: (NULL) (50.207.27.182) Hi Graham, Thanks for the report. However, Apple builds of OpenLDAP have hacked in support for a custom TLS library called Secure Transport. Use of this TLS library is not supported by the OpenLDAP project, thus we cannot address this problem. You will need to contact Apple for help with this problem. Hope that helps. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8532) Blank subject name results in failed SSLHandshake
by graham.wells＠gmail.com 21 Nov '16

21 Nov '16

Full_Name: Graham Wells Version: 2.4.28 OS: macOS 10.12.1 URL: Submission from: (NULL) (50.207.27.182) SSLHandshake fails for ldapsearch when the subject is blank, even if the certificate is valid and certificate chain trusted (should only require a valid SAN and for SAN to be marked as critical): Command: /usr/bin/ldapsearch -b "CN=userid,ou=foo,ou=bar,dc=domain,dc=com" -D "CN=bind-dn,ou=foo,ou=bar,dc=domain,dc=com" -H ldaps://server-ldap.com:636 -W -d-1 ldap_url_parse_ext(ldaps://server-ldap.com:636) ldap_create ldap_url_parse_ext(ldaps://server-ldap.com:636/??base) Enter LDAP Password:AlAldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP server-ldap.com:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.2.2.2:636 ldap_pvt_connect: fd: 3 tm: -1 async:%D tlsst_thr_init() tlsst_init() tlsst_ctx_new() = 0x7fa10de02f90 tlsst_ctx_init(0x7fa10de02f90) tlsst_ciphers_get((null), TLS_CIPHER_SUITE) tlsst_trusted_certs_get(CA 002|CA 001|CA 003|ROOT CA 001|Other Root CA, TLS_TRUSTED_CERTS) tlssttetem_get(CA 002, TLS_TRUSTED_CERTS) tlsst_item_get(CA 001, TLS_TRUSTED_CERTS) tlsst_item_get(CA 003, TLS_TRUSTED_CERTS) tlsst_item_get(ROOT CA 001, TLS_TRUSTED_CERTS) tlsst_item_get(Other Root CA, TLS_TRUSTED_CERTS) tlsst_session_new(0x7fa10de02f90) tlsst_ciphers_set(42, TLS_CIPHER_SUITE) TLS: 42 ciphers wanted: ...(omitted) TLS: 72 ciphers supported: ...(omitted) TLS: 16 ciphers enabled ...(omitted) tlsst_ctx_ref(0x7fa10de02f90) tlsst_session_new(0x7fa10de02f90) = 0x7fa10dd08280 tlsst_sb_setup(0x7fa10dd08280) tlsst_ctx_ref(0x7fa10de02f90) tlsst_session_connect(0x7fa10dd08280) tlsst_session_handshake() tlsst_socket_write(0x7fa10dd0ef68, 123) tls_write: want=123, written=123 0000: 16 03 01 00 76 01 00 00 72 03 03 58 33 55 fe 4e ....v...r..X3U.N 0010: 8e 16 0d df 99 3a e6 68 36 a1 ff 90 71 1f 78 bb .....:.h6...q.x. 0020: 70 bf 2a 02 05 44 c9 94 07 33 2f 00 00 22 00 ff p.*..D...3/..".. 0030: 00 9d 00 9f 00 3d 00 6b 00 35 00 39 00 9c 00 9e .....=.k.5.9.... 0040: 00 3c 00 67 00 2f 00 33 00 0a 00 16 00 05 00 04 .<.g./.3........ 0050: 01 00 00 27 00 0d 00 12 00 10 04 01 02 01 05 01 ...'............ 0060: 06 01 04 03 02 03 05 03 06 03 00 05 00 05 01 00 ................ 0070: 00 00 00 00 12 00 00 00 17 00 00 ........... tlsst_socket_read(0x7fa10e81d800, 5) tls_read: want=5, got=5 0000: 16 03 03 11 38 ....8 tlsst_socket_read(0x7fa10e81d805, 4408) tls_read: want=0808, got=2891 ...(sanitized) tlsst_socket_read - received (2891) bytes of (4408) requested bytes - (1517) encrypted bytes remaining tlsst_socket_flags sess(0x7fa10dd08280) tlsst_socket_flags ->(2) tlsst_socket_read(0x7fa10e81e350, 1517) tls_read: want=1517, got=1517 ...(sanitized) TLS: during handshake: peer cert is valid, or was ignored if verification disabled (-9841) TLS: during handshake: Peer certificate is not trusted: kSecTrustResultRecoverableTrustFailure tlsst_session_upflags(0x7fa10dd08280) tlsst_session_errmsg(0x7fa10dd08280) TLS: can't connect: SSLHandshake() failed: misc. bad certificate (-9825). tlsst_sb_remove(0x7fa10dd08280) tlsst_session_free(0x7fa10dd08280) tlsst_ctx_free(0x7fa10de02f90) ldap_err2string ldap_sasl_bind(SIMPLE): Can7t7t contact LDAP server (-1) ldap_pvt_clear_search_results_callback: ld 0x7fa10dd00ab0 ldap_pvt_close_select_pipe: sip = 0x7fa10e803800 tlsst_ctx_free(0x7fa10de02f90) tlsst_ctx_free(0x7fa10de02f90) tlsst_destroy() Certificate is otherwise valid: Certificate: Data: Version: 3 (0x2) Serial Number: (redacted) Signature Algorithm: sha256WithRSAEncryption Issuer: DC=foo, DC=bar, CN=CA 003 Validity Not Before: Oct 25 23:33:16 2016 GMT Not After : Oct 25 23:33:16 2017 GMT Subject: Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): (redacted) Exponent: 65537 (0x10001) X509v3 extensions: 1.3.6.1.4.1.311.21.7: 0-.%+.....7....`...W......./....W...b......d... X509v3 Extended Key Usage: 1.3.6.1.5.2.3.5, Microsoft Smartcardlogin, TLS Web Server Authentication, TLS Web Client Authentication X509v3 Key Usage: critical Digital Signature, Key Encipherment 1.3.6.1.4.1.311.21.10: 010...+......0.. +.....7...0 ..+.......0 ..+....... X509v3 Subject Key Identifier: E2:D2:D9:24:6D:A6:5A:2D:59:03:08:38:03:AE:E8:F4:2A:EA:EB:9F X509v3 Authority Key Identifier: keyid:16:70:AA:1C:31:53:76:FB:26:B5:B8:EA:FC:76:08:E6:3F:17:0D:2F X509v3 CRL Distribution Points: URI:http://foo.bar.com/CertData/CA 003.crl URI:ldap:///CN=CA 003,CN=server-ldap,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=domain,DC=co3F3FcertificateRevocationList?base?objectClass=cRLDistributionPoint Authority Information Access: CA Issuers - URI:http://foo.bar.com/CertData/server-ldap_CA-003.crt CA Issuers - URI:ldap:///CN=CA 003,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=domain,DC=com?cACertificate?base?objectClass=certificationAuthority X509v3 Subject Alternative Name: critical DNS:server-ldap.com, DNS:domain.com, DNS:DOMAIN Signature Algorithm: sha256WithRSAEncryption (redacted) The certificate is RFC5280 compliant despite having a blank subject name, specifically: "If the subject field contains an empty sequence, then the issuing CA MUST include a subjectAltName extension that is marked as critical." Reissuing the certificate and populating the subject field resolves the issue, but it should not be necessary according to the RFC.

1 0

(ITS#8531) Segfault in servers/slapd/back-sql/search.c
by winkelmann＠hornetsecurity.com 17 Nov '16

17 Nov '16

Full_Name: Guido Winkelmann Version: 2.4.44 OS: Gentoo Linux URL: Submission from: (NULL) (80.146.184.86) Hi, I have been trying to set up OpenLDAP to serve some data from a MySQL database using back_sql. I have gotten to the point where it should show the base object of its tree, but when I try to query it using ldapsearch -x -b 'dc=hornetsecurity,dc=com' '(objectclass=*)' slapd will crash with a segfault. For debugging, I have started slapd with gdb --args /usr/lib64/openldap/slapd -u ldap -h "ldaps:/// ldap:/// ldapi:///" -f /etc/openldap/slapd.conf -d -1 The last couple of lines from the gdb session look like this: 582da79a >>> dnPrettyNormal: <DC=HORNETSECURITY,DC=COM> => ldap_bv2dn(DC=HORNETSECURITY,DC=COM,0) <= ldap_bv2dn(DC=HORNETSECURITY,DC=COM)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=HORNETSECURITY,dc=COM)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=hornetsecurity,dc=com)=0 582da79a <<< dnPrettyNormal: <dc=HORNETSECURITY,dc=COM>, <dc=hornetsecurity,dc=com> 582da79a <==backsql_dn2id("dc=hornetsecurity,dc=com"): err=0 582da79a ==>backsql_id2entry() 582da79a backsql_id2entry(): retrvingng all attributes 582da79a ==>backsql_get_attr_vals(): oc="dcObject" attr="dc" keyval=1 582da79a backsql_get_attr_vals(): number of values in query: 1 582da79a <==backsql_get_attr_vals() 582da79a ==>backsql_get_attr_vals(): oc="dcObject" attr="objectClass" keyval=1 582da79a backsql_get_attr_vals(): number of values in query: 1 582da79a <==backsql_get_attr_vals() 582da79a <==backsql_id2entry() 582da79a => access_allowed: search access to "dc=HORNETSECURITY,dc=COM" "entry" requested 582da79a => slap_access_allowed: backend default search access granted to "(anonymous)" 582da79a => access_allowed: search access granted by read(=rscxd) 582da79a ==>backsql_oc_get_candidates(): oc="dcObject" 582da79a ==>backsql_srch_query() 582da79a ==>backsql_process_filter() 582da79a <==backsql_process_filter() succeeded 582da79a <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,top_domain.id,'dcObject' AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,top_domain WHERE top_domain.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3 582da79a Constructed query: SELECT DISTINCT ldap_entries.id,top_domain.id,'dcObject' AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,top_domain WHERE top_domain.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3 582da79a id: '1' 582da79a >>> dnPrettyNormal: <DC=HORNETSECURITY,DC=COM> => ldap_bv2dn(DC=HORNETSECURITY,DC=COM,0) <= ldap_bv2dn(DC=HORNETSECURITY,DC=COM)=0 => ldap_dn2bv(272) <= ldap_dn2b28dcdc=HORNETSECURITY,dc=COM)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=hornetsecurity,dc=com)=0 582da79a <<< dnPrettyNormal: <dc=HORNETSECURITY,dc=COM>, <dc=hornetsecurity,dc=com> 582da79a backsql_oc_get_candidates(): added entry id=0 keyval=1 dn="DC=HORNETSECURITY,DC=COM"X582da79a <==backsql_oc_get_candidates(): 1 582da79a backsql_search(): loading data for entry id=0 oc_id=1, keyval=1 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffee336700 (LWP 13529)] backsql_search (op=0x7fffe00028d0, r3D0x0x7fffee335950) at /var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/back-sql/search.c:2303 2303 is_entry_referral( e ) ) (gdb) bt #0 backsql_search (op=0x7fffe00028d0, rs=0x7fffee335950) a%2/var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/back-sql/search.c:2303 #1 0x00000000004353a1 in fe_op_search (op=0x7fffe00028d0, rs=0x7fffee335950) at /var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/search.c:402 #2 0x0000000000434d3c in do_search (op=0x7fffe00028d0, rs=0x7fffee335950) at /var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/search.c:247 #3 0x0000000000432754 in connection_operation (ctx=ctx@entry=0x7fffee335b90, arg_v=arg_v@entry=0x7fffe00028d0) at /var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/connection.c:1158 #4 0x0000000000432a27 in connection_read_thread (ctx=0x7fffee335b90, argv=0x10) at /var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/connection.c:1294 #5 0x00007ffff7b98cd2 in ldap_int_thread_pool_wrapper (xpool=0x84bfa0) at /var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/libraries/libldap_r/tpool.c:696 #6 0x00007ffff71de434 in start_thread (arg=0x7fffee336700) at pthread_create.c:334 #7 0x00007ffff618b52d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 (gdb) print e $1 = (Entry *) 0x0 (gdb) print bi->sql_baseObject $2 = (Entry *) 0x0 (gdb) info locals a_hasSubordinate = 0x0 a_entryUUID = 0x0 a_entryCSN = 0x0 e = 0x0 rc = <optimized out> ap = 0x0 bi = 0x89b9f0 dbh = 0x7fffe0102cb0 sres = <optimized out> user_entry = {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} base_entry = {e_id = 0, e_name = {bv_len = 24, bv_val = 0x7fffe000f278 "dc=HORNETSECURITY,dc=COM"}, e_nname = {bv_len = 24, bv_val = 0x7fffe000f2a0 "dc=hornetsecurity,dc=com"}, e_attrs = 0x90a2e8, e_ocflags = 65792, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} manageDSAit = <optimized out> stoptime = 1479390634 bsi = {bsi_op = 0x7fffe00028d0, bsi_rs = 0x7fffee335950, bsi_flags = 1, bsi_base_ndn = 0x7fffe0002908, bsi_use_subtree_shortcut = 1, bsi_base_id = {eid_id = 0, eid_keyval = 1, eid_oc_id = 1, eid_oc = 0xaf3dc0, eid_dn = {bv_len = 24, bv_val = 0x7fffe000f200 "dc=HORNETSECURITY,dc=COM"}, eid_ndn = {bv_len =4%4, bv_val = 0x7fffe000f250 "dc=hornetsecurity,dc=com"}, eid_next = 0x0}, bsi_scope = 2, bsi_filter = 0x7fffe0002eb8, bsi_stoptime = 1479390634, bsi_id_list = 0x7fffe0017658, bsi_id_listtail = 0x7fffe0017698, bsi_c_eid = 0x7fffee334478, bsi_n_candidates = -3, bsi_status = 0, bsi_oc = 0xaf3dc0, bsi_sel = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_from = {bb_val = { bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_join_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_flt_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_filter_oc = 0x0, bsi_dbh = 0x7fffe0102cb0, bsi_attrs = 0x0, bsi_e = 0x0} eid = 0x7fffe0017658 nbase = {bv_len = 0, bv_val = 0x0} lastid = 0 (gdb) print bsi->bsi_op $3 = (Operation *) 0x7fffe00028d0 (gdb) print *(bsi->bsi_op) $4 = {o_hdr = 0x7fffe0002a40, o_tag = 99, o_time = 1479387034, o_tincr = 1, o_bd = 0x89b320, o_req_dn = {bv_len = 24, bv_val = 0x7fffe0002e40 "dc=hornetsecurity,dc=com"}, o_req_ndn = {bv_len = 24, bv_val = 0x7fffe0002e90 "dc=hornetsecurity,dc=com"}, o_request = {oq_add = {rs_modlist = 0x2, rs_e = 0xe10000001f4}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 15461882266100, bv_val = 0x89b3fc "\020\016"}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 3758108344, rb_mech = {bv_len = 15, bv_val = 0x7fffe0002ed8 "(objectClass=*)"}}, oq_compare = {rs_ava = 0x2}, oq_modify = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = -12 '\364'}, rs_increment = 9024508}, oq_modrdn = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = -12 '\364'}, rs_deleteoldrdn = 9024508, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 140736951496376, bv_val = 0xf <error: Cannot access memory at address 0xf>}, rs_newSup = 0x7fffe0002ed8, rs_nnewSup = 0x0}, oq_search = {rs_scope = 2% r rs_deref = 0, rs_slimit = 500, rs_tlimit = 3600, rs_limit = 0x89b3fc, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x7fffe0002eb8, rs_filterstr = {bv_len = 15, bv_val = 0x7fffe0002ed8 "(objectClass=*)"}}, oq_abandon = {rs_msgid = 2}, oq_canl l = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xe10000001f4 <error: Cannot access memory at address 0xe10000001f4>}, rs_flags = 9024508, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xe10000001f4 <error: Cannot access memory at address 0xe10000001f4>}, rs_flags = 9024508, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x7fffe0002eb8 "\207"}, rs_new = {bv_len = 15, bv_val = 0x7fffe0002ed8 "(objectClass=*)"}, 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 = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x7fffe0002b90, o_authz = {sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x7fffe0002620, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} (gdb) In another debug session, I found by stepping through the code that e is initialized from bi->sql_baseObject, which is also 0x0. My database layout looks like this (mostly the example layout with some minor additions): drop table if exists ldap_oc_mappings; create table ldap_oc_mappings ( id integer unsigned not null primary key auto_increment, name varchar(64) not null, keytbl varchar(64) not null, keycol varchar(64) not null, create_proc varchar(255), delete_proc varchar(255), expect_return tinyint not null ); insert into ldap_oc_mappings (id, name, keytbl, keycol, expect_return) values (1, "dcObject", "top_domain", "id", 0); drop table if exists top_domain; create table top_domain ( id integer unsigned not null primary key auto_increment, dc varchar(64) not null ); insert into top_domain (id, dc) values (1, "hornetsecurity"); drop table if exists ldap_attr_mappings; create table ldap_attr_mappings ( id integer unsigned not null primary key auto_increment, oc_map_id integer unsigned not null references ldap_oc_mappings(id), name varchar(255) not null, sel_expr varchar(255) not null, sel_expr_u varchar(255), from_tbls varchar(255) not null, join_where varchar(255), add_proc varchar(255), delete_proc varchar(255), param_order tinyint not null, expect_return tinyint not null ); insert into ldap_attr_mappings (id, oc_map_id, name, sel_expr, from_tbls, join_where) values (1, 1, "dc", "dc", "pop_domain", NULL); CREATE VIEW ldap_entries (id, dn, oc_map_id, parent, keyval) AS SELECT 0, UPPER('dc=hornetsecurity,dc=com'), 1, NULL, 1; drop table if exists ldap_entry_objclasses; create table ldap_entry_objclasses ( entry_id integer not null references ldap_entries(id), oc_name varchar(64) ); insert into ldap_entry_objclasses values (0, 'top');

1 0

(ITS#8530) LMDB: Error on committing large data
by newstzpz＠gmail.com 15 Nov '16

15 Nov '16

Full_Name: Peizhao Zhang Version: LMDB (master) OS: Windows 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.218.255.229) mdb_txn_commit will fail and returns error 87 when committing a huge data block (512 * 412 * 4000 * 4 bytes). The following code demonstrates the problem: #include <lmdb.h> #include <iostream> #include <string> using namespace std; int main() { string name = "./example.mdb"; MDB_env* mdb_env; MDB_dbi mdb_dbi; MDB_val mdb_key, mdb_data; MDB_txn *mdb_txn; mdb_env_create(&mdb_env); int rc = mdb_env_open(mdb_env, name.c_str(), 0, 0664); size_t map_size = 1ULL * 1024ULL * 1024ULL * 1024ULL * 30ULL; mdb_env_set_mapsize(mdb_env, map_size); mdb_txn_begin(mdb_env, NULL, 0, &mdb_txn); mdb_dbi_open(mdb_txn, NULL, 0, &mdb_dbi); int frame_size = 512 * 424 * sizeof(float); std::string frame; frame.resize(frame_size); for (int i = 0; i < 4000; i++) { std::string name = to_string(i); mdb_key.mv_size = name.size(); mdb_key.mv_data = const_cast<char*>(name.data()); mdb_data.mv_size = frame.size(); mdb_data.mv_data = const_cast<char*>(frame.data()); int put_rc = mdb_put(mdb_txn, mdb_dbi, &mdb_key, &mdb_data, 0); if (put_rc != MDB_SUCCESS) { cout << put_rc << endl; return -1; } } // FAIL IN THE FOLLOWING LINE rc = mdb_txn_commit(mdb_txn); if (rc != MDB_SUCCESS) { cout << "error on commit " << rc << endl; return -1; } mdb_dbi_close(mdb_env, mdb_dbi);A%A if (mdb_env != NULL) { mdb_dbi_close(mdb_env, mdb_dbi); mdb_env_close(mdb_env); mdb_env = NULL; } cout << "done " << endl; return 0; } After checking the debug information, it looks like the issue is caused by overflow of the variable 'pos' defined in the function mdb_page_flush() (line 3521). 'pos' is defined as off_t, which actually is long in Windows. When computing the value of 'pos' in line 3563 (pos = pgno * psize), it will overflow when pgno =D3D 524434 and size == 4096, which is happened when large data blocks are committed. This further causes WriteFile() in line 3581 to fail. This issue looks fixed if the type of 'pos' is changed from 'off_t' to 'size_t'.

1 0

Re: (ITS#8529) Avoid hiding the error in LDAP client if user specified CA does not load
by michael＠stroeder.com 10 Nov '16

10 Nov '16

@Quanah: Could this patch even make it into upcoming release 2.4.45?

1 0

(ITS#8529) Avoid hiding the error in LDAP client if user specified CA does not load
by hguo＠suse.com 10 Nov '16

10 Nov '16

Full_Name: Howard Guo Version: Latest at commit 227e02ec2049c6df5df44333980e3b529289a5c7 OS: openSUSE URL: ftp://ftp.openldap.org/incoming/howard-guo-161110.patch Submission from: (NULL) (195.135.221.2) The TLS configuration deliberately hid the error in case that user specified CA locations cannot be read, by loading CAs from default locations; and when user does not specify CA locations, the CAs from default locations are not read at all. This patch corrects the behaviour so that CAs from default location are used if user does not specify a CA location, and user is informed of the error if CAs cannot be loaded from the user specified location.

1 0

RE: (ITS#8436) slapadd hang in bdb_tool_entry_close / ldap_pvt_thread_cond_wait
by quanah＠symas.com 07 Nov '16

07 Nov '16

--On Monday, November 07, 2016 10:47 AM +0000 Mark.Bannister(a)morganstanley.com wrote: Decoded version of Mark's mail: 'Dear Steffen, Apologies for the delay in replying. No I didn't encounter the problem again, at least, I haven't spotted any hanging slapadd processes. But I'm not looking for them either. I think it is a rare race condition. From your de scription you may well have found a new way to trigger a similar deadlock. I provided a patch, and another suggested way of fixing the issue I encountered, and as you can see from the openldap-technical archive, I had one short reply from Howard on the subject and nothing thereafter. Likewise ITS#8436 has sat in Incoming since it was raised in June without comment. My feeling is that the OpenLDAP code base is now too big for the number of active developers, pushing rare issues like this right to the bottom of their queue. I doubt it'll get fixed. Best regards, Mark.' (irrelevant parts removed) --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#8436) slapadd hang in bdb_tool_entry_close / ldap_pvt_thread_cond_wait
by Mark.Bannister＠morganstanley.com 07 Nov '16

07 Nov '16

77u/RGVhciBTdGVmZmVuLA0KDQpBcG9sb2dpZXMgZm9yIHRoZSBkZWxheSBpbiByZXBseWluZy4N Cg0KTm8gSSBkaWRuJ3QgZW5jb3VudGVyIHRoZSBwcm9ibGVtIGFnYWluLCBhdCBsZWFzdCwgSSBo YXZlbid0IHNwb3R0ZWQgYW55IGhhbmdpbmcgc2xhcGFkZCBwcm9jZXNzZXMuICBCdXQgSSdtIG5v dCBsb29raW5nIGZvciB0aGVtIGVpdGhlci4gIEkgdGhpbmsgaXQgaXMgYSByYXJlIHJhY2UgY29u ZGl0aW9uLiAgRnJvbSB5b3VyIGRlc2NyaXB0aW9uIHlvdSBtYXkgd2VsbCBoYXZlIGZvdW5kIGEg bmV3IHdheSB0byB0cmlnZ2VyIGEgc2ltaWxhciBkZWFkbG9jay4NCg0KSSBwcm92aWRlZCBhIHBh dGNoLCBhbmQgYW5vdGhlciBzdWdnZXN0ZWQgd2F5IG9mIGZpeGluZyB0aGUgaXNzdWUgSSBlbmNv dW50ZXJlZCwgYW5kIGFzIHlvdSBjYW4gc2VlIGZyb20gdGhlIG9wZW5sZGFwLXRlY2huaWNhbCBh cmNoaXZlLCBJIGhhZCBvbmUgc2hvcnQgcmVwbHkgZnJvbSBIb3dhcmQgb24gdGhlIHN1YmplY3Qg YW5kIG5vdGhpbmcgdGhlcmVhZnRlci4gIExpa2V3aXNlIElUUyM4NDM2IGhhcyBzYXQgaW4gSW5j b21pbmcgc2luY2UgaXQgd2FzIHJhaXNlZCBpbiBKdW5lIHdpdGhvdXQgY29tbWVudC4NCg0KTXkg ZmVlbGluZyBpcyB0aGF0IHRoZSBPcGVuTERBUCBjb2RlIGJhc2UgaXMgbm93IHRvbyBiaWcgZm9y IHRoZSBudW1iZXIgb2YgYWN0aXZlIGRldmVsb3BlcnMsIHB1c2hpbmcgcmFyZSBpc3N1ZXMgbGlr ZSB0aGlzIHJpZ2h0IHRvIHRoZSBib3R0b20gb2YgdGhlaXIgcXVldWUuICBJIGRvdWJ0IGl0J2xs IGdldCBmaXhlZC4NCg0KQmVzdCByZWdhcmRzLA0KTWFyay4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFN0ZWZmZW4gTW9zZXIgW21haWx0bzpsaXN0c0BzdGVmZmVuLW1vc2Vy LmRlXSANClNlbnQ6IDIzIE9jdG9iZXIgMjAxNiAwMjo0Mg0KVG86IEJhbm5pc3RlciwgTWFyayAo RW50ZXJwcmlzZSBJbmZyYXN0cnVjdHVyZSkNCkNjOiBvcGVubGRhcC1pdHNAT3BlbkxEQVAub3Jn DQpTdWJqZWN0OiBSZTogKElUUyM4NDM2KSBzbGFwYWRkIGhhbmcgaW4gYmRiX3Rvb2xfZW50cnlf Y2xvc2UgLyBsZGFwX3B2dF90aHJlYWRfY29uZF93YWl0DQoNCkRlYXIgTWFyaywNCg0KT24gMDUv MjUvMTYgMjozOCBQTSwgTWFyayBCYW5uaXN0ZXIgd3JvdGU6DQo+IENhbiBhbnlvbmUgc2hlZCBs aWdodCBvbiB3aHkgbXkgc2xhcGFkZCBwcm9jZXNzIG9uIFNvbGFyaXMgMTEgd2FzIA0KPiBoYW5n aW5nIChzbGFwZCAyLjQuMzApPyAgSSB3YXMgcGlwaW5nIOKAmGd1bnppcCAtY+KAmSB0aHJvdWdo IHRvIHNsYXBhZGQgDQo+IChmcm9tIGFuIG92ZXJuaWdodCBjcm9uIGpvYikuICBUaGlzIHVzdWFs bHkgd29ya3MgZmluZS4gIEnigJltIGd1ZXNzaW5nIA0KPiBwZXJoYXBzIHRoZSBndW56aXAgcHJv Y2VzcyBlbmNvdW50ZXJlZCBhbiBlcnJvciwgbWF5YmUgYW4gRVBJUEUgd2FzIA0KPiBzZW50LCBi dXQgdGhlIHN0YWNrIHRyYWNlIG1hbnkgZGF5cyBsYXRlciBmcm9tIHNsYXBhZGQgZG9lc27igJl0 IGxvb2sgDQo+IHJpZ2h0LiAgT25seSAyIHRocmVhZHMsIGFuZCBib3RoIG9mIHRoZW0gaW4gDQo+ IGxkYXBfcHZ0X3RocmVhZF9jb25kX3dhaXQoKSwgYnV0IG5vIG90aGVyIHRocmVhZHMgc28gd2hh dCBhcmUgdGhleSANCj4gd2FpdGluZyBmb3IgZXhhY3RseT8NCg0KSSd2ZSBqdXN0IGNvbWUgYWNy b3NzIHlvdXIgcHJvYmxlbSByZXBvcnQgd2hpY2ggeW91IHBvc3RlZCB0byB0aGUgIm9wZW5sZGFw LWl0cyIgbWFpbGluZyBsaXN0IGluIHRoaXMgeWVhcidzIE1heToNCg0KICBodHRwOi8vd3d3Lm9w ZW5sZGFwLm9yZy9saXN0cy9vcGVubGRhcC10ZWNobmljYWwvMjAxNjA1L3RocmVhZHMuaHRtbCMw MDA3OQ0KDQpUb2RheSwgSSBlbmNvdW50ZXJlZCBhIHNpbWlsYXIgaGFuZyBvZiBvdXIgT3BlbkxE QVAgMi40LjMwIHNlcnZlciBvbiBhIFNvbGFyaXMgMTEuMyguMTEuNi4wKSBob3N0Lg0KDQpJdCBp cyBxdWl0ZSBpbnRlcmVzdGluZyB0aGF0IHRoZSBmdW5jdGlvbiAiYmRiX3Rvb2xfZW50cnlfY2xv c2UiIGRvZXNuJ3Qgc2VlbSB0byBwbGF5IGEgcm9sZSBpbiBteSBjYXNlLCBidXQgImxkYXBfcHZ0 X3RocmVhZF9jb25kX3dhaXQiIGFuZCAibGRhcF9pbnRfdGhyZWFkX3Bvb2xfd3JhcHBlciIgZG8g c2VlbSB0by4NCg0KTXkgcXVlc3Rpb25zIHRvIHlvdXIgYWRkcmVzcyBhbmQgdG8gdGhlIG1haWxp bmcgbGlzdCBhcmU6IEhhcyB0aGUgYnVnL3Byb2JsZW0gYmVlbiBmdWxseSBhbmFseXplZCBhbmQg aGFzIGl0IGJlZW4gZml4ZWQgaW4gdGhlIG1lYW50aW1lPw0KTWFyaywgZGlkIHlvdSBoYXZlIGFu b3RoZXIgaGFuZyBvZiB0aGlzIGtpbmQgb3IgYW55IHNpbWlsYXIgcHJvYmxlbXMgd2l0aCB5b3Vy IE9wZW5MREFQIGluc3RhbGxhdGlvbj8NCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBpbiBhZHZhbmNl IGZvciBhbnkgaGVscGZ1bCBoaW50cyENCg0KS2luZCByZWdhcmRzLA0KU3RlZmZlbg0KDQoNCi0t DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCkRpcGwuLUluZi4gU3RlZmZlbiBNb3Nlcg0KU2Nob29sIG9mIEFk dmFuY2VkIFByb2Zlc3Npb25hbCBTdHVkaWVzICAgICAgICAgICAgUm9vbTogNDUuMy4xMTANClVs bSBVbml2ZXJzaXR5ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRlbDogKzQ5 LjczMS41MC0zMjQwNw0KQWxiZXJ0LUVpbnN0ZWluLUFsbGVlIDQ1ICAgICAgICAgICAgICAgICAg ICAgICAgICAgRmF4OiArNDkuNzMxLjUwLTMyNDA5DQo4OTA4MSBVbG0sIEdlcm1hbnkgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL3NhcHMudW5pLXVsbS5kZS8NCg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpOT1RJQ0U6IE1vcmdhbiBTdGFubGV5IGlzIG5vdCBhY3Rp bmcgYXMgYSBtdW5pY2lwYWwgYWR2aXNvciBhbmQgdGhlIG9waW5pb25zIG9yIHZpZXdzIGNvbnRh aW5lZCBoZXJlaW4gYXJlIG5vdCBpbnRlbmRlZCB0byBiZSwgYW5kIGRvIG5vdCBjb25zdGl0dXRl LCBhZHZpY2Ugd2l0aGluIHRoZSBtZWFuaW5nIG9mIFNlY3Rpb24gOTc1IG9mIHRoZSBEb2RkLUZy YW5rIFdhbGwgU3RyZWV0IFJlZm9ybSBhbmQgQ29uc3VtZXIgUHJvdGVjdGlvbiBBY3QuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIGRlc3Ry b3kgYWxsIGVsZWN0cm9uaWMgYW5kIHBhcGVyIGNvcGllcyBhbmQgbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkuIE1pc3RyYW5zbWlzc2lvbiBpcyBub3QgaW50ZW5kZWQgdG8gd2FpdmUgY29u ZmlkZW50aWFsaXR5IG9yIHByaXZpbGVnZS4gTW9yZ2FuIFN0YW5sZXkgcmVzZXJ2ZXMgdGhlIHJp Z2h0LCB0byB0aGUgZXh0ZW50IHBlcm1pdHRlZCB1bmRlciBhcHBsaWNhYmxlIGxhdywgdG8gbW9u aXRvciBlbGVjdHJvbmljIGNvbW11bmljYXRpb25zLiBUaGlzIG1lc3NhZ2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdmFpbGFibGUgYXQgdGhlIGZvbGxvd2luZyBsaW5rOiBodHRwOi8vd3d3Lm1vcmdh bnN0YW5sZXkuY29tL2Rpc2NsYWltZXJzICBJZiB5b3UgY2Fubm90IGFjY2VzcyB0aGVzZSBsaW5r cywgcGxlYXNlIG5vdGlmeSB1cyBieSByZXBseSBtZXNzYWdlIGFuZCB3ZSB3aWxsIHNlbmQgdGhl IGNvbnRlbnRzIHRvIHlvdS4gQnkgY29tbXVuaWNhdGluZyB3aXRoIE1vcmdhbiBTdGFubGV5IHlv dSBjb25zZW50IHRvIHRoZSBmb3JlZ29pbmcgYW5kIHRvIHRoZSB2b2ljZSByZWNvcmRpbmcgb2Yg Y29udmVyc2F0aW9ucyB3aXRoIHBlcnNvbm5lbCBvZiBNb3JnYW4gU3RhbmxleS4=

1 0

Re: (ITS#8528) Incorrect results on replace op for olcAccess
by quanah＠symas.com 03 Nov '16

03 Nov '16

--On Friday, November 04, 2016 12:41 AM +0000 openldap-its(a)OpenLDAP.org wrote: Here's the full text, since the web form apparently ate it: When doing a full replace on all values for olcAccess, things work incorrectly if the values provided are not in numeric sorted order. This is problematic when using tools like ldapvi who do alphabetic sort. It is trivial to reproduce the problem using the following example LDIFs: cat > replace_ordered.ldif <<EOF dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcAccess olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {1}to dn.exact="cn=1" by * none olcAccess: {2}to dn.exact="cn=2" by * none olcAccess: {3}to dn.exact="cn=3" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: {5}to dn.exact="cn=5" by * none olcAccess: {6}to dn.exact="cn=6" by * none olcAccess: {7}to dn.exact="cn=7" by * none - EOF cat > replace_ordered_mixup.ldif <<EOF dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcAccess olcAccess: {7}to dn.exact="cn=7" by * none olcAccess: {1}to dn.exact="cn=1" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: {3}to dn.exact="cn=3" by * none olcAccess: {5}to dn.exact="cn=5" by * none olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {6}to dn.exact="cn=6" by * none olcAccess: {2}to dn.exact="cn=2" by * none - EOF With the initial config as: olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to * by * read When the ordered version is done, the correct result occurs: olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {1}to dn.exact="cn=1" by * none olcAccess: {2}to dn.exact="cn=2" by * none olcAccess: {3}to dn.exact="cn=3" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: {5}to dn.exact="cn=5" by * none olcAccess: {6}to dn.exact="cn=6" by * none olcAccess: {7}to dn.exact="cn=7" by * none However, when the unordered replaced is done, an incorrect result occurs: olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {1}to dn.exact="cn=7" by * none olcAccess: {2}to dn.exact="cn=2" by * none olcAccess: {3}to dn.exact="cn=1" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: {5}to dn.exact="cn=3" by * none olcAccess: {6}to dn.exact="cn=5" by * none olcAccess: {7}to dn.exact="cn=6" by * none Since we are doing a replace of all values, it should not be trying to reweight the operation. Instead, the values should just be numeric sorted and then written out accordingly, so one ends up with the same result as in the ordered case. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8528) Incorrect results on replace op for olcAccess
by quanah＠openldap.org 03 Nov '16

03 Nov '16

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) When doing a full replace on all values for olcAccess, things work incorrectly if the values provided are not in numeric sorted order. This is problematic when using tools like ldapvi who do alphabetic sort. It is trivial to reproduce the problem using the following example LDIFs: cat > replace_ordered.ldif <<EOF dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcAccess olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {1}to dn.exact="cn=1" by * none olcAccess: {2}to dn.exact="cn=2" by * none olcAccess: {3}to dn.exact="cn=3" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: {5}to dn.exact="cn=5" by * none olcAccess: {6}to dn.exact="cn=6" by * none olcAccess: {7}to dn.exact="cn=7"yby * none - EOF cat > replace_ordered_mixup.ldif <<EOF dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcAccess olcAccess: {7}to dn.exact="cn=7" by * none olcAccess: {1}to dn.exact="cn=1" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: %7%7}to dn.exact="cn=3" by * none olcAccess: {5}to dn.exact="cn=5" by * none olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {6}to dn.exact="cn=6" by * none olcAccess: {2}to dn.exact="cn=2" by * none - EOF With the initial config as: olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to * by * read When the ordered version is done, the correct result occurs:D%D olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {1}to dn.exact="cn=1" by * none olcAccess: {2}to dn.exact="cn=2" by * none olcAccess: {3}to dn.exact="cn=3" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: {5}to dn.exact="cn=5" by * none

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs