openldap-bugs June 2009

openldap-bugs@openldap.org

41 participants
115 discussions

(ITS#6190) back-meta tls start only works when set before any target specification
by stephan.duehr＠dass-it.de 30 Jun '09

30 Jun '09

Full_Name: Stephan Duehr Version: 2.4.16 OS: SLES 10 SP2 URL: Submission from: (NULL) (84.44.166.251) I specified tls start below each target specification and did not find any STARTTLS in the targets log, running at loglevel 256. man slapd-meta says: tls {[try-]start|[try-]propagate} execute the StartTLS extended operation when the connection is initialized; only works if the URI directive protocol scheme is not ldaps://. propagate issues the StartTLS operation only if the original connection did. The try- prefix instructs the proxy to continue operations if the StartTLS operation failed; its use is highly deprecated. If set before any target specification, it affects all targets, unless overridden by any per-target directive. So it should work when set for a target. I verified the behavior by removing start tls before any target specfication and setting it below each target, which resulted in not STARTTLS being sent again.

1 0

Re: (ITS#6084) ppolicy should allow scheduled password expiration
by hyc＠symas.com 30 Jun '09

30 Jun '09

Guillaume Rousse wrote: > Howard Chu a écrit : >> Since the ppolicy module's behavior is dictated by the Behera draft, any >> suggestions for changes in this area should probably first be raised on >> the ietf-ldapext mailing list. > Right, but openldap implementation already have extension, such > pwdCheckModule. Additional extension could be implemented, before > getting standardized. > > Also, the ietf-ldapext seems to be an highly-technical list, and I don't > feel confortable enough to post this kind of request directly there. > Discussing various limitations of ppolicy among openldap users first > would probably allow openldap core team to suggest a more polished > extension request themselves. The draft doesn't say anything about setting pwdAccountLockedTime to a value in the future; since it doesn't preclude it I've fixed up the code to handle this case. However, it's not a good solution for your purpose, since the pwdAccountLockedTime value is automatically replaced with the current time if too many Bind failures occur, and it's automatically deleted when a password is changed. We'll leave this in HEAD on an experimental basis for now, until a real solution is spec'd out. -- -- 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#6163) back-sql DoS when searching for empty attr
by stephane.chazelas＠seebyte.com 30 Jun '09

30 Jun '09

Hiya, see also https://bugs.launchpad.net/bugs/382677 Whole text included here: When using the SQL backend, a search like: ldapsearch ... '(cn=)' causes slapd to crash with this error: slapd: /tmp/openldap-2.4.15/servers/slapd/back-sql/search.c:1366: backsql_process_filter_attr: Assertion `0' failed. Looking at the code there, it does a switch(f->f_choice) { .... default: assert(0); } As it happens, in that instance f_choice is something like 0x80a3, that is SLAPD_FILTER_UNDEFINED|LDAP_FILTER_EQUALITY. And the back-sql backend doesn't support that SLAPD_FILTER_UNDEFINED flag like the other backends, hence the abort() on that assert. A work around for that (change in indentation not shown): --- search.c~ 2009-06-01 15:55:16.000000000 +0100 +++ servers/slapd/back-sql/search.c 2009-06-01 17:00:51.000000000 +0100 @@ -717,6 +717,9 @@ goto done; } + if (f->f_choice & SLAPD_FILTER_UNDEFINED) { + rc = -1; + } else { switch( f->f_choice ) { case LDAP_FILTER_OR: rc = backsql_process_filter_list( bsi, f->f_or, @@ -772,6 +775,7 @@ ad = f->f_av_desc; break; } + } if ( rc == -1 ) { goto done; That's only a work around. The fix would be to implement the support for such searches. Best regards, Stephane

1 0

Re: (ITS#6186) sizelimit broken
by h.b.furuseth＠usit.uio.no 29 Jun '09

29 Jun '09

Christian.Fischer(a)fischundfischer.com writes: > Args debugging showed me ors_slimit of 500 in all cases > (servers/slapd/search.c:do_search():123) Note that at this point the fields have just been parsed from the protocol message. So that's the limit as it was sent by the client. (From SIZELIMIT in ldap.conf, maybe?) If the client sends 500, limits_check() should not reset it. -- Hallvard

1 0

Re: (ITS#6186) sizelimit broken
by Christian.Fischer＠fischundfischer.com 29 Jun '09

29 Jun '09

On Monday 29 June 2009, Howard Chu wrote: > Unfortunately not. I was also unable to reproduce this behavior on 2.4.16 > or on current code. Without a clear way to illustrate the problem, we have > nothing to investigate. Yes, I understand this. > Likewise, since you mention that you're running > "patched slapd" we can't help you with that either. The patch sets ors_slimit = 0, nothing else. This is only FYI if someone runs into the same problem. Christian

1 0

Re: (ITS#6186) sizelimit broken
by hyc＠symas.com 29 Jun '09

29 Jun '09

Christian Fischer wrote: > On Wednesday 24 June 2009, Howard Chu wrote: > >> Your explanation is a bit unclear. Please provide an ldapsearch commandline >> that demonstrates the problem with the slapd.conf you provided. >> >> When a given sizelimit is configured on the server, what values of >> sizelimit requested by the client are working correctly or incorrectly? > > Due to all servers run a patched slapd and all are in productive state i've > set up 2 testsystems (provider - consumer). > > I can't reproduce the buggy behavior. > > Let me explain what i have done before submitting the bug report. > > I've set up two slapd in mirrormode and one as proxy and some customer slapd, > all unpatched. After working around ITS#6167 I've initiated the initial > customer replication with the proxy as peer and got a sizelimit of 500. I've > tried replication against one mirror, that failed with sizelimit 500. The > providers sizelimit was set to unlimited. > > I've tried replication with different sizelimit values, 10 gave me 10 entries > back, 500 gave me 500 back, 502 gave me 500 and -1 gave me 500 back. > > Args debugging showed me ors_slimit of 500 in all cases > (servers/slapd/search.c:do_search():123) > > Hope that helps Unfortunately not. I was also unable to reproduce this behavior on 2.4.16 or on current code. Without a clear way to illustrate the problem, we have nothing to investigate. Likewise, since you mention that you're running "patched slapd" we can't help you with that either. -- -- 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#6186) sizelimit broken
by Christian.Fischer＠fischundfischer.com 29 Jun '09

29 Jun '09

On Wednesday 24 June 2009, Howard Chu wrote: > Your explanation is a bit unclear. Please provide an ldapsearch commandline > that demonstrates the problem with the slapd.conf you provided. > > When a given sizelimit is configured on the server, what values of > sizelimit requested by the client are working correctly or incorrectly? Due to all servers run a patched slapd and all are in productive state i've set up 2 testsystems (provider - consumer). I can't reproduce the buggy behavior. Let me explain what i have done before submitting the bug report. I've set up two slapd in mirrormode and one as proxy and some customer slapd, all unpatched. After working around ITS#6167 I've initiated the initial customer replication with the proxy as peer and got a sizelimit of 500. I've tried replication against one mirror, that failed with sizelimit 500. The providers sizelimit was set to unlimited. I've tried replication with different sizelimit values, 10 gave me 10 entries back, 500 gave me 500 back, 502 gave me 500 and -1 gave me 500 back. Args debugging showed me ors_slimit of 500 in all cases (servers/slapd/search.c:do_search():123) Hope that helps Christian

1 0

Re: (ITS#5836) hung writers
by jorge.perez＠adaptia.net 29 Jun '09

29 Jun '09

--001636c5b621da4708046d784a4e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello, I still reproduce this problem with 2.4.17-prerelease. I have a client that request a lof of operations at the same time through a connection. The slapd seems to overload and finally close the connection sending a reset to the client and when this happens the connection hungs eating the CPU, blocked in the pthread_cond_wait in send_ldap_ber function at the same point of the first trace sent in this report. Best regards --001636c5b621da4708046d784a4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I still reproduce this problem with 2.4.17-prerelease. I have= a client that request a lof of operations at the same time through a conne= ction. The slapd seems to overload and finally close the connection sending= a reset to the client and when this happens the connection hungs eating th= e CPU, blocked in the pthread_cond_wait in send_ldap_ber function at the sa= me point of the first trace sent in this report. Best regards --001636c5b621da4708046d784a4e--

1 0

Re: (ITS#6189) test056 failure
by hyc＠symas.com 28 Jun '09

28 Jun '09

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: RE24/HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > See http://www.openldap.org/lists/openldap-devel/200906/msg00048.html > > Note that the proposed fix may mean revisiting ITS#3850. > Without the patch in HEAD, test056 failed after 21 iterations on my OpenSUSE system. With the patch it ran 1000 iterations successfully. -- -- 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

(ITS#6189) test056 failure
by hyc＠OpenLDAP.org 27 Jun '09

27 Jun '09

Full_Name: Howard Chu Version: RE24/HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc See http://www.openldap.org/lists/openldap-devel/200906/msg00048.html Note that the proposed fix may mean revisiting ITS#3850.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2009