openldap-bugs

openldap-bugs@openldap.org

1 participants
20958 discussions

Re: (ITS#4907) Syncrepl consumer failing to perform deletes
by hyc＠symas.com 03 Apr '07

03 Apr '07

Sean Burford wrote: > Hi, > > On 4/2/07, *Howard Chu* <hyc(a)symas.com <mailto:hyc@symas.com>> wrote: > > > I am attempting to set up syncrepl between two OpenLDAP 2.3.32 > servers. Adds > > and Modifies are replicated from the provider to the consumer, > but deletes > > result in thousands of "unknown filter type 136644788" messages > in the consumer > > log and no deletion. Commenting out the syncprov-sessionlog > directive works > > around the issue. > > I don't see this with 2.3.32 on Linux 2.6.18. You'll probably need to > trace the activity with gdb to see what's wrong with the filter. > > > Right you are. The patch for ITS#4638 (rejected here: > http://www.openldap.org/lists/openldap-bugs/200608/msg00043.html) > introduced the bug. I'll send in a corrected patch once it has been QA'd. The log says that ITS#4638 was already fixed in 2.3.32. Why are you still using that particular patch, given that an alternate solution is already present in the release? I also see that in RE23 we had one more patch to fix some interaction between slapo-rwm and back-meta for filter processing. I suggest you test against the current RE23 code. I expect to push 2.3.35 out pretty soon. -- -- 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#4907) Syncrepl consumer failing to perform deletes
by unix.gurus＠gmail.com 03 Apr '07

03 Apr '07

------=_Part_14849_31495008.1175634207921 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, On 4/2/07, Howard Chu <hyc(a)symas.com> wrote: > > > I am attempting to set up syncrepl between two OpenLDAP 2.3.32servers. Adds > > and Modifies are replicated from the provider to the consumer, but > deletes > > result in thousands of "unknown filter type 136644788" messages in the > consumer > > log and no deletion. Commenting out the syncprov-sessionlog directive > works > > around the issue. > > I don't see this with 2.3.32 on Linux 2.6.18. You'll probably need to > trace the activity with gdb to see what's wrong with the filter. Right you are. The patch for ITS#4638 (rejected here: http://www.openldap.org/lists/openldap-bugs/200608/msg00043.html) introduced the bug. I'll send in a corrected patch once it has been QA'd. -- Thanks, Sean Burford ------=_Part_14849_31495008.1175634207921 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,<br><br><div><span class="gmail_quote">On 4/2/07, <b class="gmail_sendername">Howard Chu</b> <<a href="mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > I am attempting to set up syncrepl between two OpenLDAP 2.3.32 servers.  Adds<br>> and Modifies are replicated from the provider to the consumer, but deletes<br>> result in thousands of "unknown filter type 136644788" messages in the consumer <br>> log and no deletion.  Commenting out the syncprov-sessionlog directive works<br>> around the issue.<br><br>I don't see this with 2.3.32 on Linux 2.6.18. You'll probably need to<br>trace the activity with gdb to see what's wrong with the filter. </blockquote><div><br> Right you are.  The patch for ITS#4638 (rejected here: <a href="http://www.openldap.org/lists/openldap-bugs/200608/msg00043.html">http://www.openldap.org/lists/openldap-bugs/200608/msg00043.html</a>) introduced the bug.  I'll send in a corrected patch once it has been QA'd. <br><br></div></div>-- <br>Thanks,<br>Sean Burford ------=_Part_14849_31495008.1175634207921--

1 0

RE: (ITS#4908) bug ldapsearch.c
by Dale.Moore＠cs.cmu.edu 03 Apr '07

03 Apr '07

> The bug is still present. It is a consequence of naively assuming that > argv[] is NULL terminated, which is not required to be, AFAIK. My spec for ANSI C (ISO/IEC 9899:1990 (E)) says on section 5.1.2.2.1 (page 7) - argv[argc] shall be a null pointer. Maybe my C spec is a little out of date.

1 0

Re: (ITS#4908) bug ldapsearch.c
by h.b.furuseth＠usit.uio.no 03 Apr '07

03 Apr '07

ando(a)sys-net.it writes: > The bug is still present. It is a consequence of naively assuming that > argv[] is NULL terminated, which is not required to be, AFAIK. Yes it is. The C standard's "Program Startup" section requires argv[argc] == NULL. Though I suppose some systems may break it. And the standard does allow argc == 0 (and thus argv[0] == NULL), maybe some OpenLDAP code mishandles that. -- Regards, Hallvard

1 0

Re: (ITS#4908) bug ldapsearch.c
by ando＠sys-net.it 03 Apr '07

03 Apr '07

quanah(a)stanford.edu wrote: > --On Tuesday, April 03, 2007 3:01 PM +0000 buwalgui(a)etu.univ-rouen.fr wrote: > >> Full_Name: Guillaume BUWALDA >> Version: 2.2.3 >> OS: Linux ubuntu > > > The current released version of OpenLDAP is 2.3.34. OpenLDAP 2.2.x is a > historic release. As such, bugs against it will not be investigated. If > you can reproduce this issue with the current release, then please follow > up. The bug is still present. It is a consequence of naively assuming that argv[] is NULL terminated, which is not required to be, AFAIK. 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#4908) bug ldapsearch.c
by quanah＠stanford.edu 03 Apr '07

03 Apr '07

--On Tuesday, April 03, 2007 3:01 PM +0000 buwalgui(a)etu.univ-rouen.fr wrote: > Full_Name: Guillaume BUWALDA > Version: 2.2.3 > OS: Linux ubuntu The current released version of OpenLDAP is 2.3.34. OpenLDAP 2.2.x is a historic release. As such, bugs against it will not be investigated. If you can reproduce this issue with the current release, then please follow up. Regards, Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4908) bug ldapsearch.c
by buwalgui＠etu.univ-rouen.fr 03 Apr '07

03 Apr '07

Full_Name: Guillaume BUWALDA Version: 2.2.3 OS: Linux ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.23.181.151) Hello, I do not know where I can send this message, so I send it to you... I found a little error in the source file client/tools/ldapsearch.c . gdb give me this bt: [Cacher les citations] Program received signal SIGSEGV, Segmentation fault. > 0xb7eb3c53 in strlen () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt > #0 0xb7eb3c53 in strlen () from /lib/tls/i686/cmov/libc.so.6 > #1 0xb7e40031 in ber_put_string () from /usr/lib/liblber.so.2 > #2 0xb7e40321 in ber_printf () from /usr/lib/liblber.so.2 > #3 0xb7f8a376 in ldap_build_search_req () from /usr/lib/libldap_r.so.2 > #4 0xb7f8a7fe in ldap_search_ext () from /usr/lib/libldap_r.so.2 when it calls the function ldap_search_ext(). I think the error comes from then "attrs" parameters of this function. At line 611 of the file: > if ( argv[optind] != NULL ) { > attrs = &argv[optind]; > } You may put the last element of the array at NULL. I did this and it work. I hope this message will help you, and I'm sorry for my very bad english... lol Good Luck Guillaume BUWALDA

1 0

Re: (ITS#4879) URL parse/unparse troubles
by h.b.furuseth＠usit.uio.no 03 Apr '07

03 Apr '07

Howard Chu writes: >> The url.c Novell kludge does not work (for the example URL). >> If the bug is old and nobody has complained, maybe it should be >> removed. If it's fixed instead, note that the code looks like >> it'll handle Novell URLs with '/' in components after hostport: >> ldap_url_parse_ext() does strchr( url, '/' ) very early to find >> the end of the hostport. > > Hm, I think I see what you mean, but I don't see what to do about that. I think we can just replace strchr(,'/') with strpbrk(,"/?") or strcspn and take it from there. And require '?' in ldapi filenames to be URL-escaped, if they are not already. Thank you, much easier to see now the rest of the mess is cleaned up:-) >> Converting "%00" to char* should return an error, since the char* >> will not match the source URL: >> >> ldapi://a%00b/cn=d%00e -> host "a", DN "cn=d" -> >> ldapi://a/cn=d??base > > I've left this alone for now. We can make ldap_pvt_hex_unescape() return success/failure instead of void (and the output URL would be undefined). At the same time also reject bad %escapes - see that function's comment * FIXME: what if '%' is followed * by non-hexpair chars? >> ================ >> >> The RFCs 4516/2255 hostport part has grammar [host [":" port]], >> but ldap_url_desc2str() produces [host][":" port]. >> >> ldap:// -> host NULL, port 389 -> >> ldap://:389/??base >> >> That's OK as an ldap_url_parse() OpenLDAP extension, but not as >> ldap_url_desc2str() output given to non-OpenLDAP applications. > > This is a mess. The ldap: scheme definition has always been broken, and > it certainly does not conform to the basic URI syntax in RFC3986 section > 3. In particular, RFC3986 forbids a URI from containing "//" when the > authority component is absent. Would it help to produce ldap://0:389/? Helps the syntax, but I don't know if host 0 or 0.0.0.0 for INADDR_ANY is OK or just another unportable hack. > Looks like RFC4516 should not have been approved in its current state. I'd say RFCs2255 should not have been, but RFC4516 should since it was too late; it didn't introduce any new bugs. -- Regards, Hallvard

1 0

Re: (ITS#4907) Syncrepl consumer failing to perform deletes
by hyc＠symas.com 02 Apr '07

02 Apr '07

unix.gurus(a)gmail.com wrote: > Full_Name: Sean Burford > Version: 2.3.32 > OS: Linux 2.4.20 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (65.57.245.11) > > > I am attempting to set up syncrepl between two OpenLDAP 2.3.32 servers. Adds > and Modifies are replicated from the provider to the consumer, but deletes > result in thousands of "unknown filter type 136644788" messages in the consumer > log and no deletion. Commenting out the syncprov-sessionlog directive works > around the issue. I don't see this with 2.3.32 on Linux 2.6.18. You'll probably need to trace the activity with gdb to see what's wrong with the filter. -- -- 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#4879) URL parse/unparse troubles
by hyc＠symas.com 02 Apr '07

02 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > Here are some URLs parsing/building bugs in libldap/url.c. > Some may be design bugs. Possibly some fixes will need backwards > bug-compatibility. > > I show URLs converted from string to LDAPURLDesc format with > ldap_url_parse(), back to string format with ldap_url_desc2str() > when the result differs from the original, back to LDAPURLDesc... > > ================ > > The url.c Novell kludge does not work (for the example URL). > If the bug is old and nobody has complained, maybe it should be > removed. If it's fixed instead, note that the code looks like > it'll handle Novell URLs with '/' in components after hostport: > ldap_url_parse_ext() does strchr( url, '/' ) very early to find > the end of the hostport. Hm, I think I see what you mean, but I don't see what to do about that. > ldap://111.222.333.444:389??cn=abc,o=company -> > error 5 (LDAP_URL_ERR_BADURL) This now works. > > Example URL without port number: > > ldap://111.222.333.444??cn=abc,o=company -> > host "111.222.333.444??cn=abc,o=company", DN NULL -> > ldap://111.222.333.444??cn=abc,o=company:389/??base This now works. > > ================ > > ldap_url_desc2str() outputs IPv6 host addresses as "addr" rather > than "[addr]". (LDAPURLDesc does not contain the '[]'s in > .lud_host, nor any flag which says it's an IPv6 host address). > > I don't know the syntax of such addresses, but I seem to remember > they contains ':'s. If so the parser could fail if an IPv6 > address does not contains ':', and the URL builder could test for > ':' to determine if there should be [] around the host part. This now works. > > Also, what does stuff between the ']' and ':port' mean? > Should anything be allowed there? > > ldap://[::1]what's this:222/ -> host "::1", port 222 -> This is now correctly rejected. > ldap://::1:222/??base -> error 5 (LDAP_URL_ERR_BADURL) > > ================ > > Converting "%00" to char* should return an error, since the char* > will not match the source URL: > > ldapi://a%00b/cn=d%00e -> host "a", DN "cn=d" -> > ldapi://a/cn=d??base I've left this alone for now. > ================ > > The RFCs 4516/2255 hostport part has grammar [host [":" port]], > but ldap_url_desc2str() produces [host][":" port]. > > ldap:// -> host NULL, port 389 -> > ldap://:389/??base > > That's OK as an ldap_url_parse() OpenLDAP extension, but not as > ldap_url_desc2str() output given to non-OpenLDAP applications. This is a mess. The ldap: scheme definition has always been broken, and it certainly does not conform to the basic URI syntax in RFC3986 section 3. In particular, RFC3986 forbids a URI from containing "//" when the authority component is absent. Looks like RFC4516 should not have been approved in its current state. > ================ > > While I'm writing, I wonder if OpenLDAP 2.4 could omit defaults > and final "?"s from the ldap_url_desc2str() output. E.g. ldap:// > would become ldap:// and not ldap://:389/??base. But maybe we get > into trouble if ldap.conf has another port or something. I thought about changing this, but left it alone for now. Agreed, the interaction with ldap.conf isn't clear. > ================ > > ldapi URL (un)parsing has several problems: > > ldap_url_parse() always treats ':' as a host:port separator. > Thus one can produce an ldapi LDAPURLDesc with a meaningless port. > However ldap_url_desc2str() does not URL-escape ':', and it also > takes port!=0 to mean it is not an ldapi URL and needs no > '/'-escaping. Similarly filenames with initial '[' do not work. > > ldapi://%2Ftmp%2Ffoo%3A222/ -> host "/tmp/foo:222" (correct) -> > ldapi://%2Ftmp%2Ffoo:222/??base -> host "/tmp/foo", port 222 -> > ldapi:///tmp/foo:222/??base -> host NULL, DN "tmp/foo:222/" > > ldapi://%2Ftmp%2Ffoo:000/ -> host "/tmp/foo" -> > ldapi://%2Ftmp%2Ffoo/??base > > ldapi://%2Ftmp%2Ffoo:bar/ -> error 5 (LDAP_URL_ERR_BADURL) These are all fixed. Note that the "ldapi:///tmp/foo:222/" case simply means an ldapi:// URL with a DN of "tmp/foo:222/" which is legal in a URL parsing sense, even though DN validation would reject it. > > ==== > > The current implementation would handle some non-Unix ldapi > filenames wrong. (They'll need well-defined URL-escaping rules > if they get implemented, so it might as well be fixed now.) Of > course these can also be strange Unix relative filenames... > > Windows-like filenames: > > ldapi://C%3A%2Fldapi/ -> host "C:/ldapi" -> > ldapi://C:%2Fldapi/??base -> error 5 (LDAP_URL_ERR_BADURL) > > Tops-20-like filenames resemble IPv6 addresses (not that I expect > to port OpenLDAP to Tops-20:-) > > ldapi://[ldap.var.run]ldapi/ -> host "ldap.var.run" -> > ldapi://ldap.var.run/??base > > URL-escaping the '[' and ']' does not help; the '[' is lost: > > ldapi://%5Bldap.var.run%5Dldapi/ -> host "ldap.var.run]ldapi" -> > ldapi://ldap.var.run%5Dldapi/??base > These are all fixed. -- -- 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

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