openldap-bugs June 2012

openldap-bugs@openldap.org

29 participants
84 discussions

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 13 Jun '12

13 Jun '12

This is a cryptographically signed message in MIME format. --------------ms060502000406060901070508 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable fumiyas(a)osstech.jp wrote: > At Mon, 11 Jun 2012 21:30:18 +0200, > Michael Str=F6der wrote: >>>> Do I have to tweak the Makefile? >>> >>> Add -fPIC to $CCFLAGS in Makefile if you are using GCC. >> >> I hoped that this would not be necessary and the module work include s= omething >> detected via autoconf before. >=20 > Can you try the following Makefile? >=20 > https://gist.github.com/2915450 This works much better. And now the bind after Password Modify ext. op. also works! ??? Could you please submit a patch with your recent Makefile? Ciao, Michael. --------------ms060502000406060901070508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNjEzMDczMDAzWjAjBgkq hkiG9w0BCQQxFgQUrungi4tWis9D11T/hGg7NPK0+MQwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEALHbs0wAx3r3but/uiE5O3lKc+27I4VhWvGrTxD8CHDtE8Xk4xA7CNiHjMMtoYWRWrSKw VWMXXhEXwNN6ePT4CIu4UgBpvh5DsVnaOeRHspjv0+V1Dy0H0QmptzyEf1pjxhguIv181eRm aZmKatgTBXTxj7aWrm1+N2ozuYXPVUSJCWXa2OcENnYc4Fm7XuAy0LDg0dqnaAxRgSlTQyu0 tEXBz5M7a0YJuCwjVMyf74f3hP/Z90CGIirnk96SKC9UutbYocWlck3F4KQkKhTR8A+Tx/Hv M9EqRvWw7PxRGoRpSSjX7SdkRw0cUw5ZJtZX3UmYohz8Ks0v+8krldsgMgAAAAAAAA== --------------ms060502000406060901070508--

1 0

(ITS#7303) bdb/hdb search checks aliases unnecessarily
by hyc＠OpenLDAP.org 12 Jun '12

12 Jun '12

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.19.96.193) Submitted by: hyc If a search request has derefSearching set in the alias deref option, the search_aliases() function walks thru a (potentially) large number of entries checking to see if they are aliases, even if the objectclass index shows there are no alias entries in the database. It should exit early instead. The bug is also present to a lesser degree in back-mdb; the back-mdb version of search_aliases() would only do a single unneeded entry lookup.

1 0

