openldap-bugs September 2007

openldap-bugs@openldap.org

33 participants
179 discussions

Re: (ITS#4860) Sets' enhancement
by jclarke＠linagora.com 13 Sep '07

13 Sep '07

This is a multi-part message in MIME format. --------------070701020707050408020200 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit jclarke(a)linagora.com a écrit : > ando(a)sys-net.it a écrit : >> raphael.ouazana(a)linagora.com wrote: >> >>> It seems OK with HEAD, but only if I revert this patch: >>> http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/sets.c.diff?r1=1.28.… >>> >>> With this patch, I get a segfault. >> I have just committed a cleanup of the slap_set_join() function that >> should be consistent. It should fix a leak in case of '&' on >> overlapping sets, and consistently handle memory. Can you please test >> it and point out failures? If you get any, please post the rules that >> cause them, as those I could design worked fine (tested with valgrind). > > I am one of Raphael's colleagues, answering on his behalf. > > I've tested your latest commit, and most of our tests now run great. > However, I still get a segault with the two rules below. Please note > that this segfault only happens when *both* rules are present, each one > by itself does not cause a segfault : > >> access to dn.sub="ou=Affectations,dc=linagora,dc=org" attrs=sigleAbrege,labeledURI,mailRoutingAddress,telephoneNumber,facsimileTelephoneNumber,entry >> by set="([ldap:///] + (([ldap:///] + ((([ldap:///] + this + [??base?(|(objectClass=affectationLiee)(objectClass=affectationSemiLibre))])/entryDN)/-0) + [??base?])/responsable) + [??base?(|(administrateurResponsable=] + user + [)(administrateur=] + user + [)(membre=] + user + [))])/entryDN" +rscx >> by * break > >> access to dn.sub="ou=Affectations,dc=linagora,dc=org" attrs=domaineMessagerie,finValidite,identifiantHarpegeStructure,responsable,objectClass,entry >> by set="[ldap:///] + (((([ldap:///] + this + [??base?(|(objectClass=affectationLiee)(objectClass=affectationSemiLibre))])/entryDN)/-100) & ((([ldap:///] + user + [??base?(objectClass=personnel)])/entryDN)/-100)) + [??sub?entryDN=] + user/entryDN" +rscx >> by * break > > I'm afraid that we use quite a few specific schemas so you may not be > able to reproduce this easily. However, I hope these rules will enable > you to determine the problematic case. If necessary, I could prepare a > data and schema extract to reproduce the problem. Oh, and I forgot, please find attached the output from valgrind when running these rules. Jon -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com --------------070701020707050408020200 Content-Type: text/plain; name="valgrind.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="valgrind.txt" => dn: [5] ou=affectations,dc=linagora,dc=fr => acl_get: [5] matched => dn: [6] ou=affectations,dc=linagora,dc=fr => acl_get: [6] matched => acl_get: [6] attr objectClass => acl_mask: access to entry "ou=4,ou=0132,ou=0126,ou=SG,ou=UPMC,ou=Affectations,dc=linagora,dc=fr", attr "objectClass" requested => acl_mask: to value by "uid=test,ou=machines,dc=linagora,dc=fr", (=0) <= check a_set_pat: [ldap:///] + (((([ldap:///] + this + [??base?(|(objectClass=affectationLiee)(objectClass=affectationSemiLibre))])/entryDN)/-100) & ((([ldap:///] + user + [??base?(objectClass=personnel)])/entryDN)/-100)) + [??sub?entryDN=] + user/entryDN => access_allowed: search access to "ou=4,ou=0132,ou=0126,ou=SG,ou=UPMC,ou=Affectations,dc=linagora,dc=fr" "entry" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) => access_allowed: search access to "ou=4,ou=0132,ou=0126,ou=SG,ou=UPMC,ou=Affectations,dc=linagora,dc=fr" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) => access_allowed: search access to "ou=4,ou=0132,ou=0126,ou=SG,ou=UPMC,ou=Affectations,dc=linagora,dc=fr" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) => access_allowed: search access to "uid=test,ou=Machines,dc=linagora,dc=fr" "entry" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) => access_allowed: search access to "uid=test,ou=Machines,dc=linagora,dc=fr" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) ==28687== ==28687== Thread 3: ==28687== Invalid read of size 4 ==28687== at 0x80AE729: slap_set_size (sets.c:34) ==28687== by 0x80AE921: slap_set_join (sets.c:269) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== by 0x80679F5: fe_op_search (search.c:368) ==28687== Address 0x7226C34 is 4 bytes inside a block of size 24 free'd ==28687== at 0x402123A: free (vg_replace_malloc.c:233) ==28687== by 0x80AE892: slap_set_dispose (sets.c:74) ==28687== by 0x80AE8E8: slap_set_join (sets.c:354) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== ==28687== Invalid read of size 4 ==28687== at 0x80AE735: slap_set_size (sets.c:34) ==28687== by 0x80AE921: slap_set_join (sets.c:269) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== by 0x80679F5: fe_op_search (search.c:368) ==28687== Address 0x7226C3C is 12 bytes inside a block of size 24 free'd ==28687== at 0x402123A: free (vg_replace_malloc.c:233) ==28687== by 0x80AE892: slap_set_dispose (sets.c:74) ==28687== by 0x80AE8E8: slap_set_join (sets.c:354) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== ==28687== Invalid read of size 4 ==28687== at 0x80AEC5E: slap_set_join (sets.c:298) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== by 0x80679F5: fe_op_search (search.c:368) ==28687== by 0x80C7CA0: overlay_op_walk (backover.c:652) ==28687== Address 0x7226C34 is 4 bytes inside a block of size 24 free'd ==28687== at 0x402123A: free (vg_replace_malloc.c:233) ==28687== by 0x80AE892: slap_set_dispose (sets.c:74) ==28687== by 0x80AE8E8: slap_set_join (sets.c:354) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== ==28687== Invalid read of size 4 ==28687== at 0x80AEC96: slap_set_join (sets.c:304) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== by 0x80679F5: fe_op_search (search.c:368) ==28687== by 0x80C7CA0: overlay_op_walk (backover.c:652) ==28687== Address 0x7226C30 is 0 bytes inside a block of size 24 free'd ==28687== at 0x402123A: free (vg_replace_malloc.c:233) ==28687== by 0x80AE892: slap_set_dispose (sets.c:74) ==28687== by 0x80AE8E8: slap_set_join (sets.c:354) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== ==28687== Invalid read of size 4 ==28687== at 0x80AEDBD: slap_set_join (sets.c:329) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== by 0x80679F5: fe_op_search (search.c:368) ==28687== by 0x80C7CA0: overlay_op_walk (backover.c:652) ==28687== Address 0x7226C30 is 0 bytes inside a block of size 24 free'd ==28687== at 0x402123A: free (vg_replace_malloc.c:233) ==28687== by 0x80AE892: slap_set_dispose (sets.c:74) ==28687== by 0x80AE8E8: slap_set_join (sets.c:354) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== ==28687== Invalid read of size 4 ==28687== at 0x80AEDC3: slap_set_join (sets.c:329) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== by 0x80679F5: fe_op_search (search.c:368) ==28687== by 0x80C7CA0: overlay_op_walk (backover.c:652) ==28687== Address 0x7226C34 is 4 bytes inside a block of size 24 free'd ==28687== at 0x402123A: free (vg_replace_malloc.c:233) ==28687== by 0x80AE892: slap_set_dispose (sets.c:74) ==28687== by 0x80AE8E8: slap_set_join (sets.c:354) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== ==28687== Invalid read of size 4 ==28687== at 0x80AEDDF: slap_set_join (sets.c:330) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== by 0x80679F5: fe_op_search (search.c:368) ==28687== by 0x80C7CA0: overlay_op_walk (backover.c:652) ==28687== Address 0x7226C30 is 0 bytes inside a block of size 24 free'd ==28687== at 0x402123A: free (vg_replace_malloc.c:233) ==28687== by 0x80AE892: slap_set_dispose (sets.c:74) ==28687== by 0x80AE8E8: slap_set_join (sets.c:354) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== ==28687== Invalid read of size 4 ==28687== at 0x80AED4E: slap_set_join (sets.c:298) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== by 0x80679F5: fe_op_search (search.c:368) ==28687== by 0x80C7CA0: overlay_op_walk (backover.c:652) ==28687== Address 0x7226C3C is 12 bytes inside a block of size 24 free'd ==28687== at 0x402123A: free (vg_replace_malloc.c:233) ==28687== by 0x80AE892: slap_set_dispose (sets.c:74) ==28687== by 0x80AE8E8: slap_set_join (sets.c:354) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== ==28687== Invalid read of size 4 ==28687== at 0x816334F: ber_bvarray_free_x (memory.c:727) ==28687== by 0x80AE892: slap_set_dispose (sets.c:74) ==28687== by 0x80AE8E8: slap_set_join (sets.c:354) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== Address 0x7226C34 is 4 bytes inside a block of size 24 free'd ==28687== at 0x402123A: free (vg_replace_malloc.c:233) ==28687== by 0x80AE892: slap_set_dispose (sets.c:74) ==28687== by 0x80AE8E8: slap_set_join (sets.c:354) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== ==28687== Invalid read of size 4 ==28687== at 0x816335E: ber_bvarray_free_x (memory.c:727) ==28687== by 0x80AE892: slap_set_dispose (sets.c:74) ==28687== by 0x80AE8E8: slap_set_join (sets.c:354) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== Address 0x7226C3C is 12 bytes inside a block of size 24 free'd ==28687== at 0x402123A: free (vg_replace_malloc.c:233) ==28687== by 0x80AE892: slap_set_dispose (sets.c:74) ==28687== by 0x80AE8E8: slap_set_join (sets.c:354) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== ==28687== Invalid read of size 4 ==28687== at 0x8163380: ber_bvarray_free_x (memory.c:731) ==28687== by 0x80AE892: slap_set_dispose (sets.c:74) ==28687== by 0x80AE8E8: slap_set_join (sets.c:354) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== Address 0x7226C34 is 4 bytes inside a block of size 24 free'd ==28687== at 0x402123A: free (vg_replace_malloc.c:233) ==28687== by 0x80AE892: slap_set_dispose (sets.c:74) ==28687== by 0x80AE8E8: slap_set_join (sets.c:354) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== ==28687== Invalid free() / delete / delete[] ==28687== at 0x402123A: free (vg_replace_malloc.c:233) ==28687== by 0x80AE892: slap_set_dispose (sets.c:74) ==28687== by 0x80AE8E8: slap_set_join (sets.c:354) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) ==28687== Address 0x7226C30 is 0 bytes inside a block of size 24 free'd ==28687== at 0x402123A: free (vg_replace_malloc.c:233) ==28687== by 0x80AE892: slap_set_dispose (sets.c:74) ==28687== by 0x80AE8E8: slap_set_join (sets.c:354) ==28687== by 0x80AF1C2: slap_set_filter (sets.c:612) ==28687== by 0x80864C9: acl_match_set (acl.c:2299) ==28687== by 0x8089785: slap_access_allowed (acl.c:1621) ==28687== by 0x808B6C3: fe_access_allowed (acl.c:311) ==28687== by 0x80C892F: over_access_allowed (backover.c:314) ==28687== by 0x80872C3: access_allowed_mask (acl.c:413) ==28687== by 0x8083BCE: test_ava_filter (filterentry.c:545) ==28687== by 0x80843E8: test_filter (filterentry.c:88) ==28687== by 0x80DC90D: bdb_search (search.c:844) <= acl_mask: [1] applying +rscx (stop) <= acl_mask: [1] mask: =rscx => slap_access_allowed: search access granted by =rscx => access_allowed: search access granted by =rscx --------------070701020707050408020200--

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 13 Sep '07

