June 2009 - openldap-bugs

(ITS#6190) back-meta tls start only works when set before any target specification

by stephan.duehr＠dass-it.de

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.

13 years, 11 months

1
0
0 / 0

Re: (ITS#6084) ppolicy should allow scheduled password expiration

by hyc＠symas.com

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/

13 years, 11 months

1
0
0 / 0

Re: (ITS#6163) back-sql DoS when searching for empty attr

by stephane.chazelas＠seebyte.com

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

13 years, 11 months

1
0
0 / 0

Re: (ITS#6186) sizelimit broken

by h.b.furuseth＠usit.uio.no

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

13 years, 11 months

1
0
0 / 0

Re: (ITS#6186) sizelimit broken

by Christian.Fischer＠fischundfischer.com

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

13 years, 11 months

1
0
0 / 0

Re: (ITS#6186) sizelimit broken

by hyc＠symas.com

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/

13 years, 11 months

1
0
0 / 0

Re: (ITS#6186) sizelimit broken

by Christian.Fischer＠fischundfischer.com

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

13 years, 11 months

1
0
0 / 0

Re: (ITS#5836) hung writers

by jorge.perez＠adaptia.net

--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--

13 years, 11 months

1
0
0 / 0

Re: (ITS#6189) test056 failure

by hyc＠symas.com

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/

13 years, 11 months

1
0
0 / 0

(ITS#6189) test056 failure

by hyc＠OpenLDAP.org

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.

13 years, 11 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2009