openldap-bugs

openldap-bugs@openldap.org

1 participants
20968 discussions

Re: (ITS#7009) TIMEOUT with unexpected results
by masarati＠aero.polimi.it 10 Aug '11

10 Aug '11

> libldap's ldap_result() sets ld_errno to LDAP_TIMEOUT but returns 0, so > ldapsearch (and all tools) are fooled by not actually checking ld_errno > (actually, ldap_get_option(LDAP_OPT_RESULT_CODE)). Fixed in master. Also fixed timelimit (apparently, it was not honored). p.

1 0

Re: (ITS#7009) TIMEOUT with unexpected results
by masarati＠aero.polimi.it 10 Aug '11

10 Aug '11

> Full_Name: Bjoern Jacke > Version: 2.4.23 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.159.216.39) > > > When TIMEOUT is set and happend to occur there is nothing that shows that > we > timed out. For example if you do a large/slow LDAP search using ldapsearch > and > then stop the conversation between slapd and ldapsearch by "killall -STOP > slapd" > then ldapsearch will terminate after TIMEOUT seconds and it will return > the > number of records that it got so far and exit with return code 0 and not > error > message. I'd expect that after TIMEOUT occuring that we get a warning and > a > return code != 0 libldap's ldap_result() sets ld_errno to LDAP_TIMEOUT but returns 0, so ldapsearch (and all tools) are fooled by not actually checking ld_errno (actually, ldap_get_option(LDAP_OPT_RESULT_CODE)). p.

1 0

Re: (ITS#7007) sync: inconsistent directory when starting with emtpy node
by steffo76＠gmx.de 10 Aug '11

10 Aug '11

I'm sorry, in the meantime I found out that the binddn I used didn't have full access so the empty node couldn't get all attributes and then the broken directory got replicated back to the initial node. It was just a configuration problem on my part. Sorry again.

1 0

Re: (ITS#7012) Getting a core dump when TLSCertificateFile does not have an argument
by masarati＠aero.polimi.it 10 Aug '11

10 Aug '11

> I don't remember any particular reason why the argument count was omitted > here. Looking back over release 2.2 I don't see any special provision for > multiple arguments. I.e., it doesn't look like we need to accomodate > longer > argument lists here. And I don't see why we would want to NULL out any > existing settings. Sounds like we should just require argc == 2. Fixed in master, passes all tests for me. BTW, the original poster's address no longer exists, so I do not expect feedback. p.

1 0

Re: (ITS#7012) Getting a core dump when TLSCertificateFile does not have an argument
by hyc＠symas.com 10 Aug '11

10 Aug '11

masarati(a)aero.polimi.it wrote: >> No, thanks. The problem is that these specific statements do not >> prescribe a fixed number of arguments. Moreover, the function that uses >> the value resets the field when passed a NULL argument. If this behavior >> needs to be preserved, I have the right fix handy. Otherwise it might >> need more work. > > To be more specific: slapd's TLS configuration is registered without > enforcing a specific number of arguments. This check is delegated to the > underlying calls to ldap_pvt_tls_set_option() performed by > config_tls_option(). This poses two problems: > > - since the argument of these parameters is ARG_STRING, if no arg is > passed then ch_strdup() fails > > - fixing this (by skipping ch_strdup() if argc == 1, for example) results > in calling ldap_pvt_tls_set_option with a NULL value, which is a perfectly > legitimate value (it means: clear any existing value), but it may not be > appropriate in this context. > > Please advise whether the right fix is skip ch_strdup(), or enforcing a > requirement for argc == 2 for TLS-related fields. I don't remember any particular reason why the argument count was omitted here. Looking back over release 2.2 I don't see any special provision for multiple arguments. I.e., it doesn't look like we need to accomodate longer argument lists here. And I don't see why we would want to NULL out any existing settings. Sounds like we should just require argc == 2. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7012) Getting a core dump when TLSCertificateFile does not have an argument
by masarati＠aero.polimi.it 10 Aug '11

10 Aug '11

> No, thanks. The problem is that these specific statements do not > prescribe a fixed number of arguments. Moreover, the function that uses > the value resets the field when passed a NULL argument. If this behavior > needs to be preserved, I have the right fix handy. Otherwise it might > need more work. To be more specific: slapd's TLS configuration is registered without enforcing a specific number of arguments. This check is delegated to the underlying calls to ldap_pvt_tls_set_option() performed by config_tls_option(). This poses two problems: - since the argument of these parameters is ARG_STRING, if no arg is passed then ch_strdup() fails - fixing this (by skipping ch_strdup() if argc == 1, for example) results in calling ldap_pvt_tls_set_option with a NULL value, which is a perfectly legitimate value (it means: clear any existing value), but it may not be appropriate in this context. Please advise whether the right fix is skip ch_strdup(), or enforcing a requirement for argc == 2 for TLS-related fields. p.

1 0

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by matheus.morais＠gmail.com 09 Aug '11

09 Aug '11

--00163683235cdfe3c004aa1933e0 Content-Type: text/plain; charset=ISO-8859-1 This seems to be a little old but I had attached the patch to close this issue and now I realize that I should provide it in a Uniform Resource Locator (URL) just as http://www.openldap.org/devel/contributing.html explains. So here it goes: http://xsun.eti.br/openldap/ldapsearch1_man_page.patch Sorry for this mistake. Thanks. Matheus Morais On Tue, Aug 31, 2010 at 1:44 AM, Matheus Morais <matheus.morais(a)gmail.com>wrote: > Hi there, > > <quote> That's... bizarre. Even slapd doesn't behave that way. Nor any > other program comes immediately to mind. </quote> > > Even sounds like an strange behave, as Quanah said, this information should > be included on ldapsearch man page IMHO. > > I believe that the following patch could close this BUG: > > --- openldap/doc/man/man1/ldapsearch.1.orig 2010-08-31 > 01:25:23.000000000 -0300 > +++ openldap/doc/man/man1/ldapsearch.1 2010-08-31 01:37:50.000000000 > -0300 > @@ -7,6 +7,8 @@ > .SH SYNOPSIS > .B ldapsearch > [\c > +.BR \-V [ V ]] > +[\c > .BR \-n ] > [\c > .BR \-c ] > @@ -107,6 +109,11 @@ > Option \fI\-L\fP controls the format of the output. > .SH OPTIONS > .TP > +.BR \-V [ V ] > +Prints the ldapsearch version and proceeds with the search. > +.B \-VV > +Prints the ldapsearch version and quit. > +.TP > .B \-n > Show what would be done, but don't actually perform the search. Useful > for > debugging in conjunction with \fB\-v\fP. > > Please review it. > > Thanks, > > Matheus Morais > --00163683235cdfe3c004aa1933e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This seems to be a little old but I had attached the patch to close this is= sue and now I realize that I should provide it in a Uniform Resource Locato= r (URL) just as=A0<meta http-equiv=3D"content-type" content=3D"text/html; c= harset=3Dutf-8"><a href=3D"http://www.openldap.org/devel/contributing.html"= >http://www.openldap.org/devel/contributing.html</a>=A0explains.<div> <br></div><div>So here it goes:</div><div><br></div><div><a href=3D"http://= xsun.eti.br/openldap/ldapsearch1_man_page.patch">http://xsun.eti.br/openlda= p/ldapsearch1_man_page.patch</a></div><div><br></div><div>Sorry for this mi= stake.</div> <div><br></div><div>Thanks.</div><div>Matheus Morais</div><div><br><div cla= ss=3D"gmail_quote">On Tue, Aug 31, 2010 at 1:44 AM, Matheus Morais <span di= r=3D"ltr"><<a href=3D"mailto:matheus.morais@gmail.com">matheus.morais@gm= ail.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">Hi there,<br><br><quote> That's..= . bizarre. Even slapd doesn't behave that way. Nor any other program = comes immediately to mind. </quote><br> <br>Even sounds like an strange behave, as Quanah said, this information sh= ould be included on ldapsearch man page IMHO.<br> <br>I believe that the following patch could close this BUG:<br><br>--- ope= nldap/doc/man/man1/ldapsearch.1.orig=A0=A0=A0 2010-08-31 01:25:23.000000000= -0300<br>+++ openldap/doc/man/man1/ldapsearch.1=A0=A0=A0 2010-08-31 01:37:= 50.000000000 -0300<br> @@ -7,6 +7,8 @@<br>=A0.SH SYNOPSIS<br>=A0.B ldapsearch<br>=A0[\c<br>+.BR \-= V [ V ]]<br>+[\c<br>=A0.BR \-n ]<br>=A0[\c<br>=A0.BR \-c ]<br>@@ -107,6 +10= 9,11 @@<br>=A0Option \fI\-L\fP controls the format of the output.<br>=A0.SH= OPTIONS<br> =A0.TP<br>+.BR \-V [ V ]<br>+Prints the ldapsearch version and proceeds wit= h the search.<br>+.B \-VV<br>+Prints the ldapsearch version and quit.<br>+.= TP<br>=A0.B \-n<br>=A0Show what would be done, but don't actually perfo= rm the search.=A0 Useful for<br> =A0debugging in conjunction with \fB\-v\fP.<br><br>Please review it.<br><br= >Thanks,<br><font color=3D"#888888"><br>Matheus Morais<br> </font></blockquote></div><br></div> --00163683235cdfe3c004aa1933e0--

1 0

Re: (ITS#7012) Getting a core dump when TLSCertificateFile does not have an argument
by masarati＠aero.polimi.it 09 Aug '11

09 Aug '11

> Full_Name: Ashish Gawarikar > Version: 2.4.23 > OS: Redhat 5.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.253.98.197) > > > In my slapd.conf file: > ... > TLSCertificateFile > TLSCertificateKeyFile > ... > > If I have the above, I get a core dump, with the error: > slapd: ch_malloc.c:123: ch_strdup: Assertion `0' failed. > > > Let me know if you need the core file. No, thanks. The problem is that these specific statements do not prescribe a fixed number of arguments. Moreover, the function that uses the value resets the field when passed a NULL argument. If this behavior needs to be preserved, I have the right fix handy. Otherwise it might need more work. p.

1 0

(ITS#7014) TLS: certificate hostnames are being checked when TLS_REQCERT is se to allow
by jvcelak＠redhat.com 09 Aug '11

09 Aug '11

Full_Name: Jan Vcelak Version: master OS: Linux URL: http://jvcelak.fedorapeople.org/openldap/0001-TLS-do-not-check-hostname-whe… Submission from: (NULL) (209.132.186.34) Hello. If server certificate hostname does not match the server hostname, connection is closed even if client has set TLS_REQCERT to 'allow'. This is wrong - the documentation says, that bad certificates are being ignored when TLS_REQCERT is set to 'allow'. (Other certificate failures (like invalid CA) are handled as expected - at least with MozNSS.) I'm attaching patch, which fixes this behavior. The patch applies on master branch. (OpenLDAP FTP server for incoming patches reports 'No space left on device.', that's why I uploaded the patch to fedorapeople.org.) Regards, Jan

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu 08 Aug '11

08 Aug '11

--On Tuesday, August 02, 2011 02:16:27 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > Sounds like this may be related to ITS#6817. Please try adding a > dummy binddn to your idassert-bind directive and re-test. And, at Quanah's prompting I tried it with an empty empty binddn and got similar results. Still a failure, sometimes after returning 1000 entries, sometimes after returning 2000 entries. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

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