13 Sep '07

> I've tested your latest commit, and most of our tests now run great. > However, I still get a segault with the two rules below. Please note > that this segfault only happens when *both* rules are present, each one > by itself does not cause a segfault : > >> access to dn.sub="ou=Affectations,dc=linagora,dc=org" >> attrs=sigleAbrege,labeledURI,mailRoutingAddress,telephoneNumber,facsimileTelephoneNumber,entry >> by set="([ldap:///] + (([ldap:///] + ((([ldap:///] + this + >> [??base?(|(objectClass=affectationLiee)(objectClass=affectationSemiLibre))])/entryDN)/-0) >> + [??base?])/responsable) + >> [??base?(|(administrateurResponsable=] + user + >> [)(administrateur=] + user + [)(membre=] + user + [))])/entryDN" >> +rscx >> by * break > >> access to dn.sub="ou=Affectations,dc=linagora,dc=org" >> attrs=domaineMessagerie,finValidite,identifiantHarpegeStructure,responsable,objectClass,entry >> by set="[ldap:///] + (((([ldap:///] + this + >> [??base?(|(objectClass=affectationLiee)(objectClass=affectationSemiLibre))])/entryDN)/-100) >> & ((([ldap:///] + user + >> [??base?(objectClass=personnel)])/entryDN)/-100)) + >> [??sub?entryDN=] + user/entryDN" +rscx >> by * break > > I'm afraid that we use quite a few specific schemas so you may not be > able to reproduce this easily. However, I hope these rules will enable > you to determine the problematic case. If necessary, I could prepare a > data and schema extract to reproduce the problem. That would help, but before you do it, could you please post a backtrace of the stack when the issue occurs? In case this doesn't suffice, and I can't figure things out myself, I'll ask you to provide a self-contained set of data that causes the issue. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4860) Sets' enhancement
by jclarke＠linagora.com 13 Sep '07