(ITS#7302) mdb segfault when renaming entry
by quanah＠OpenLDAP.org 12 Jun '12

12 Jun '12

Full_Name: Quanah Gibson-Mount Version: 2.4.31 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) Got the following segfault in mdb when renaming entry X to the same name as a previously deleted entry Y. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f076d5c6700 (LWP 15510)] 0x00007f1b6ea5190b in mdb_cursor_del (mc=0x2e09a08, flags=0) at ./../../../libraries/libmdb/mdb.c:4516 4516 ./../../../libraries/libmdb/mdb.c: No such file or directory. in ./../../../libraries/libmdb/mdb.c (gdb) thr apply all bt full Thread 5 (Thread 0x7f076ddc7700 (LWP 15509)): #0 0x00007f1b7261c2d3 in epoll_wait () from /lib/libc.so.6 No symbol table info available. #1 0x00000000004395d9 in slapd_daemon_task (ptr=0x2715d00) at daemon.c:2540 ns = 1 at = 0 nfds = 8 revents = 0x287e000 tvp = 0x7f076ddc4da0 cat = {tv_sec = 1339538180, tv_usec = 0} i = 1 nwriters = 0 now = 1339537971 tv = {tv_sec = 209, tv_usec = 0} tdelta = 1 rtask = 0x2d81950 l = 3 last_idle_check = 1339537880 ebadf = 0 tid = 0 #2 0x00007f1b728be9ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #3 0x00007f1b7261bcdd in clone () from /lib/libc.so.6 No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available. Thread 4 (Thread 0x7f076d5c6700 (LWP 15510)): #0 0x00007f1b6ea5190b in mdb_cursor_del (mc=0x2e09a08, flags=0) at ./../../../libraries/libmdb/mdb.c:4516 leaf = 0x130000004c rc = 0 #1 0x00007f1b6ea519b4 in mdb_cursor_del (mc=0x2e09880, flags=0) at ./../../../libraries/libmdb/mdb.c:4523 leaf = 0x50baacc rc = 0 #2 0x00007f1b6ea42088 in mdb_dn2id_delete (op=0x2c0fc00, mc=0x2e09880, id=75) at dn2id.c:235 key = {mv_size = 8, mv_data = 0x7f076d5c5468} rc = 0 #3 0x00007f1b6ea31abc in mdb_delete (op=0x2c0fc00, rs=0x7f076d5c5a10) at delete.c:336 mdb = 0x2e56000 pdn = {bv_len = 16, bv_val = 0x48e82c2 "dc=zimbra,dc=com"} e = 0x48e8e90 p = 0x48e83f0 manageDSAit = 0 children = 0x2722ec0 entry = 0x2722f00 txn = 0x458c000 mc = 0x2e09880 opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x2e56000}, moi_txn = 0x458c000, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7f076d5c5530 preread_ctrl = 0x0 ctrls = {0x0, 0x151f55373c8e5d00, 0x0, 0x48e8308, 0x7f076d5c5570, 0x27fb280} num_ctrls = 0 parent_is_glue = 0 parent_is_leaf = 0 __PRETTY_FUNCTION__ = "mdb_delete" #4 0x00000000004d4b08 in overlay_op_walk (op=0x2c0fc00, rs=0x7f076d5c5a10, which=op_delete, oi=0x2c62d20, on=0x0) at backover.c:671 func = 0x7f1b6ec60cf8 rc = 32768 #5 0x00000000004d4d46 in over_op_func (op=0x2c0fc00, rs=0x7f076d5c5a10, which=op_delete) at backover.c:723 oi = 0x2c62d20 on = 0x2c62780 be = 0x27589c0 db = {bd_info = 0x7f1b6ec60ca0, bd_self = 0x27589c0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 2312, 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, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x2be7900, be_nsuffix = 0x2be78c0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x2d5eda0 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x2d5ed80 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, 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 = 0x0, be_acl = 0x2c6f6c0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x456f610, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7f1b6ec60aa0, be_private = 0x2e56000, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x48e82e0, sc_response = 0x4d3840 <over_back_response>, sc_cleanup = 0, sc_private = 0x2c62d20} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #6 0x00000000004d4f2f in over_op_delete (op=0x2c0fc00, rs=0x7f076d5c5a10) at backover.c:780 No locals. #7 0x000000000046149c in fe_op_delete (op=0x2c0fc00, rs=0x7f076d5c5a10) at delete.c:174 org_req_dn = {bv_len = 0, bv_val = 0x0} org_ndn = {bv_len = 0, bv_val = 0x0} org_managedsait = 41923200 org_req_ndn = {bv_len = 0, bv_val = 0x0} org_dn = {bv_len = 0, bv_val = 0x0} repl_user = 0 pdn = {bv_len = 0, bv_val = 0x0} op_be = 0x27589c0 bd = 0x75fdc0 #8 0x000000000046110f in do_delete (op=0x2c0fc00, rs=0x7f076d5c5a10) at delete.c:95 dn = {bv_len = 26, bv_val = 0x4577da5 "ou=people,dc=zimbra,dc=com"} #9 0x000000000043d8c9 in connection_operation (ctx=0x7f076d5c5b50, arg_v=0x2c0fc00) at connection.c:1150 rc = 80 cancel = 0 op = 0x2c0fc00 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = -30798, sr_matched = 0x0, sr_text = 0x0, 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_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 74 opidx = SLAP_OP_DELETE conn = 0x2f6b440 memctx = 0x27fb280 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #10 0x000000000043de67 in connection_read_thread (ctx=0x7f076d5c5b50, argv=0x13) at connection.c:1286 rc = 0 cri = {op = 0x2c0fc00, func = 0, arg = 0x0, ctx = 0x7f076d5c5b50, nullop = 0} s = 19 #11 0x00007f1b73db5cc9 in ldap_int_thread_pool_wrapper (xpool=0x273c1c0) at tpool.c:688 pool = 0x273c1c0 task = 0x4576680 work_list = 0x273c258 ctx = {ltu_id = 139669876270848, ltu_key = {{ltk_key = 0x43d429, ltk_data = 0x2c78200, ltk_free = 0x43d26d <conn_counter_destroy>}, {ltk_key = 0x4b388f, ltk_data = 0x27fb280, ltk_free = 0x4b36b4 <slap_sl_mem_destroy>}, {ltk_key = 0x4591ad, ltk_data = 0x0, ltk_free = 0x459100 <slap_op_q_destroy>}, {ltk_key = 0x45e6000, ltk_data = 0x457e000, ltk_free = 0x7f1b6ea4492b <mdb_reader_free>}, {ltk_key = 0x7f1b6ea384d9, ltk_data = 0x49e8000, ltk_free = 0x7f1b6ea38491 <scope_chunk_free>}, {ltk_key = 0x4daa000, ltk_data = 0x4581400, ltk_free = 0x7f1b6ea4492b <mdb_reader_free>}, {ltk_key = 0x7f1b6ea3aaf4, ltk_data = 0x65f2000, ltk_free = 0x7f1b6ea3aad1 <search_stack_free>}, { ltk_key = 0x0, ltk_data = 0x4579200, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 854 hash = 2665057110 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #12 0x00007f1b728be9ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #13 0x00007f1b7261bcdd in clone () from /lib/libc.so.6 No symbol table info available. #14 0x0000000000000000 in ?? () No symbol table info available. Thread 3 (Thread 0x7ef36cdc3700 (LWP 15671)): #0 0x00007f1b728c385c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007f1b73db72be in ldap_pvt_thread_cond_wait (cond=0x273c1f0, mutex=0x273c1c8) at thr_posix.c:277 No locals. #2 0x00007f1b73db5c22 in ldap_int_thread_pool_wrapper (xpool=0x273c1c0) at tpool.c:675 pool = 0x273c1c0 task = 0x0 work_list = 0x273c258 ctx = {ltu_id = 139583968524032, ltu_key = {{ltk_key = 0x43d429, ltk_data = 0x2c04400, ltk_free = 0x43d26d <conn_counter_destroy>}, {ltk_key = 0x4b388f, ltk_data = 0x2bc1200, ltk_free = 0x4b36b4 <slap_sl_mem_destroy>}, {ltk_key = 0x4591ad, ltk_data = 0x2c0e000, ltk_free = 0x459100 <slap_op_q_destroy>}, {ltk_key = 0x4daa000, ltk_data = 0x4582e00, ltk_free = 0x7f1b6ea4492b <mdb_reader_free>}, {ltk_key = 0x7f1b6ea384d9, ltk_data = 0x51ee000, ltk_free = 0x7f1b6ea38491 <scope_chunk_free>}, {ltk_key = 0x45e6000, ltk_data = 0x4586200, ltk_free = 0x7f1b6ea4492b <mdb_reader_free>}, {ltk_key = 0x7f1b6ea3aaf4, ltk_data = 0x55ee000, ltk_free = 0x7f1b6ea3aad1 <search_stack_free>}, { ltk_key = 0x0, ltk_data = 0x457a400, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 464 hash = 81037776 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f1b728be9ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007f1b7261bcdd in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 2 (Thread 0x7ef36c5c2700 (LWP 15672)): #0 0x00007f1b728c385c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007f1b73db72be in ldap_pvt_thread_cond_wait (cond=0x273c1f0, mutex=0x273c1c8) at thr_posix.c:277 No locals. #2 0x00007f1b73db5c22 in ldap_int_thread_pool_wrapper (xpool=0x273c1c0) at tpool.c:675 pool = 0x273c1c0 task = 0x0 work_list = 0x273c258 ctx = {ltu_id = 139583960131328, ltu_key = {{ltk_key = 0x43d429, ltk_data = 0x2c04500, ltk_free = 0x43d26d <conn_counter_destroy>}, {ltk_key = 0x4b388f, ltk_data = 0x2bc1300, ltk_free = 0x4b36b4 <slap_sl_mem_destroy>}, {ltk_key = 0x4591ad, ltk_data = 0x2c0e800, ltk_free = 0x459100 <slap_op_q_destroy>}, {ltk_key = 0x45e6000, ltk_data = 0x458e000, ltk_free = 0x7f1b6ea4492b <mdb_reader_free>}, {ltk_key = 0x7f1b6ea384d9, ltk_data = 0x75f6000, ltk_free = 0x7f1b6ea38491 <scope_chunk_free>}, {ltk_key = 0x7f1b6ea3aaf4, ltk_data = 0x78f6000, ltk_free = 0x7f1b6ea3aad1 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x457b600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = 0x0 i = 32 keyslot = 576 hash = 1606749760 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f1b728be9ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007f1b7261bcdd in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 1 (Thread 0x7f1b744e4720 (LWP 15508)): #0 0x00007f1b728c003d in pthread_join () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007f1b73db71ff in ldap_pvt_thread_join (thread=139669884663552, thread_return=0x0) at thr_posix.c:197 No locals. #2 0x000000000043a7ff in slapd_daemon () at daemon.c:2930 i = 0 rc = 0 #3 0x0000000000416d7f in main (argc=9, argv=0x7fffc49fe378) at main.c:1012 i = 9 no_detach = 0 rc = 0 urls = 0x271a000 "ldap://zre-ldap003.eng.vmware.com:389 ldapi:///" username = 0x2714020 "root" groupname = 0x0 sandbox = 0x0 syslogUser = 128 pid = 0 waitfds = {10, 11} g_argc = 9 g_argv = 0x7fffc49fe378 configfile = 0x0 configdir = 0x2712040 "/opt/zimbra/data/ldap/config" serverName = 0x7fffc49ffd92 "slapd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x4f9928 "" l = 139755887037800 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = 0 __PRETTY_FUNCTION__ = "main"

