- openldap-bugs - openldap.org

Re: (ITS#5134) dbconfig vs. DB_CONFIG
by hyc＠symas.com 13 Sep '07

13 Sep '07

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24/re23 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.203.230.29) > Submitted by: ando > > > The slapd-bdb(5) man page seems to me unclear with respect to the dbconfig > directive. In fact, what I gather from the text is that if no DB_CONFIG file > exists, any dbconfig directive will be used to generate one; otherwise, an > existing DB_CONFIG file will not be altered. What is unclear is what happens if > both a DB_CONFIG file and any dbconfig directives exist, and they differ? Who > takes the precedence? What if any dbconfig directive is not present in the > DB_CONFIG file? There is nothing ambiguous here. When slapd.conf is being used, the dbconfig directive *only* takes effect *if* no DB_CONFIG file exists. If one exists, the dbconfig directives are ignored. -- -- Howard Chu Chief Architect, 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#5134) dbconfig vs. DB_CONFIG
by ghenry＠suretecsystems.com 13 Sep '07

13 Sep '07

<quote who="ando(a)sys-net.it"> > ghenry(a)suretecsystems.com wrote: > >> I read that as if there is no DB_CONFIG, one gets created from the >> dbconfig directives. If there is one, dbconfig stuff gets ignored and >> the >> DB_CONFIG file is used. >> >> But yes, it's not clear what happens in that situation. So, I go back to >> you ;-) What does the code actually do? If it does indeed ignore >> dbconfig >> and honour DB_CONFIG then we say that. >> >> As I read your comments, you sound like you don't know what the code >> does > > Exactly. Oh, well excuse me for presuming! > >> (I don't as I haven't looked, but I'd be very surprised if you actually >> don't know). So this brings me back to my first point; we make it say >> what >> the code actually does do in the situation that there is a DB_CONFIG >> file >> and dbconfig directives in slapd.conf or slapd.d/ > > After reading the code, it seems that if reading from slapd.conf and the > DB_CONFIG is in place, any slapd.conf dbconfig directive is ignored. OK, sorry. I should have taken the time to read it myself. So we just amend the man page to say that. Good. > > 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#5134) dbconfig vs. DB_CONFIG
by ando＠sys-net.it 13 Sep '07

13 Sep '07

ghenry(a)suretecsystems.com wrote: > I read that as if there is no DB_CONFIG, one gets created from the > dbconfig directives. If there is one, dbconfig stuff gets ignored and the > DB_CONFIG file is used. > > But yes, it's not clear what happens in that situation. So, I go back to > you ;-) What does the code actually do? If it does indeed ignore dbconfig > and honour DB_CONFIG then we say that. > > As I read your comments, you sound like you don't know what the code does Exactly. > (I don't as I haven't looked, but I'd be very surprised if you actually > don't know). So this brings me back to my first point; we make it say what > the code actually does do in the situation that there is a DB_CONFIG file > and dbconfig directives in slapd.conf or slapd.d/ After reading the code, it seems that if reading from slapd.conf and the DB_CONFIG is in place, any slapd.conf dbconfig directive is ignored. 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#5134) dbconfig vs. DB_CONFIG
by ghenry＠suretecsystems.com 13 Sep '07

13 Sep '07

<quote who="Pierangelo Masarati"> > ghenry(a)suretecsystems.com wrote: > >>> I think the point is not what the code should (or should not) do, or >>> whether its current behavior is correct or not; it's rather that the >>> man >>> page, as far as I understand it, is not clear about what the code >>> currently does. >> >> Ok, well the text should reflect what the code does. I think I'm missing >> the point of your question. If the text doesn't currently match what is >> actually happening in the code, then we fix the man page so it does. > > My point is that from that text I don't understand what the code does. > Either it's my English (could well be), or it needs to be reworded. I'm > quoting here the original text: > > snip... > > dbconfig <Berkeley-DB-setting> > Specify a configuration directive to be placed in the DB_CONFIG > file of the database directory. The dbconfig directive is just > a convenience to allow all necessary configuration to be set in > the slapd.conf file. The options set using this directive will > only be written to the DB_CONFIG file if no such file existed > at server startup time. This allows one to set initial values > without overwriting/destroying a DB_CONFIG file that was > already customized through other means. > > snip... > > So it seems to be quite clear about what's going to happen if no > DB_CONFIG exists, but not as clear about what happens if DB_CONFIG > already exists, apart from not getting overwritten or otherwise modified. I read that as if there is no DB_CONFIG, one gets created from the dbconfig directives. If there is one, dbconfig stuff gets ignored and the DB_CONFIG file is used. But yes, it's not clear what happens in that situation. So, I go back to you ;-) What does the code actually do? If it does indeed ignore dbconfig and honour DB_CONFIG then we say that. As I read your comments, you sound like you don't know what the code does (I don't as I haven't looked, but I'd be very surprised if you actually don't know). So this brings me back to my first point; we make it say what the code actually does do in the situation that there is a DB_CONFIG file and dbconfig directives in slapd.conf or slapd.d/ Or am I being extremely stupid here? Thanks, Gavin.

