openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#5994) replica segfault after syncing final entry
by quanah＠zimbra.com 05 Mar '09

05 Mar '09

Full_Name: Quanah Gibson-Mount Version: 2.3.43 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) With a replica doing a full refresh from the master, it segfaults on the final entry. The line in question is: rc = bdb_cache_find_id( op, ltid, eip->bei_id, &eip, 0, locker, &plock ); Core data: Program terminated with signal 11, Segmentation fault. #0 0x00002aaaaf76ddee in bdb_delete (op=0x41000840, rs=0x41000430) at delete.c:178 There is only one active thread in the core: (gdb) thr apply all bt Thread 4 (process 23189): #0 0x0000003167a075b5 in pthread_join () from /lib64/libpthread.so.0 #1 0x00002aaaaaabd817 in ldap_pvt_thread_join (thread=1082132800, thread_return=0x0) at thr_posix.c:193 #2 0x0000000000429c79 in slapd_daemon () at daemon.c:2579 #3 0x0000000000412183 in main (argc=10, argv=0x7fffca15ec78) at main.c:859 Thread 3 (process 23190): #0 0x0000003166ecec48 in ?? () #1 0x0000000000000000 in ?? () Thread 2 (process 23192): #0 0x0000003167a0a4a6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002aaaaaabd8c4 in ldap_pvt_thread_cond_wait (cond=0x6579a50, mutex=0x6579a28) at thr_posix.c:299 #2 0x00002aaaaaabc609 in ldap_int_thread_pool_wrapper (xpool=0x6579a20) at tpool.c:466 #3 0x0000003167a062f7 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003166ece85d in ?? () #5 0x0000000000000000 in ?? () Thread 1 (process 23191): #0 0x00002aaaaf76ddee in bdb_delete (op=0x41000840, rs=0x41000430) at delete.c:178 #1 0x00000000004a0fe9 in overlay_op_walk (op=0x41000840, rs=0x41000430, which=op_delete, oi=0x66a3550, on=0x0) at backover.c:650 #2 0x00000000004a11ec in over_op_func (op=0x41000840, rs=0x41000430, which=op_delete) at backover.c:702 #3 0x00000000004a1336 in over_op_delete (op=0x41000840, rs=0x41000430) at backover.c:754 #4 0x00000000004985fc in syncrepl_del_nonpresent (op=0x41000840, si=0x66a3170, uuids=0x0, cookiecsn=0x41000640) at syncrepl.c:2167 #5 0x0000000000493849 in do_syncrep2 (op=0x41000840, si=0x66a3170) at syncrepl.c:823 #6 0x00000000004946e9 in do_syncrepl (ctx=0x41000e00, arg=0x66a3350) at syncrepl.c:1102 #7 0x00002aaaaaabc56a in ldap_int_thread_pool_wrapper (xpool=0x6579a20) at tpool.c:478 #8 0x0000003167a062f7 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003166ece85d in ?? () #10 0x0000000000000000 in ?? () The operation data is: (gdb) print *op $1 = {o_hdr = 0x410009a0, o_tag = 74, o_time = 1236201040, o_tincr = 2166, o_bd = 0x41000080, o_req_dn = {bv_len = 0, bv_val = 0x6902820 ""}, o_req_ndn = {bv_len = 0, bv_val = 0x6b8dcd0 ""}, o_request = {oq_add = {rs_e = 0x2, rs_modlist = 0xffffffffffffffff}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 18446744073709551615, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x41000370 "\t"}, rb_ssf = 159460192, rb_tmp_mech = {bv_len = 15, bv_val = 0x66a2ac0 "(objectclass=*)"}}, oq_compare = {rs_ava = 0x2}, oq_modify = { rs_modlist = 0x2, rs_increment = -1}, oq_modrdn = {rs_newrdn = {bv_len = 2, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x41000370, rs_nnewSup = 0x9812b60, rs_deleteoldrdn = 15}, oq_search = {rs_scope = 2, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x41000370, rs_filter = 0x9812b60, rs_filterstr = {bv_len = 15, bv_val = 0x66a2ac0 "(objectclass=*)"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = { rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = { rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 1090519920, bv_val = 0x9812b60 "�5\221\t"}, rs_new = {bv_len = 15, bv_val = 0x66a2ac0 "(objectclass=*)"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_ctrlflag = '\0' <repeats 12 times>, "\002", '\0' <repeats 18 times>, o_controls = 0x41000a18, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x66a2690 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x66a0a20 "cn=config"}, sai_ssf = 256, sai_transport_ssf = 0, sai_tls_ssf = 256, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x980ebf0, o_ctrls = 0x0, o_csn = {bv_len = 32, bv_val = 0x9417220 "20090304090011Z#000000#00#000000"}, o_private = 0x40fffef0, o_next = {stqe_next = 0x0}} (gdb) print *ltid $3 = {mgrp = 0x675ea50, parent = 0x0, last_lsn = {file = 0, offset = 0}, txnid = 2147483701, tid = 0, off = 16056, lock_timeout = 0, expire = 0, txn_list = 0x0, links = {tqe_next = 0x0, tqe_prev = 0x675ea58}, xalinks = {tqe_next = 0x0, tqe_prev = 0x0}, events = {tqh_first = 0x0, tqh_last = 0x68dc978}, logs = {stqh_first = 0x0, stqh_last = 0x68dc988}, kids = { tqh_first = 0x0, tqh_last = 0x68dc998}, klinks = {tqe_next = 0x0, tqe_prev = 0x0}, api_internal = 0x0, cursors = 0, abort = 0x2aaaafa4ca70 <__txn_abort_pp>, commit = 0x2aaaafa4caf0 <__txn_commit_pp>, discard = 0x2aaaafa4c9f0 <__txn_discard_pp>, id = 0x2aaaafa4a690 <__txn_id>, prepare = 0x2aaaafa4bf70 <__txn_prepare>, set_timeout = 0x2aaaafa4b0b0 <__txn_set_timeout>, flags = 16} And here's the last few lines of debug output when I ran slapd with '-d32767': => test_filter PRESENT => access_allowed: search access to "cn=serverX,cn=servers,cn=zimbra" "objectClass" requested <= root access granted <= test_filter 6 send_ldap_result: conn=-1 op=0 p=3 send_ldap_result: err=0 matched="" text="" ==> bdb_delete: bdb_dn2entry("") entry_decode: "" <= entry_decode() (serverX is the last dn in an ldif produced with slapcat, and it's also the name of the replica server).