13 Sep '07

ando(a)sys-net.it a écrit : > raphael.ouazana(a)linagora.com wrote: > >> It seems OK with HEAD, but only if I revert this patch: >> http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/sets.c.diff?r1=1.28.… >> >> With this patch, I get a segfault. > > I have just committed a cleanup of the slap_set_join() function that > should be consistent. It should fix a leak in case of '&' on > overlapping sets, and consistently handle memory. Can you please test > it and point out failures? If you get any, please post the rules that > cause them, as those I could design worked fine (tested with valgrind). I am one of Raphael's colleagues, answering on his behalf. I've tested your latest commit, and most of our tests now run great. However, I still get a segault with the two rules below. Please note that this segfault only happens when *both* rules are present, each one by itself does not cause a segfault : > access to dn.sub="ou=Affectations,dc=linagora,dc=org" attrs=sigleAbrege,labeledURI,mailRoutingAddress,telephoneNumber,facsimileTelephoneNumber,entry > by set="([ldap:///] + (([ldap:///] + ((([ldap:///] + this + [??base?(|(objectClass=affectationLiee)(objectClass=affectationSemiLibre))])/entryDN)/-0) + [??base?])/responsable) + [??base?(|(administrateurResponsable=] + user + [)(administrateur=] + user + [)(membre=] + user + [))])/entryDN" +rscx > by * break > access to dn.sub="ou=Affectations,dc=linagora,dc=org" attrs=domaineMessagerie,finValidite,identifiantHarpegeStructure,responsable,objectClass,entry > by set="[ldap:///] + (((([ldap:///] + this + [??base?(|(objectClass=affectationLiee)(objectClass=affectationSemiLibre))])/entryDN)/-100) & ((([ldap:///] + user + [??base?(objectClass=personnel)])/entryDN)/-100)) + [??sub?entryDN=] + user/entryDN" +rscx > by * break I'm afraid that we use quite a few specific schemas so you may not be able to reproduce this easily. However, I hope these rules will enable you to determine the problematic case. If necessary, I could prepare a data and schema extract to reproduce the problem. Regards, Jon -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com

1 0

Re: (ITS#5069) SyncRepl on request
by ando＠sys-net.it 12 Sep '07

12 Sep '07

hadmut(a)danisch.de wrote: > Therefore, slapd should have a client mode where the SyncRepl process is > performed only on request, but then immediately. There should be an external > trigger to pull, e.g. send a signal oder do a special LDAP request. slapd should > then start a SyncRepl. A simple approach to performing what require is to use back-config to re-configure syncrepl for the consumer database; this should trigger an immediate sync. The trigger would then be a LDAPModify replace on the olcSyncrepl attribute of the database entry. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 10 Sep '07

10 Sep '07

raphael.ouazana(a)linagora.com wrote: > It seems OK with HEAD, but only if I revert this patch: > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/sets.c.diff?r1=1.28.… > > With this patch, I get a segfault. I have just committed a cleanup of the slap_set_join() function that should be consistent. It should fix a leak in case of '&' on overlapping sets, and consistently handle memory. Can you please test it and point out failures? If you get any, please post the rules that cause them, as those I could design worked fine (tested with valgrind). > >> And, could you >> document it on the FAQ, please? > > Done: http://www.openldap.org/faq/data/cache/1133.html. Does it seems > good for you ? Well, I'd prefer you to merge your comments with the existing, giant one. The contents look fine (although I'm not a native English speaker), except for one consideration: for consistency, "/-0" should return the DN untouched (although useless); perhaps "/-*" or something like that could be used to explode the DN into all ancestors. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 10 Sep '07

10 Sep '07

raphael.ouazana(a)linagora.com wrote: > Le Lun 10 septembre 2007 00:12, Pierangelo Masarati a écrit : >> raphael.ouazana(a)linagora.com wrote: >> >>> Do you think this patch has any chance to be accepted for future 2.4? >> Applied (with minor changes) to HEAD, please test. > > It seems OK with HEAD, but only if I revert this patch: > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/sets.c.diff?r1=1.28.… > > With this patch, I get a segfault. I think that's somehow related to ITS#4873, which I should definitely take time to solve. Unfortunately, with the proposed patch I see a leak, and I couldn't find time to track it down. > >> And, could you >> document it on the FAQ, please? > > Done: http://www.openldap.org/faq/data/cache/1133.html. Does it seems > good for you ? > >> One improvement that could be applied >> is to allow numbers larger than 9... > > As far as I know, there is no such limitation... Then I probably misinterpreted that bit of parsing. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4860) Sets' enhancement
by raphael.ouazana＠linagora.com 10 Sep '07

10 Sep '07

Le Lun 10 septembre 2007 00:12, Pierangelo Masarati a écrit : > raphael.ouazana(a)linagora.com wrote: > >> Do you think this patch has any chance to be accepted for future 2.4? > > Applied (with minor changes) to HEAD, please test. It seems OK with HEAD, but only if I revert this patch: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/sets.c.diff?r1=1.28.… With this patch, I get a segfault. > And, could you > document it on the FAQ, please? Done: http://www.openldap.org/faq/data/cache/1133.html. Does it seems good for you ? > One improvement that could be applied > is to allow numbers larger than 9... As far as I know, there is no such limitation... Regards, Raphael Ouazana.

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 09 Sep '07

09 Sep '07

raphael.ouazana(a)linagora.com wrote: > Do you think this patch has any chance to be accepted for future 2.4? Applied (with minor changes) to HEAD, please test. And, could you document it on the FAQ, please? One improvement that could be applied is to allow numbers larger than 9... 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4860) Sets' enhancement
by raphael.ouazana＠linagora.com 09 Sep '07