1 0

Re: (ITS#7301) Improve DNS SRV support in OpenLDAP
by quanah＠zimbra.com 12 Jun '12

12 Jun '12

--On Tuesday, June 12, 2012 11:25 AM -0700 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.31 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.108.184.39) >> >> >> LDAP URI handling via SRV records is not in the library. In >> particular, an OpenLDAP library client that specifies a >> (correctly formed or otherwise) LDAP URI of the form: >> >> ldap:///dc=example,dc=com/ >> >> will not be connected to the LDAP servers found in the SRV records >> for _ldap._tcp.example.com. That code is only in the ldapsearch(1) >> and related tools. >> >> The existence of the low-level support functions in the library is >> of no help to users who want to specify URIs that resolve to the >> underlying LDAP servers via SRV records. > > Tough luck. Currently ldap:/// means localhost. Changing the library > behavior here would be a pretty drastic incompatible change and would > break pretty much all existing software. This has been discussed and shot > down before, and rejecting this request is the only correct outcome for > this ITS. What about an ldap_set_option() parameter for enabling it? >> Also, the SRV -> host:port list lookup code that is in the library >> (but not tied to the libraries connection establishment code) is >> broken, it ignores the weight and priority which is not a good >> idea, the published SRV priorities and weights must not be ignored. > > priorities/weights are already the subject of ITS#7027. Ok, so will 7027 be committed, since there is a patch already provided? ;) The discussion around this started at <http://archives.neohapsis.com/archives/postfix/2012-06/0183.html> --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7301) Improve DNS SRV support in OpenLDAP
by hyc＠symas.com 12 Jun '12

