openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#5132) test052 fails: ldapadd failed (21)!
by ando＠sys-net.it 13 Sep '07

13 Sep '07

The test doesn't consider the possibility to build slapo-memberof(5) as module. I'll fix that later. 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

(ITS#5132) test052 fails: ldapadd failed (21)!
by michael＠stroeder.com 13 Sep '07

13 Sep '07

Full_Name: Michael Ströder Version: HEAD synced now OS: openSUSE 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.6.221) $ ./run -b bdb test052 Cleaning up test run directory leftover from previous run. Running ./scripts/test052-memberof... running defines.sh Starting slapd on TCP/IP port 9011... Running ldapadd to build slapd config database... ldapadd failed (21)!

1 0

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

13 Sep '07

Pierangelo Masarati a écrit : >> 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. Of course. Please also see my message a few minutes ago with valgrind output. Stack trace follows: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1740719216 (LWP 10412)] 0xb7bcfdec in free () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb7bcfdec in free () from /lib/tls/i686/cmov/libc.so.6 #1 0x0816338e in ber_bvarray_free_x (a=0x82e4058, ctx=0x82bd6b8) at memory.c:731 #2 0x080af40a in slap_set_filter (gatherer=0x8086720 <acl_set_gather>, cp=0x983291e0, fbv=0x983291e8, user=0x82dc094, target=0xb5312bd0, results=0x0) at sets.c:391 #3 0x080864ca in acl_match_set (subj=0x983295b0, op=0x82dbff8, e=0xb5312bc4, default_set_attribute=0x0) at acl.c:2299 #4 0x08089786 in slap_access_allowed (op=0x82dbff8, e=0xb5312bc4, desc=0x8244de8, val=0x97eeb4c0, access=ACL_SEARCH, state=0x0, maskp=0x98329c20) at acl.c:1621 #5 0x0808b6c4 in fe_access_allowed (op=0x82dbff8, e=0xb5312bc4, desc=0x8244de8, val=0x97eeb4c0, access=ACL_SEARCH, state=0x0, maskp=0x98329c20) at acl.c:311 #6 0x080c8930 in over_access_allowed (op=0x82dbff8, e=0xb5312bc4, desc=0x8244de8, val=0x97eeb4c0, access=ACL_SEARCH, state=0x0, maskp=0x98329c20) at backover.c:314 #7 0x080872c4 in access_allowed_mask (op=0x82dbff8, e=0xb5312bc4, desc=0x8244de8, val=0x97eeb4c0, access=<value optimized out>, state=0x0, maskp=0x0) at acl.c:413 #8 0x08083bcf in test_ava_filter (op=0x82dbff8, e=0xb5312bc4, ava=0x97eeb4bc, type=163) at filterentry.c:545 #9 0x080843e9 in test_filter (op=0x82dbff8, e=0xb5312bc4, f=0x97eeb4e4) at filterentry.c:88 #10 0x080dc90e in bdb_search (op=0x82dbff8, rs=0x983eb154) at search.c:844 #11 0x080679f6 in fe_op_search (op=0x82dbff8, rs=0x983eb154) at search.c:368 #12 0x080c7ca1 in overlay_op_walk (op=0x82dbff8, rs=0x983eb154, which=op_search, oi=0x8264bf8, on=0x8264cf8) at backover.c:652 #13 0x080c820d in over_op_func (op=0x82dbff8, rs=0x983eb154, which=op_search) at backover.c:704 #14 0x0806823e in do_search (op=0x82dbff8, rs=0x983eb154) at search.c:217 #15 0x0806583e in connection_operation (ctx=0x983eb238, arg_v=0x82dbff8) at connection.c:1145 #16 0x08065c71 in connection_read_thread (ctx=0x983eb238, argv=0xe) at connection.c:1271 #17 0x0813cda6 in ldap_int_thread_pool_wrapper (xpool=0x824bfd0) at tpool.c:614 #18 0xb7cab31b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #19 0xb7c3457e in clone () from /lib/tls/i686/cmov/libc.so.6 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#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

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