1 0

(ITS#5993) slapo-chain TLS issues
by duramaxlb7＠gmail.com 05 Mar '09

05 Mar '09

Full_Name: Chad Richards Version: 2.4.15 OS: CentOS 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.178.116.129) overlay chain chain-rebind-as-user FALSE chain-uri "ldap://XXX" chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=Manager,dc=XXX,dc=com" credentials="secret" mode="self" starttls=critical tls_reqcert=never tls_cacertdir=/etc/openldap/cacerts chain-tls start chain-return-error TRUE slapo-chain and TLS work fine connecting to the slave with LUMA, I can do password updates and everything is fine. At first TLS slapo-chain wouldn't work in LUMA until I added starttls=critical inside chain-idassert-bind Now the problem I'm having is that I cannot do a passwd as root or an ldap user from the shell prompt. ldap.conf ssl start_tls tls_reqcert never tls_checkpeer no tls_cacertdir /etc/openldap/cacerts Master log file when slapo-chain runs --------------- TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(18): got connid=6 connection_read(18): checking for input on id=6 TLS trace: SSL3 alert read:fatal:unknown CA TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca. connection_read(18): TLS accept failure error=-1 id=6, closing connection_close: conn=6 sd=18 Slave log file when slapo-chain runs ----------------- TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 19, subject: /C=US/ST=XX/O=XX/OU=XX/CN=XX/emailAddress=XX, issuer: /C=US/ST=XX/O=XX/OU=XX/CN=XX/emailAddress=XX TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. I had the same problem with LUMA and that problem went away when I put the starttls=critical in the chain-idassert-bind my ldap.conf works fine for everything else but just dies on passwd with TLS errors with slapo-chain. Any ideas? Thanks!