12 Jun '12

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.31 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.108.184.39) > > > LDAP URI handling via SRV records is not in the library. In > particular, an OpenLDAP library client that specifies a > (correctly formed or otherwise) LDAP URI of the form: > > ldap:///dc=example,dc=com/ > > will not be connected to the LDAP servers found in the SRV records > for _ldap._tcp.example.com. That code is only in the ldapsearch(1) > and related tools. > > The existence of the low-level support functions in the library is > of no help to users who want to specify URIs that resolve to the > underlying LDAP servers via SRV records. Tough luck. Currently ldap:/// means localhost. Changing the library behavior here would be a pretty drastic incompatible change and would break pretty much all existing software. This has been discussed and shot down before, and rejecting this request is the only correct outcome for this ITS. > Also, the SRV -> host:port list lookup code that is in the library > (but not tied to the libraries connection establishment code) is > broken, it ignores the weight and priority which is not a good > idea, the published SRV priorities and weights must not be ignored. priorities/weights are already the subject of ITS#7027. -- -- 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#7301) Improve DNS SRV support in OpenLDAP
by quanah＠zimbra.com 12 Jun '12

12 Jun '12

--On Tuesday, June 12, 2012 6:09 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.31 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.108.184.39) Note: Filed on behalf of the Postfix authors. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7301) Improve DNS SRV support in OpenLDAP
by quanah＠OpenLDAP.org 12 Jun '12

