openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#8533) Support OpenSSL-1.1.0c
by quanah＠symas.com 28 Nov '16

28 Nov '16

--On Saturday, November 26, 2016 10:50 PM +0000 sca(a)andreasschulze.de wrote: > But I personally need pkg-config because my openssl library is named > libssl-dv / libcrypto-dv > to coexist with the distribution versions. Viktor Dukhovni told me to > build openssl-1.1 that way > and beside the requirement for pkg-config I'm personally fine with > that advise :-) > > should I prepare the new patch to fit your needs? > otherwise I would be fine if you modify the contribution to your needs. > > Anyway: after I wrote the patch for git-master it was very easy to > create a patch to compile also 2.4.44 with openssl-1.1 > I could publish that also next week. Do you think that makes sense? Hi Andreas, Thanks for looking into this. I have a few additional comments: a) "configure.in" should be patched rather than "configure", and then I'd verify that regenerating configure works appropriately. b) A coding style issue found throughout the patch, where you are using NULL == variable rather than variable == NULL. This should be fixed. For example, you have: if ( NULL == tlso_bio_method ) { this instead should be: if ( tlso_bio_method == NULL ) { Thanks, 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#8533) Support OpenSSL-1.1.0c
by sca＠andreasschulze.de 26 Nov '16

26 Nov '16

Howard Chu: > Patches should be relative to git master. There is no 2.4.45. right, I wrongly named the git master 2.4.45 - my fault but in fact it's git master... > Don't use pkg-config. Not all systems support it. I know only linux, sorry. Again: your right, support for openssl-1.1 don't require pkg-config. But I personally need pkg-config because my openssl library is named libssl-dv / libcrypto-dv to coexist with the distribution versions. Viktor Dukhovni told me to build openssl-1.1 that way and beside the requirement for pkg-config I'm personally fine with that advise :-) should I prepare the new patch to fit your needs? otherwise I would be fine if you modify the contribution to your needs. Anyway: after I wrote the patch for git-master it was very easy to create a patch to compile also 2.4.44 with openssl-1.1 I could publish that also next week. Do you think that makes sense? Thanks, Andreas

1 0

Re: (ITS#8533) Support OpenSSL-1.1.0c
by hyc＠symas.com 26 Nov '16

26 Nov '16

sca+openldap(a)andreasschulze.de wrote: > Full_Name: Andreas Schulze > Version: 2.4.45~git Patches should be relative to git master. There is no 2.4.45. > OS: linux > URL: ftp://ftp.openldap.org/incoming/andreas-schulze-161125.patch > Submission from: (NULL) (2001:a60:f0b4:e502::152) > > > while http://www.openldap.org/its/index.cgi/Development?id=8353 > end with "work with openssl-1.1" I checked out openldap from git in november > 2016 > and found it does not compile. So I write the patch. > > it solve the following challenges: > - SSL_library_init no longer exist, use OPENSSL_init_ssl to detect openssl > - configure use pkg-config to find the names of libssl and libcrypto Don't use pkg-config. Not all systems support it. > - codechanges in libraries/libldap/tls_o.c to handle the API changes introduced > by openssl-1.1.0 > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8533) Support OpenSSL-1.1.0c
by sca+openldap＠andreasschulze.de 25 Nov '16

25 Nov '16

Full_Name: Andreas Schulze Version: 2.4.45~git OS: linux URL: ftp://ftp.openldap.org/incoming/andreas-schulze-161125.patch Submission from: (NULL) (2001:a60:f0b4:e502::152) while http://www.openldap.org/its/index.cgi/Development?id=8353 end with "work with openssl-1.1" I checked out openldap from git in november 2016 and found it does not compile. So I write the patch. it solve the following challenges: - SSL_library_init no longer exist, use OPENSSL_init_ssl to detect openssl - configure use pkg-config to find the names of libssl and libcrypto - codechanges in libraries/libldap/tls_o.c to handle the API changes introduced by openssl-1.1.0

1 0

Re: (ITS#8531) Segfault in servers/slapd/back-sql/search.c
by quanah＠symas.com 21 Nov '16

21 Nov '16

--On Thursday, November 17, 2016 3:47 PM +0000 winkelmann(a)hornetsecurity.com wrote: > 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 Hello Guido, As noted in the slapd-sql(5) man page the backend is entirely experimental and one uses it at their own risk. There is not, to my knowledge, any current maintainer for the backend at this time. Patches welcome. If you do decide to pursue a patch, please be sure and read over: <http://www.openldap.org/devel/contributing.html> Regards, 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#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

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