1 0

(ITS#5992) libldap with gnutls don't trust V1 CAs.
by mathias.gug＠canonical.com 05 Mar '09

05 Mar '09

Full_Name: Mathias Gug Version: 2.4.15 OS: Ubuntu Linux (Jaunty - 9.04) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.56.226.136) Starting with GnuTLS 2.6.3, V1 CA certs are no longer trusted by default when a CA chain is checked. Thus libldap+gnutls breaks in existing environement when one of the CA certs uses a V1 certificate. However libldap+openssl still supports V1 certificates in the CA chain. See https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/305264 for more information. Could libldap+gnutls be updated to also support V1 CA certificates to match features provided by libldap+openssl? To reproduce: 0. Need two versions of openldap : one compiled with gnutls, the other with openssl. 1. Create a V1 CA. 2. Create a certificate to be used by slapd and sign it with the V1 CA. 3. Configure a slapd+openssl system with certificates issues above. 4. Try to connect to the slapd+openssl system with a libldap+gnutls client: mathiaz@t-slapd-gnutls:~$ ldapsearch -b "dc=vmnet" -D "cn=admin,dc=vmnet" -x -w mypwd -H ldaps://t-slapd-openssl./ -d 1 ldap_url_parse_ext(ldaps://t-slapd-openssl./) ldap_create ldap_url_parse_ext(ldaps://t-slapd-openssl.:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP t-slapd-openssl.:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.42.220:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS: peer cert untrusted or revoked (0x82) TLS: can't connect: (unknown error code). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) On a system with libldap+openssl: mathiaz@t-slapd-openssl:~$ ldapsearch -b "dc=vmnet" -D "cn=admin,dc=vmnet" -x -w mypwd -H ldaps://t-slapd-openssl./ # extended LDIF # # LDAPv3 # base <dc=vmnet> with scope subtree # filter: (objectclass=*) # requesting: ALL # # vmnet dn: dc=vmnet objectClass: top objectClass: dcObject objectClass: organization o: vmnet dc: vmnet # admin, vmnet dn: cn=admin,dc=vmnet objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: e2NyeXB0fWtlVHlnV1lleFBDWFU= # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 $ ldapsearch is able to connect to the slapd+openssl server.

1 0