12 Jun '12

Full_Name: Quanah Gibson-Mount Version: 2.4.31 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) LDAP URI handling via SRV records is not in the library. In particular, an OpenLDAP library client that specifies a (correctly formed or otherwise) LDAP URI of the form: ldap:///dc=example,dc=com/ will not be connected to the LDAP servers found in the SRV records for _ldap._tcp.example.com. That code is only in the ldapsearch(1) and related tools. The existence of the low-level support functions in the library is of no help to users who want to specify URIs that resolve to the underlying LDAP servers via SRV records. Also, the SRV -> host:port list lookup code that is in the library (but not tied to the libraries connection establishment code) is broken, it ignores the weight and priority which is not a good idea, the published SRV priorities and weights must not be ignored.

1 0

Re: (ITS#7300) ACLs
by quanah＠zimbra.com 12 Jun '12

12 Jun '12

--On Tuesday, June 12, 2012 5:57 PM +0000 andre.cardinal(a)bell.ca wrote: > Full_Name: Andre Cardinal > Version: 2.4.30 > OS: Red Hat 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (206.47.249.246) This is not a bug report. This ITS will be closed. If you have usage questions, please use the openldap-technical(a)openldap.org mailing list. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7300) ACLs
by andre.cardinal＠bell.ca 12 Jun '12

12 Jun '12

Full_Name: Andre Cardinal Version: 2.4.30 OS: Red Hat 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.47.249.246) I have the following ACL set up in slapd.conf access to dn.base="" by * read access to attrs=GCSRAAllow,GCSRAGroup,GCSRASubjectdn,userpassword by dn="cn=ProvAdmin,ou=GCSRAAdmin,o=gc,c=ca" write by dn="cn=gateAdmin1,ou=GCSRAAdmin,o=gc,c=ca" read by dn="cn=gateAdmin2,ou=GCSRAAdmin,o=gc,c=ca" read slapacl -f /usr/local/etc/openldap/slapd.conf -D cn=provadmin,ou=gcsraadmin,o=gc,c=ca -b ou=gcsrausers,o=gc,c=ca gcsraallow authcDN: "cn=provadmin,ou=gcsraadmin,o=gc,c=ca" GCSRAAllow: write(=wrscxd) However any modify I try returns: modifying entry "GCSRASubjectDN=my636-test,ou=GCSRAUsers,o=gc,c=ca" ldap_modify: Insufficient access (50)

1 0

(ITS#7299) Memory leaks when using ldapmodify to add members to groupOfNames objectclass
by jsynacek＠redhat.com 12 Jun '12

12 Jun '12

Full_Name: Jan Synacek Version: git (c73ec15) OS: linux-fedora17 URL: http://jsynacek.fedorapeople.org/openldap/leak/openldap-mmr-leak.tar.gz Submission from: (NULL) (209.132.186.34) I'm using a 2-node mmr setup on my local machine - configuration files and 'uploader' scripts are provided in the archive. 1) I have the two nodes running. 2) Execute run.sh (only a wrapper for ldapusradm.sh) and start monitoring slapd's memory usage. 3) After some time (at about 2k users on my system), slapd consumes a large amount of memory which is still growing Note that not using ldapmodify to add members to 'cn=users,dc=yes,dc=my', but using it e.g. for modifying each user's email, does NOT result in any memory leakage. I have also created a massif output using valgrind's massif tool: http://jsynacek.fedorapeople.org/openldap/leak/massif.out.17906 I found a very similar bug (#7292), but I'm not sure if it's related.

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2012