09 Sep '07

Hi, I have uploaded a new version of this patch: ftp://ftp.openldap.org/incoming/raphael-ouazana-070906.patch Now /-0 allows to get all the parents of an entry. So to keep the example where user is cn=user,ou=people,dc=example,dc=com: user/-0 : resolves to set { "cn=user,ou=people,dc=example,dc=com" , "ou=people,dc=example,dc=com", "dc=example,dc=com" , "dc=com" , "" } In fact it was already possible to do that with sets with filters using entryDN:dnSuperiorMatch, but it was really slower (in 2.3 as in HEAD). Do you think this patch has any chance to be accepted for future 2.4? Regards, Raphael Ouazana. Legal notice : This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in this following patch were developed by Raphael Ouazana raphael.ouazana(a)linagora.com. These modifications are not subject to any license of Linagora. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2007 Raphael Ouazana, Linagora Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#5130) "Reply" oddities
by kurt＠OpenLDAP.org 08 Sep '07

08 Sep '07

On Sep 8, 2007, at 10:02 AM, ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: none > OS: none > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.175.154.35) > Submitted by: ando > > > When hitting "reply" from the ITS, messages are not sent to the > mailing list, > even if openldap-its(a)openldap.org is added to the CC field. Kind of by (broken) design. A reply is intended to be used to send a note directly to the submitter. It's broken in that you need to change the from header to openldap-its(a)openldap.org for any follow-up to be returned to openldap-its(a)openldap.org. If you want to reply-all, reply-all to the copy forwarded to openldap-bugs(a)openldap.org.

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2007