(ITS#5991) slapd+gnutls doesn't send all of the CA certs available in the certficate chain while slapd+openssl does
by mathias.gug＠canonical.com 05 Mar '09

05 Mar '09

Full_Name: Mathias Gug Version: 2.4.15 OS: Ubuntu Linux (Jaunty - 9.04) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.56.226.136) slapd+gnutls doesn't send all the certificates in the chain while slapd+openssl does. openldap version: 2.4.15 gnutls version: 2.4.2 openssl version: 0.9.8g Here are two systems running slapd 2.4.15 - one compiled with gnutls (t-slapd-gnutls), the other with openssl (t-slapd-openssl). mathiaz@t-slapd-gnutls:~$ gnutls-cli --x509cafile allca.pem --print-cert -p 636 t-slapd-gnutls. Processed 2 CA certificate(s). Resolving 't-slapd-gnutls.'... Connecting to '172.19.42.87:636'... - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: -----BEGIN CERTIFICATE----- MIICyTCCAjKgAwIBAgIBBTANBgkqhkiG9w0BAQUFADBIMQswCQYDVQQGEwJDQTEL MAkGA1UECBMCUUMxEDAOBgNVBAoTB01hdGhpYXoxGjAYBgNVBAMTEVRFU1QgQ0FW MSAtIEhBUkRZMB4XDTA5MDMwNDE5NTcxMVoXDTEwMDMwNDE5NTcxMVowRjELMAkG A1UEBhMCQ0ExCzAJBgNVBAgTAlFDMRAwDgYDVQQKEwdNYXRoaWF6MRgwFgYDVQQD Ew90LXNsYXBkLWdudXRscy4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL5X ERAGYnqTCJae2FnEB1qT2Hk0sNiD1n+mnyhNDespomTINPLKpZZmqOSlD7x71zuy DQ/Z6uxgIxOhuUV9VVo2cISi9MmEOYn4qxGq2YIHyra5FJZf6O43qajicDaRRzGz UA17ap7vDqgig9T4qFvwCllz4EFlcTzxV+N99m1RAgMBAAGjgcQwgcEwCQYDVR0T BAIwADALBgNVHQ8EBAMCBaAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJh dGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBSii4L1Po9xGWrMD2oG8VeFuTQtfzBa BgNVHSMEUzBRoUykSjBIMQswCQYDVQQGEwJDQTELMAkGA1UECBMCUUMxEDAOBgNV BAoTB01hdGhpYXoxGjAYBgNVBAMTEVRFU1QgQ0FWMSAtIEhBUkRZggEAMA0GCSqG SIb3DQEBBQUAA4GBAEEQMsEc0VQOt1y8B22xfRewUmwMKk34J80aFkKuG/RQJoBw TSnlHpqyZFvmOu4JaCJAh6IdTdxfsuDB5vu/5kpNMc3jJX1Ale17l1MuxB6lvcKn zG3A17BIIZh3aoJcVQgDAQ8Vr/I9z8y51i1Qr37E5HF2GjuuyF+5BJz9lITq -----END CERTIFICATE----- # The hostname in the certificate matches 't-slapd-gnutls.'. # valid since: Wed Mar 4 14:57:11 EST 2009 # expires at: Thu Mar 4 14:57:11 EST 2010 # fingerprint: 72:5A:24:83:6C:5C:3F:0E:80:52:F1:61:CD:C3:0D:31 # Subject's DN: C=CA,ST=QC,O=Mathiaz,CN=t-slapd-gnutls. # Issuer's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY - Peer's certificate is trusted - Version: TLS1.1 - Key Exchange: RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Handshake was completed - Simple Client Mode: mathiaz@t-slapd-gnutls:~$ gnutls-cli --x509cafile allca.pem --print-cert -p 636 t-slapd-openssl. Processed 2 CA certificate(s). Resolving 't-slapd-openssl.'... Connecting to '172.19.42.220:636'... - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: -----BEGIN CERTIFICATE----- MIIB/jCCAWcCAQcwDQYJKoZIhvcNAQEFBQAwSDELMAkGA1UEBhMCQ0ExCzAJBgNV BAgTAlFDMRAwDgYDVQQKEwdNYXRoaWF6MRowGAYDVQQDExFURVNUIENBVjEgLSBI QVJEWTAeFw0wOTAzMDQyMDExMTRaFw0xMDAzMDQyMDExMTRaMEcxCzAJBgNVBAYT AkNBMQswCQYDVQQIEwJRQzEQMA4GA1UEChMHTWF0aGlhejEZMBcGA1UEAxMQdC1z bGFwZC1vcGVuc3NsLjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzTEuHfVR ELoXxSyVTwWrfIIsoKqBfbZYJSGQcTTEtuvxABxX8AoKyc9T+AkhR4wsSmRZGOBz opH9u0LReaGyhWkUA/XaFF24jkSogi6yDsh478P/ayZjushPLh9LpIeW/2lD9xkh t5LGW255lXIMGI5+/x8EgiaU1pS5OO9wz/kCAwEAATANBgkqhkiG9w0BAQUFAAOB gQBlg/lIawsDYFqqNz61BNl2nix4LrIRFxiOA/p14VFkRyuCVHXDjhBtlb13wBZk wVTDfUdykvy2nlJq8bLQ7OYYdiA4h64HMnLTMyMALKBFiVwyrg/GvF7TsUg3K41K uFTF0H1bQOmqrJPcIu8r+h3gQLkCRvBLssZaQtA4M4jw4A== -----END CERTIFICATE----- # The hostname in the certificate matches 't-slapd-openssl.'. # valid since: Wed Mar 4 15:11:14 EST 2009 # expires at: Thu Mar 4 15:11:14 EST 2010 # fingerprint: 85:7F:06:0A:EC:3A:9E:6C:78:BC:FC:C3:8F:4D:4B:E9 # Subject's DN: C=CA,ST=QC,O=Mathiaz,CN=t-slapd-openssl. # Issuer's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY - Certificate[1] info: -----BEGIN CERTIFICATE----- MIIB/zCCAWgCAQAwDQYJKoZIhvcNAQEFBQAwSDELMAkGA1UEBhMCQ0ExCzAJBgNV BAgTAlFDMRAwDgYDVQQKEwdNYXRoaWF6MRowGAYDVQQDExFURVNUIENBVjEgLSBI QVJEWTAeFw0wOTAzMDMxODI1NTBaFw0xMjAzMDIxODI1NTBaMEgxCzAJBgNVBAYT AkNBMQswCQYDVQQIEwJRQzEQMA4GA1UEChMHTWF0aGlhejEaMBgGA1UEAxMRVEVT VCBDQVYxIC0gSEFSRFkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMZSKqDg Y5rn4SgJUgnO0IAM2Us/5sQ18mu8gxoDeLkIcHHuiwYHeT4BcOit2hemmOCIEolh XPKkMD4MVAbafDFtJjhuEgPtWoUuZcOa9gRi3eH+h7QEYhhwnwLewrQGhx4tsfY4 wR3LIUm/lxkJISy17v3uc5yNLcAlreUrrdJ1AgMBAAEwDQYJKoZIhvcNAQEFBQAD gYEAAsaBDAMUKofwOZPNNV/9EKglG7O3G5p/i9h8n5C3bXy6E6vWtVxqpWd5qBEt uMXU1vIIop7FrKornuPWtEy4jKSw12Sv9EXaUJ9rfXQTWh6GpgUmTjlZtOwjABT9 fAU4M9MdLDTBaZA11NqtdMMPKTwTHXjmv9bKcgOLh1g5WhQ= -----END CERTIFICATE----- # valid since: Tue Mar 3 13:25:50 EST 2009 # expires at: Fri Mar 2 13:25:50 EST 2012 # fingerprint: 66:D2:B7:8E:03:DD:BF:24:4D:A1:D8:EA:8E:6F:8B:80 # Subject's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY # Issuer's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY - Peer's certificate is trusted - Version: TLS1.0 - Key Exchange: RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Handshake was completed - Simple Client Mode: ^C

1 0

Re: (ITS#5990) Segmentation Fault with slapd with two olcSyncrepl directives in the config database
by hyc＠symas.com 04 Mar '09

04 Mar '09

crispy(a)cluenet.org wrote: > Full_Name: Chris Breneman > Version: 2.4.15 > OS: Debian Lenny > URL: > Submission from: (NULL) (207.38.203.80) > > > Using this configuration on a replication consumer, it segfaults almost > immediately, and on startup. > === ./slapd.d/cn=config/olcDatabase={0}config.ldif === > dn: olcDatabase={0}config > objectClass: olcDatabaseConfig > olcDatabase: {0}config > olcAccess: {0}to * by * none > olcAddContentAcl: TRUE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcRootDN: cn=config > olcRootPW:: XXXXXXXXXXX > olcMonitoring: FALSE > structuralObjectClass: olcDatabaseConfig > entryUUID: 410b0970-9d47-102d-8854-57b95f7e164c > creatorsName: cn=config > createTimestamp: 20090304203158Z > olcSyncrepl: {0}rid=3 provider=ldap://ldap.cluenet.org type=refreshAndPersist > interval=00:00:01:00 retry="60 10 300 +" searchbase="cn=schema,cn=config" bin > dmethod=simple binddn="cn=replicator,dc=cluenet,dc=org" credentials="xxxxxxxx > xxxxxxxxx" starttls=critical tls_cacert=/etc/ssl/certs/Cluenet.pem tls_reqcer > t=demand > olcSyncrepl: {1}rid=4 provider=ldap://ldap.cluenet.org type=refreshAndPersist > interval=00:00:01:00 retry="60 10 300 +" searchbase="olcDatabase={0}config,cn > =config" attrs=olcAccess bindmethod=simple binddn="cn=replicator,dc=cluenet,d > c=org" credentials="xxxxxxxxxxxxxxxxx" starttls=critical tls_cacert=/etc/ssl/ > certs/Cluenet.pem tls_reqcert=demand > entryCSN: 20090304203402.651594Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20090304203402Z This replication config is not currently supported. Fractional replication means the consumer gets a subset of the provider's attributes. But it also means that the consumer can *only* have that subset. Here, cn=config needs all of its attributes in order to function, but the consumer code will attempt to delete the non-replicated ones because they aren't part of the info received from the provider. -- -- 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#5990) Segmentation Fault with slapd with two olcSyncrepl directives in the config database
by crispy＠cluenet.org 04 Mar '09

04 Mar '09

Full_Name: Chris Breneman Version: 2.4.15 OS: Debian Lenny URL: Submission from: (NULL) (207.38.203.80) Using this configuration on a replication consumer, it segfaults almost immediately, and on startup. Config (standard schema files left out): === ./slapd.d/cn=config.ldif === dn: cn=config objectClass: olcGlobal cn: config olcConfigFile: /home/slapd/slapd.conf.skel olcConfigDir: /home/slapd/usr/etc/openldap/slapd.d olcArgsFile: /home/slapd/usr/var/run/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcLocalSSF: 71 olcPidFile: /home/slapd/usr/var/run/slapd.pid olcReadOnly: FALSE olcSaslSecProps: noplain,noanonymous olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCRLCheck: none olcTLSVerifyClient: never olcToolThreads: 1 structuralObjectClass: olcGlobal entryUUID: 410a9404-9d47-102d-884d-57b95f7e164c creatorsName: cn=config createTimestamp: 20090304203158Z entryCSN: 20090304203158.642980Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090304203158Z === ./slapd.d/cn=config/olcDatabase={-1}frontend.ldif === dn: olcDatabase={-1}frontend objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 410b05ba-9d47-102d-8853-57b95f7e164c creatorsName: cn=config createTimestamp: 20090304203158Z entryCSN: 20090304203158.642980Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090304203158Z === ./slapd.d/cn=config/olcDatabase={0}config.ldif === dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcRootPW:: XXXXXXXXXXX olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 410b0970-9d47-102d-8854-57b95f7e164c creatorsName: cn=config createTimestamp: 20090304203158Z olcSyncrepl: {0}rid=3 provider=ldap://ldap.cluenet.org type=refreshAndPersist interval=00:00:01:00 retry="60 10 300 +" searchbase="cn=schema,cn=config" bin dmethod=simple binddn="cn=replicator,dc=cluenet,dc=org" credentials="xxxxxxxx xxxxxxxxx" starttls=critical tls_cacert=/etc/ssl/certs/Cluenet.pem tls_reqcer t=demand olcSyncrepl: {1}rid=4 provider=ldap://ldap.cluenet.org type=refreshAndPersist interval=00:00:01:00 retry="60 10 300 +" searchbase="olcDatabase={0}config,cn =config" attrs=olcAccess bindmethod=simple binddn="cn=replicator,dc=cluenet,d c=org" credentials="xxxxxxxxxxxxxxxxx" starttls=critical tls_cacert=/etc/ssl/ certs/Cluenet.pem tls_reqcert=demand entryCSN: 20090304203402.651594Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090304203402Z Backtrace: #0 0x0805a0e7 in config_add_internal (cfb=0x8207ba0, e=0x8fe5554, ca=0xb68fc568, rs=0xb68fd974, renum=0xb68fd6e0, op=0xb68fdd24) at bconfig.c:4521 #1 0x0805a9c8 in config_back_add (op=0xb68fdd24, rs=0xb68fd974) at bconfig.c:4730 #2 0x080dda6c in syncrepl_entry (si=0x900bd08, op=0xb68fdd24, entry=0x8fe5554, modlist=0xb68fdb38, syncstate=1, syncUUID=0xb68fdb90, syncCSN=0x0) at syncrepl.c:2153 #3 0x080d9622 in do_syncrep2 (op=0xb68fdd24, si=0x900bd08) at syncrepl.c:890 #4 0x080daf2c in do_syncrepl (ctx=0xb68fe210, arg=0x900c008) at syncrepl.c:1333 #5 0x0806cf10 in connection_read_thread (ctx=0xb68fe210, argv=0xd) at connection.c:1225 #6 0x0816ba54 in ldap_int_thread_pool_wrapper (xpool=0x8fccf08) at tpool.c:663 #7 0xb7e4bf3b in start_thread () from /lib/libpthread.so.0 #8 0xb7be0bee in clone () from /lib/libc.so.6 Last lines with -d -1: syncrepl_entry: rid=003 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=003 inserted UUID 3d9f90aa-9ba6-102d-9a95-995804f089ee => access_allowed: search access to "cn=schema,cn=config" "entry" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) => test_filter EQUALITY => access_allowed: search access to "cn=schema,cn=config" "entryUUID" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 5 => test_filter EQUALITY => access_allowed: search access to "cn={0}core,cn=schema,cn=config" "entryUUID" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 5 => test_filter EQUALITY => access_allowed: search access to "cn={1}cosine,cn=schema,cn=config" "entryUUID" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 5 => test_filter EQUALITY => access_allowed: search access to "cn={2}nis,cn=schema,cn=config" "entryUUID" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 5 => test_filter EQUALITY => access_allowed: search access to "cn={3}inetorgperson,cn=schema,cn=config" "entryUUID" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 5 send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" syncrepl_entry: rid=003 be_search (0) syncrepl_entry: rid=003 cn=schema,cn=config => access_allowed: add access to "cn=schema,cn=config" "entry" requested <= root access granted => access_allowed: add access granted by manage(=mwrscxd) <= acl_access_allowed: granted to database root => access_allowed: add access to "olcDatabase={0}config,cn=config" "children" requested <= root access granted => access_allowed: add access granted by manage(=mwrscxd) Segmentation fault (core dumped)

1 0

Re: (ITS#5989) slapd-ldap(5) idassert-bind missing starttls
by ando＠sys-net.it 04 Mar '09

04 Mar '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24/HEAD > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > In the slapd-ldap man page, the section on idassert-bind is missing the fact > that you can configure: > > starttls=no|yes|critical > > while listing all the other tls related keywords you can configure. tls_protocol_min is missing as well. Also, I note the values of starttls should be changed from "no,yes,critical" to "no,try,yes" (with "critical" synonym of "yes"), to remove the false security perception given by the current semantics of "yes". The change would create minor backward compatibility issues, but no security concern, since the meaning of "yes" would be promoted from optional to required. Incautious users that still use "yes" would just need to change it to "try" to restore the previous unsafe behavior. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5989) slapd-ldap(5) idassert-bind missing starttls
by quanah＠OpenLDAP.org 04 Mar '09

04 Mar '09

Full_Name: Quanah Gibson-Mount Version: RE24/HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) In the slapd-ldap man page, the section on idassert-bind is missing the fact that you can configure: starttls=no|yes|critical while listing all the other tls related keywords you can configure.

1 0

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by mariusp44＠gmail.com 04 Mar '09

04 Mar '09

Thanks for your help. Would you be able to email your Makefile that you generated for gcc 4.0.3 on Solaris/SPARC? I am seriously missing something. I installed lated Sun Studio 12 and compiled with it and it's the same problem. /M. On Tue, Mar 3, 2009 at 2:49 PM, <hyc(a)symas.com> wrote: > mariusp44(a)gmail.com wrote: >> as I have pointed out in earlier post not only it doesn't work when I >> compile it myself but also the one that was downloaded form >> sunfreeware.com. It is not possible to tell what version of gcc was >> used to compile openldap that is distributed but explanation that it >> doesn't work because of compiler bug seems to me highly unlikely. >> Unless you can specifically point to which bug in gcc on SPARC >> contributes to this erratic behaviour of openldap. > > It's not our responsibility to do your legwork for you. You can easily email > the maintainers at sunfreeware.com and ask them. Since they currently host gcc > 3.4.6 on their site it's a safe bet they're still using gcc 3.4.x overall. > > Fyi, I have just now built the 2.4.15 source using gcc 4.0.3 on SPARC/Solaris > and all of the hash mechanisms work fine. I don't have a gcc 3.x build handy > on my system, nor do I see any reason to install a known-bad compiler just to > further demonstrate what has already been plainly documented by other folks. >> >> Either way, thanks for comments. >> >> /M. >> >> On Mon, Mar 2, 2009 at 5:56 PM,<hyc(a)symas.com> wrote: >>> ando(a)sys-net.it wrote: >>>> mariusp44(a)gmail.com wrote: >>>>> I have just compiled and tested 2.4.15 and result is same: cleartext, >>>>> md5 and sha works, smd5, ssha and crypt doesn't. >>>>> >>>>> Solaris 10 SPARC latest, gcc 3.4.3, Berkeley DB 4.7.25, opessl 0.9.8j. >>>> I have no chance to test on that arch. You should figure our why those >>>> hashes are not supported. Did you enable crypt (--enable-crypt)? >>> gcc 3.4.3 was released November 4 2004 http://gcc.gnu.org/gcc-3.4/ >>> >>> and is known to have many bugs. It's also already known that old gcc releases >>> have other problems on Sparc. (E.g. ITS#5875.) >>> >>> Please use a working compiler. >>> >>> As a workaround, recompile the offending functions with optimization disabled. >>> That usually helps in cases like this. >>> >>> There is no bug in OpenLDAP Software here, this ITS will be closed. >>> >>> -- >>> -- Howard Chu >>> CTO, Symas Corp. http://www.symas.com >>> Director, Highland Sun http://highlandsun.com/hyc/ >>> Chief Architect, OpenLDAP http://www.openldap.org/project/ >>> >>> >>> >> >> >> > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > >

1 0

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by hyc＠symas.com 03 Mar '09

03 Mar '09

mariusp44(a)gmail.com wrote: > as I have pointed out in earlier post not only it doesn't work when I > compile it myself but also the one that was downloaded form > sunfreeware.com. It is not possible to tell what version of gcc was > used to compile openldap that is distributed but explanation that it > doesn't work because of compiler bug seems to me highly unlikely. > Unless you can specifically point to which bug in gcc on SPARC > contributes to this erratic behaviour of openldap. It's not our responsibility to do your legwork for you. You can easily email the maintainers at sunfreeware.com and ask them. Since they currently host gcc 3.4.6 on their site it's a safe bet they're still using gcc 3.4.x overall. Fyi, I have just now built the 2.4.15 source using gcc 4.0.3 on SPARC/Solaris and all of the hash mechanisms work fine. I don't have a gcc 3.x build handy on my system, nor do I see any reason to install a known-bad compiler just to further demonstrate what has already been plainly documented by other folks. > > Either way, thanks for comments. > > /M. > > On Mon, Mar 2, 2009 at 5:56 PM,<hyc(a)symas.com> wrote: >> ando(a)sys-net.it wrote: >>> mariusp44(a)gmail.com wrote: >>>> I have just compiled and tested 2.4.15 and result is same: cleartext, >>>> md5 and sha works, smd5, ssha and crypt doesn't. >>>> >>>> Solaris 10 SPARC latest, gcc 3.4.3, Berkeley DB 4.7.25, opessl 0.9.8j. >>> I have no chance to test on that arch. You should figure our why those >>> hashes are not supported. Did you enable crypt (--enable-crypt)? >> gcc 3.4.3 was released November 4 2004 http://gcc.gnu.org/gcc-3.4/ >> >> and is known to have many bugs. It's also already known that old gcc releases >> have other problems on Sparc. (E.g. ITS#5875.) >> >> Please use a working compiler. >> >> As a workaround, recompile the offending functions with optimization disabled. >> That usually helps in cases like this. >> >> There is no bug in OpenLDAP Software here, this ITS will be closed. >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> >> >> > > > -- -- 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

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