1 0

Re: (ITS#5134) dbconfig vs. DB_CONFIG
by ando＠sys-net.it 13 Sep '07

13 Sep '07

ghenry(a)suretecsystems.com wrote: >> I think the point is not what the code should (or should not) do, or >> whether its current behavior is correct or not; it's rather that the man >> page, as far as I understand it, is not clear about what the code >> currently does. > > Ok, well the text should reflect what the code does. I think I'm missing > the point of your question. If the text doesn't currently match what is > actually happening in the code, then we fix the man page so it does. My point is that from that text I don't understand what the code does. Either it's my English (could well be), or it needs to be reworded. I'm quoting here the original text: snip... dbconfig <Berkeley-DB-setting> Specify a configuration directive to be placed in the DB_CONFIG file of the database directory. The dbconfig directive is just a convenience to allow all necessary configuration to be set in the slapd.conf file. The options set using this directive will only be written to the DB_CONFIG file if no such file existed at server startup time. This allows one to set initial values without overwriting/destroying a DB_CONFIG file that was already customized through other means. snip... So it seems to be quite clear about what's going to happen if no DB_CONFIG exists, but not as clear about what happens if DB_CONFIG already exists, apart from not getting overwritten or otherwise modified. 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#5134) dbconfig vs. DB_CONFIG
by ghenry＠suretecsystems.com 13 Sep '07

13 Sep '07

<quote who="ando(a)sys-net.it"> > ghenry(a)suretecsystems.com wrote: >>> The slapd-bdb(5) man page seems to me unclear with respect to the >>> dbconfig >>> directive. In fact, what I gather from the text is that if no >>> DB_CONFIG >>> file >>> exists, any dbconfig directive will be used to generate one; otherwise, >>> an >>> existing DB_CONFIG file will not be altered. What is unclear is what >>> happens if >>> both a DB_CONFIG file and any dbconfig directives exist, and they >>> differ? >>> Who >>> takes the precedence? What if any dbconfig directive is not present in >>> the >>> DB_CONFIG file? >>> >> >> I would say since dbconfig directives only work on a restart of slapd, >> and >> that if a DB_CONFIG is present, the DB_CONFIG should *always* take >> precedence. If dbconfig changes could make a difference via back-config, >> which they can't without a restart, then dbconfig stuff should override >> any DB_CONFIG. > > Gavin, > > I think the point is not what the code should (or should not) do, or > whether its current behavior is correct or not; it's rather that the man > page, as far as I understand it, is not clear about what the code > currently does. Ok, well the text should reflect what the code does. I think I'm missing the point of your question. If the text doesn't currently match what is actually happening in the code, then we fix the man page so it does.

1 0

Re: (ITS#5134) dbconfig vs. DB_CONFIG
by ando＠sys-net.it 13 Sep '07

13 Sep '07

ghenry(a)suretecsystems.com wrote: >> The slapd-bdb(5) man page seems to me unclear with respect to the dbconfig >> directive. In fact, what I gather from the text is that if no DB_CONFIG >> file >> exists, any dbconfig directive will be used to generate one; otherwise, an >> existing DB_CONFIG file will not be altered. What is unclear is what >> happens if >> both a DB_CONFIG file and any dbconfig directives exist, and they differ? >> Who >> takes the precedence? What if any dbconfig directive is not present in >> the >> DB_CONFIG file? >> > > I would say since dbconfig directives only work on a restart of slapd, and > that if a DB_CONFIG is present, the DB_CONFIG should *always* take > precedence. If dbconfig changes could make a difference via back-config, > which they can't without a restart, then dbconfig stuff should override > any DB_CONFIG. Gavin, I think the point is not what the code should (or should not) do, or whether its current behavior is correct or not; it's rather that the man page, as far as I understand it, is not clear about what the code currently does. 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#5132) test052 fails: ldapadd failed (21)!
by ando＠sys-net.it 13 Sep '07

13 Sep '07

Fixed in HEAD (HEAD only); please test. 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#5134) dbconfig vs. DB_CONFIG
by ghenry＠suretecsystems.com 13 Sep '07

13 Sep '07

> > The slapd-bdb(5) man page seems to me unclear with respect to the dbconfig > directive. In fact, what I gather from the text is that if no DB_CONFIG > file > exists, any dbconfig directive will be used to generate one; otherwise, an > existing DB_CONFIG file will not be altered. What is unclear is what > happens if > both a DB_CONFIG file and any dbconfig directives exist, and they differ? > Who > takes the precedence? What if any dbconfig directive is not present in > the > DB_CONFIG file? > I would say since dbconfig directives only work on a restart of slapd, and that if a DB_CONFIG is present, the DB_CONFIG should *always* take precedence. If dbconfig changes could make a difference via back-config, which they can't without a restart, then dbconfig stuff should override any DB_CONFIG. I hope that makes sense? Gavin.

1 0

(ITS#5134) dbconfig vs. DB_CONFIG
by ando＠sys-net.it 13 Sep '07

13 Sep '07

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.203.230.29) Submitted by: ando The slapd-bdb(5) man page seems to me unclear with respect to the dbconfig directive. In fact, what I gather from the text is that if no DB_CONFIG file exists, any dbconfig directive will be used to generate one; otherwise, an existing DB_CONFIG file will not be altered. What is unclear is what happens if both a DB_CONFIG file and any dbconfig directives exist, and they differ? Who takes the precedence? What if any dbconfig directive is not present in the DB_CONFIG file? p.

1 0

(ITS#5133) Synchronous replication on slave doesn't notice lost network connection
by audrius.valunas＠teo.lt 13 Sep '07

13 Sep '07

Full_Name: Audrius Valunas Version: openldap2-2.3.27-25 OS: SUSE LINUX 10.0 (i586) OSS URL: Submission from: (NULL) (212.59.0.201) There is synchronous replication between mastyer and slave. When network connectivity problems occur master closes tcp connection but slave doesn't notice those problems, it still has tcp connection open, but in real it is not receiving updates any more. I think that can be solved adding some ack from slave because sending on such a socket would fail and force slave to retry connection.

1 0

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

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

10 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

Re: (ITS#5130) "Reply" oddities
by ghenry＠suretecsystems.com 08 Sep '07

08 Sep '07

<quote who="ando(a)sys-net.it"> > ghenry(a)suretecsystems.com wrote: > >>> 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. >>> >> >> Testing. > > I've received yours (twice, as usual), but I don't receive mine. This is a reply via a normal mail client to openldap-its only, not cc'd to you. > > 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#5130) "Reply" oddities
by ando＠sys-net.it 08 Sep '07

08 Sep '07

ghenry(a)suretecsystems.com wrote: >> 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. >> > > Testing. I've received yours (twice, as usual), but I don't receive mine. 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#5130) "Reply" oddities
by ghenry＠suretecsystems.com 08 Sep '07

08 Sep '07

<quote who="ando(a)sys-net.it"> > 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. > Testing.

1 0

(ITS#5130) "Reply" oddities
by ando＠sys-net.it 08 Sep '07

08 Sep '07

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.

1 0

Re: (ITS#5120) slapadd -q makes database logs unusable
by ando＠sys-net.it 08 Sep '07

08 Sep '07

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> hyc(a)symas.com wrote: >>> ando(a)sys-net.it wrote: >>>> When slapadd'ing -q, existing database log files seem to become unusable. If >>>> this is correct, as it seems to be, slapadd could refuse to start with -q if log >>>> files are present, or, for example, remove the logs if -qq. >>> I guess we could add that check. The docs already say that if an error occurs, >>> the entire database will be unusable. As such, you should only use it for >>> initially populating a database, not for adding to an existing one. >> The story is that I placed logs in a separate directory and I forgot to >> clean them up when regenerating the DB after removing the database files :) > > Ugh. I don't see how we can reliably detect this case. > > In what way do the logs become unusable? I've tried to reproduce this situation > and see no errors of any kind. > > E.g., sh run test001 > rm testrun/db.1.a/{alock,*db*} > ../servers/slapd/slapadd -q -f testrun/slapd.1.conf -l testdata/test-ordered.ldif > (the above works fine) > ../servers/slapd/slapd -f testrun/slapd.1.conf ... > (works fine) > > db_stat -h testrun/db.1.a -l > > (no complaints there either) Initially, I thought your check was not much representative, since test001 doesn't do any writes. In my original case, I forgot to mention that DB_LOG_AUTOREMOVE was set. So I tried that configuration and manually ran the load of test008, resulting in creating multiple logs, part of which were removed. Then I ran the commands you suggested above, but nothing happened, so I'm at a loss. In fact, old log files were immediately removed by slapd itself, and log files numbering correctly restarted from where it left. Probably I was chasing a red herring. 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#5120) slapadd -q makes database logs unusable
by hyc＠symas.com 08 Sep '07

08 Sep '07

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> ando(a)sys-net.it wrote: >>> When slapadd'ing -q, existing database log files seem to become unusable. If >>> this is correct, as it seems to be, slapadd could refuse to start with -q if log >>> files are present, or, for example, remove the logs if -qq. >> I guess we could add that check. The docs already say that if an error occurs, >> the entire database will be unusable. As such, you should only use it for >> initially populating a database, not for adding to an existing one. > > The story is that I placed logs in a separate directory and I forgot to > clean them up when regenerating the DB after removing the database files :) Ugh. I don't see how we can reliably detect this case. In what way do the logs become unusable? I've tried to reproduce this situation and see no errors of any kind. E.g., sh run test001 rm testrun/db.1.a/{alock,*db*} ../servers/slapd/slapadd -q -f testrun/slapd.1.conf -l testdata/test-ordered.ldif (the above works fine) ../servers/slapd/slapd -f testrun/slapd.1.conf ... (works fine) db_stat -h testrun/db.1.a -l (no complaints there either) -- -- Howard Chu Chief Architect, 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#5129) slapindex -q corrupts database if the DB_CONFIG file has changed
by hyc＠symas.com 08 Sep '07

08 Sep '07

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.37 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (71.202.148.128) > > > After getting repeat DB corruptions, I finally tracked down the issue to this: > > If DB_CONFIG has changed since the last time slapd was started, and slapindex -q > is run, the database ends up corrupt. Don't do that. HEAD has been fixed to exit in this situation. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5129) slapindex -q corrupts database if the DB_CONFIG file has changed
by quanah＠zimbra.com 08 Sep '07

08 Sep '07

Full_Name: Quanah Gibson-Mount Version: 2.3.37 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.202.148.128) After getting repeat DB corruptions, I finally tracked down the issue to this: If DB_CONFIG has changed since the last time slapd was started, and slapindex -q is run, the database ends up corrupt. For example, I did the following with a perfectly happy slapd: ldap stop Killing slapd with pid 9857 done. cd /opt/zimbra/openldap-data touch DB_CONFIG /opt/zimbra/openldap/sbin/slapindex -b '' -q -f /opt/zimbra/conf/slapd.conf bdb_db_open: DB_CONFIG for suffix has changed. Performing database recovery to activate new settings. bdb(): DB_RECOVER and DB_RECOVER_FATAL require DB_TXN_INIT in DB_ENV->open bdb(): PANIC: Invalid argument bdb_db_open: Database cannot be recovered, err -30978. Restore from backup! backend_startup_one: bi_db_open failed! (-30978) slap_startup failed One of the things this does, is break syncreplication, as it apparently clears out the glue entry. :/ --Quanah

1 0

(ITS#5128) slapd startup fails to note suffix when DB_CONFIG chagnes and suffix is ""
by quanah＠zimbra.com 08 Sep '07

08 Sep '07

Full_Name: Quanah Gibson-Mount Version: 2.3.37 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.202.148.128) I noticed that when using the empty suffix, and DB_CONFIG is updated, this gets logged: bdb_db_open: DB_CONFIG for suffix has changed. Note the extra space and lack of suffix.

1 0

Re: ldap_unbind unhandled SIGPIPE (ITS#5127)
by ando＠sys-net.it 07 Sep '07

07 Sep '07

ando(a)sys-net.it wrote: > I've prepared a trivial client that ldap_sasl_bind_s(), holds on while I > shut down the server, ldap_search_ext_s() with LDAP_SERVER_DOWN and > ldap_unbind_ext(). Prior to patching, I always got SIGPIPE. Let me add that the above patch does not work when using ldapi://; in that case, the SIGPIPE occurs when first flushing a request on the broken connection (in sb_stream_write()), while on regular INET sockets the flush succeeds and the SIGPIPE prior to patching was returned much later at unbind. 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: ldap_unbind unhandled SIGPIPE (ITS#5127)
by ando＠sys-net.it 07 Sep '07

07 Sep '07

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: >> I've seen something similar in recent code. I was just tracking it >> down, so you basically saved me the effort of opening a ticket :). What >> I found so far is that when ldap_unbind(3) is called (which is required >> to release resources after the connection broke), the client library >> tries to send a LDAPUnbind request to the server, even though it just >> got a LDAP_SERVER_DOWN (-1). The behavior seems to be more frequent >> when the connection brakes while using ldapi://, and I couldn't spot the >> difference up to now, I'm just mentioning it in case it rings any bells. > > > What happens is that when try_read1msg() finds out the connection is > broken, it sets ld_errno to LDAP_SERVER_DOWN, but leaves > lc->lconn_status to LDAP_CONNST_CONNECTED, so a subsequent call to > ldap_unbind_ext causes ldap_free_connection() to try sending the > LDAPUnbind anyway. Either we also check that ld->ld_errno is not > LDAP_SERVER_DOWN (provided no one resets it in the meanwhile), or clear > lc->lconn_status as soon as we find out the connection is broken. I'd > go for the second, but probably someone else is more familiar than me > with the library's internals. This is the fix I propose: ========================================== diff -u -r1.154 result.c --- libraries/libldap/result.c 14 Jun 2007 20:35:41 -0000 1.154 +++ libraries/libldap/result.c 7 Sep 2007 20:57:52 -0000 @@ -558,6 +558,14 @@ if ( sock_errno() == EAGAIN ) return LDAP_MSG_X_KEEP_LOOKING; #endif ld->ld_errno = LDAP_SERVER_DOWN; +#ifdef LDAP_R_COMPILE + ldap_pvt_thread_mutex_lock( &ld->ld_req_mutex ); +#endif + ldap_free_connection( ld, lc, 1, 0 ); +#ifdef LDAP_R_COMPILE + ldap_pvt_thread_mutex_unlock( &ld->ld_req_mutex ); +#endif + lc = *lcp = NULL; return -1; default: ========================================== I've prepared a trivial client that ldap_sasl_bind_s(), holds on while I shut down the server, ldap_search_ext_s() with LDAP_SERVER_DOWN and ldap_unbind_ext(). Prior to patching, I always got SIGPIPE. 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: ldap_unbind unhandled SIGPIPE (ITS#5127)
by ando＠sys-net.it 07 Sep '07

07 Sep '07

ando(a)sys-net.it wrote: > I've seen something similar in recent code. I was just tracking it > down, so you basically saved me the effort of opening a ticket :). What > I found so far is that when ldap_unbind(3) is called (which is required > to release resources after the connection broke), the client library > tries to send a LDAPUnbind request to the server, even though it just > got a LDAP_SERVER_DOWN (-1). The behavior seems to be more frequent > when the connection brakes while using ldapi://, and I couldn't spot the > difference up to now, I'm just mentioning it in case it rings any bells. What happens is that when try_read1msg() finds out the connection is broken, it sets ld_errno to LDAP_SERVER_DOWN, but leaves lc->lconn_status to LDAP_CONNST_CONNECTED, so a subsequent call to ldap_unbind_ext causes ldap_free_connection() to try sending the LDAPUnbind anyway. Either we also check that ld->ld_errno is not LDAP_SERVER_DOWN (provided no one resets it in the meanwhile), or clear lc->lconn_status as soon as we find out the connection is broken. I'd go for the second, but probably someone else is more familiar than me with the library's internals. 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: ldap_unbind unhandled SIGPIPE (ITS#5127)
by ando＠sys-net.it 07 Sep '07

07 Sep '07

I've seen something similar in recent code. I was just tracking it down, so you basically saved me the effort of opening a ticket :). What I found so far is that when ldap_unbind(3) is called (which is required to release resources after the connection broke), the client library tries to send a LDAPUnbind request to the server, even though it just got a LDAP_SERVER_DOWN (-1). The behavior seems to be more frequent when the connection brakes while using ldapi://, and I couldn't spot the difference up to now, I'm just mentioning it in case it rings any bells. I think not trapping SIGPIPE is correct, since this should definitely be delegated to the application. But the library itself shouldn't trigger false SIGPIPEs by trying to use a connection it knows it's broken. I'll keep digging. 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#5127) ldap_unbind unhandled SIGPIPE
by aberry0364＠hotmail.com 07 Sep '07

07 Sep '07

Full_Name: Arlene Berry Version: 2.3.38 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.221.115.100) I am using OpenLDAP 2.3.38 with Cyrus SASL and MIT Kerberos to communicate with Active Directory on Windows Server 2003 R2. I have been primarily working on Solaris 8 and 9 but we've also seen signs of this problem on Solaris 10, AIX, and HPUX. Initially I was using OpenLDAP 2.3.19 which also had the problem. The sequence of events is that I bind to Active Directory, do a search, and successfully retrieve the results. Then I let my program and the LDAP connection sit idle for at least 15 minutes so that the LDAP connection will time out. Next I have the program do another ldap_search_ext which returns 0 and then ldap_result which returns -1. At this point the program does an ldap_unbind. What the program is supposed to do next is create a new LDAP connection and try the search again. Sometimes it does and sometimes I see an unhandled SIGPIPE error which causes the program to halt. When run under a debugger with the LDAP debug level set to 65535 this is what it shows: ldap_unbind ldap_free_request (origid 8, msgid 8) ldap_free_connection 1 1 ldap_send_unbind t@1 (l@1) signal PIPE (Broken Pipe) in _libc_write at 0xff21e15c 0xff21e15c: _libc_write+0x000c: bgeu _libc_write+0x40 ! 0xff21e190 Current function is sb_stream_write 521 return write( sbiod->sbiod_sb->sb_fd, buf, len ); If I tell the debugger to continue or if I set SIGPIPE to SIG_IGN at the beginning of the program, it appears to continue successfully.

1 0

Re: (ITS#5124) segfault on modify operation by slurpd with rwm overlay
by jclarke＠linagora.com 07 Sep '07

07 Sep '07

Hi Pierangelo, Pierangelo Masarati a écrit : > ando(a)sys-net.it wrote: >> I'll check >> if this could also happen with syncrepl, and try to figure out a >> workaround. > > This is now fixed in HEAD and in re23. Please test. Thanks, p. Just tested in re23, with slurpd, and it works great ! Thanks a lot, 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: OpenLdap ERROR: passwd: Authentication token manipulation error (ITS#5125)
by ando＠sys-net.it 07 Sep '07

07 Sep '07

Anne Moore wrote: > No, it's not that easy. Not just untar, configure, etc. Remember, RHEL 4.0 > doesn't support the latest OpenLdap version. So, "tar, configure, etc" would > not do any good. ;-) Wish it did!! I routinely **develop** OpenLDAP on RHEL 4.0; what does in your opinion prevent it from **supporting** the latest OpenLDAP? All you need is a compiler and few tools available with any Linux distribution. 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: OpenLdap ERROR: passwd: Authentication token manipulation error (ITS#5125)
by quanah＠zimbra.com 07 Sep '07

07 Sep '07

--On Friday, September 07, 2007 12:54 PM +0000 ando(a)sys-net.it wrote: > diabeticithink(a)yahoo.com wrote: >> Thank you for the help. I cannot upgrade to a later version of OpenLdap >> because RHEL 4.0 doesn't support it. Bummer, eh? > > Well, there is nothing the OpenLDAP project can do for you, then, other > than providing more than 3 years of development since 2.2.13 (it was > released June 2004), that RedHat in the first place, but basically you > seem to be willing to ignore (it's just one click away: untar, > configure, make, make install). > > Or, you should ask RedHat to either upgrade OpenLDAP in RHEL 4.0, or fix > your specific bug, if any (I still suspect a misconfiguration, possibly > unrelated to OpenLDAP software itself, given that OpenLDAP software does > not generate that specific message). As distributors, they are > responsible for providing you up-to-date software when available (how > responsive they are might depend on the type of maintenance contract you > have with them). Just to note, this has been discussed many times on the software list. RedHat's packages should only be viewed as providing access to the LDAP client API, and *not* as packages to be used for running a production LDAP service. They are not maintained to the level necessary for production usage. I'd strongly advise using the resources already made available elsewhere for running OpenLDAP as a production service. For example, Symas Corp. (employer of Howard Chu, OpenLDAP's Chief Architect) provides free pre-compiled and tested packages of OpenLDAP at <http://www.symas.com>, and Buchan Milne, who is heavily involved with the OpenLDAP project also provides pre-compiled packages of OpenLDAP at <http://staff.telkomsa.net/packages/>. You are best off utilizing either of these resources if you want to run OpenLDAP as a production service on your systems. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: OpenLdap ERROR: passwd: Authentication token manipulation error (ITS#5125)
by ando＠sys-net.it 07 Sep '07

07 Sep '07

diabeticithink(a)yahoo.com wrote: > Thank you for the help. I cannot upgrade to a later version of OpenLdap > because RHEL 4.0 doesn't support it. Bummer, eh? Well, there is nothing the OpenLDAP project can do for you, then, other than providing more than 3 years of development since 2.2.13 (it was released June 2004), that RedHat in the first place, but basically you seem to be willing to ignore (it's just one click away: untar, configure, make, make install). Or, you should ask RedHat to either upgrade OpenLDAP in RHEL 4.0, or fix your specific bug, if any (I still suspect a misconfiguration, possibly unrelated to OpenLDAP software itself, given that OpenLDAP software does not generate that specific message). As distributors, they are responsible for providing you up-to-date software when available (how responsive they are might depend on the type of maintenance contract you have with them). 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: OpenLdap ERROR: passwd: Authentication token manipulation error (ITS#5125)
by diabeticithink＠yahoo.com 07 Sep '07

07 Sep '07

Thank you for the help. I cannot upgrade to a later version of OpenLdap because RHEL 4.0 doesn't support it. Bummer, eh? -----Original Message----- From: Pierangelo Masarati [mailto:openldap-its@OpenLDAP.org] Sent: Friday, September 07, 2007 2:18 AM To: diabeticithink(a)yahoo.com Cc: openldap-its(a)OpenLDAP.org Subject: Re: OpenLdap ERROR: passwd: Authentication token manipulation error (ITS#5125) OpenLDAP 2.2.13 is obsolete. Support has been dropped ages ago and even in the case a problem is solved, no new release can occur in that branch. The current release is 2.3.38, so please upgrade and check if the problem persists. In any case, although the error message may appear scaring, there is no indication of a software error, so please direct further discussion to the openldap-software mailing list. This ITS is to track OpenLDAP software bugs, so please don't use it until there's evidence of a software bug. This ITS will be closed. p.

1 0

RE: OpenLdap ERROR: passwd: Authentication token manipulation error (ITS#5125)
by diabeticithink＠yahoo.com 07 Sep '07

07 Sep '07

Yes, it's the OpenLdap software that created this. As soon as I disable the Openldap, the users can change their password without a problem. Any idea on how to fix this? -----Original Message----- From: Kurt Zeilenga [mailto:openldap-its@OpenLDAP.org] Sent: Friday, September 07, 2007 4:10 AM To: diabeticithink(a)yahoo.com Subject: Re: OpenLdap ERROR: passwd: Authentication token manipulation error (ITS#5125) Actually, discussion of this error message should be directed to a mailing list about the LDAP client software, or other software, that actually produced the message. That message doesn't appear to be generated by any OpenLDAP Software.

1 0

Re: (ITS#5113) pcache returns incomplete results
by rhafer＠suse.de 07 Sep '07

07 Sep '07

On Donnerstag, 6. September 2007, ando(a)sys-net.it wrote: > rhafer(a)suse.de wrote: > > Hm, current HEAD first calls add_query, which adds the CachedQuery to the > > cache and after that calls cache_entries to add the entries of that Query > > to the cache. That means that query_containment already know about the > > Query before its result is completely cached. > > In RE23 it is just the other way arround (first cache_entries() then > > add_query()). > > I see two possible solution: > > > > 1. Switch back to the old behaviour. But I guess the change was made for > > a reason. I don't know that yet. Seems the change happend between r1.95 > > and r1.96 of pcache.c (log message: "Fix concurrency issues"). > > > > 2. Protect the cached query with an rw_lock. Writelock it while > > cache_entries() is executing and readlock it during searches. This would > > give us the behaviour that Ando suggested in the discussion of ITS#5112. > > (pcache would not try to cache the same search request mulitple times, > > but block the second request until the first one is cached and then > > answer it from the cache) > > +1 (if there's no drawback, of course) The only drawback (if it really is a drawback) is that subsequent clients will have to wait for the caching to be completed. Depending on the query that is being cached can take pretty long. On the other hand one can also view this as an advantage, as it save some network traffic between the proxy that the backend-server. :) -- Ralf

1 0

(ITS#5126) Auto-generation of devel/admin on website
by ghenry＠OpenLDAP.org 07 Sep '07

07 Sep '07

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Dear all, I would like http://www.openldap.org/devel/admin/ to be automatically generated once a week. Daily is too often and might catch a broken make or similar. We can discuss the best time of day to run the job. Thanks, Gavin.

1 0

Re: (ITS#5124) segfault on modify operation by slurpd with rwm overlay
by ando＠sys-net.it 07 Sep '07

07 Sep '07

ando(a)sys-net.it wrote: > I'll check > if this could also happen with syncrepl, and try to figure out a > workaround. This is now fixed in HEAD and in re23. Please test. Thanks, 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#5124) segfault on modify operation by slurpd with rwm overlay
by ando＠sys-net.it 07 Sep '07

07 Sep '07

jclarke(a)linagora.com wrote: > We are using 2.3.37 for both master and slave, and have confirmed that > disactivating the rwm overlay in slapd.conf avoids the problem. The failure is related to the fact that you rewrite the bindDN; this tricks slapo-rwm(5) into failing to recognize that the operation is actually an update, resulting in a double free at cleanup. I'll check if this could also happen with syncrepl, and try to figure out a workaround. In the meanwhile you should be able to solve the problem by reworking the bindDN rewrite rules so that the updatedn is not rewritten. 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#5124) segfault on modify operation by slurpd with rwm overlay
by ando＠sys-net.it 07 Sep '07

07 Sep '07

jclarke(a)linagora.com wrote: > With a simple master/slave setup, and the rwm overlay activated for the bindDN > context, any modify operation made on the master, replicated with slurpd causes > the slave to crash. > > You will find below a backtrace of the slave when it crashes, and the > configuration files we're using on the master, the slave, an LDIF of the > contents of the directory are in the archive on ftp.openldap.org indicated in > the ITS. > > We are using 2.3.37 for both master and slave, and have confirmed that > disactivating the rwm overlay in slapd.conf avoids the problem. I'll try to look at your report, but let me note that slurpd is deprecated; since you're running OpenLDAP 2.3.37, you're strongly recommended to use syncrepl. 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#5113) pcache returns incomplete results
by ando＠sys-net.it 06 Sep '07

06 Sep '07

rhafer(a)suse.de wrote: > Hm, current HEAD first calls add_query, which adds the CachedQuery to the > cache and after that calls cache_entries to add the entries of that Query to > the cache. That means that query_containment already know about the Query > before its result is completely cached. > In RE23 it is just the other way arround (first cache_entries() then > add_query()). > I see two possible solution: > > 1. Switch back to the old behaviour. But I guess the change was made for a > reason. I don't know that yet. Seems the change happend between r1.95 and > r1.96 of pcache.c (log message: "Fix concurrency issues"). > > 2. Protect the cached query with an rw_lock. Writelock it while > cache_entries() is executing and readlock it during searches. This would give > us the behaviour that Ando suggested in the discussion of ITS#5112. (pcache > would not try to cache the same search request mulitple times, but block the > second request until the first one is cached and then answer it from the > cache) +1 (if there's no drawback, of course) 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs