openldap-bugs June 2011

openldap-bugs@openldap.org

35 participants
131 discussions

Re: (ITS#6974) Possible segfault in back-monitor
by ondrej.kuznik＠acision.com 16 Jun '11

16 Jun '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/16/2011 11:23 AM, openldap-its(a)OpenLDAP.org wrote: > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Also, in the same file, there are superfluous asserts (assert for a non-null pointer after dereferencing that same pointer) at lines 1233 and 1370. They might be considered documentation, though. - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk35zF0ACgkQ9GWxeeH+cXsIpACglIHvpX9HCWeNL9k6/d7fn9DJ 3I8AnAuxriR7HbUTjRGFXw/qo49tEZPV =Jb1D -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

(ITS#6974) Possible segfault in back-monitor
by ondrej.kuznik＠acision.com 16 Jun '11

16 Jun '11

Full_Name: Ondrej Kuznik Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/ondrej-kuznik-20110616.patch Submission from: (NULL) (62.168.56.1) There is a minute chance of crashing OpenLDAP when registering a monitor callback while the monitor is dormant. See URL for a suggested patch. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010 Acision 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#6892) Segfault in Syncprov overlay
by ghola＠rebelbase.com 15 Jun '11

15 Jun '11

I'm unable to reproduce this problem with the latest syncrepl.c from git.

1 0

Re: (ITS#6973) Problem with sssvlv overlay and ldapsearch
by ctcard＠hotmail.com 15 Jun '11

15 Jun '11

--_41ab47cd-3d88-4bfe-b11d-afb7d8b14738_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable sorry=2C I mistyped my email address=2C it should be ctcard(a)hotmail.com = = --_41ab47cd-3d88-4bfe-b11d-afb7d8b14738_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style> </head> <body class=3D'hmmessage'> sorry=2C I mistyped my email address=2C it should be ctcard(a)hotmail.com = </body> </html>= --_41ab47cd-3d88-4bfe-b11d-afb7d8b14738_--

1 0

Fwd: Re: (ITS#6968) Glue objectclass created during Grouper provisioning
by hyc＠symas.com 15 Jun '11

15 Jun '11

User error, closing. -------- Original Message -------- Subject: Re: (ITS#6968) Glue objectclass created during Grouper provisioning Date: Wed, 15 Jun 2011 10:40:32 +0100 From: Mark Cairney <Mark.Cairney(a)ed.ac.uk> To: Howard Chu <hyc(a)symas.com> Hi, > > Then please strip out those attributes and objectclasses and verify that the LDIF file still reproduces the problem. I can't do this at the moment as this system will be going live imminently however I think I've tracked down the root cause of the problem. One of our servers was going to Redhat for it's NTP sync rather than the same local source as the others so it's clock was slightly skewed in relation. The issue now seems to no longer be occuring having thrown some fairly large LDIFs as the server as a test. >> > Just clicking on the link in any web browser. Also using the link with wget. Either way authentication is requested. >> I've moved the zip if you still want to take a look but given the cause I'm happy for the issue to be closed. IMO it was probably premature raising it as a bug but I was advised to on the list! I'll reply to my post on the list with the cause/solution for completeness. Kind regards, Mark -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

(ITS#6973) Problem with sssvlv overlay and ldapsearch
by ctcard＠hotmal.com 14 Jun '11

14 Jun '11

Full_Name: Chris Card Version: 2.4.23 OS: Centos 5.4 URL: Submission from: (NULL) (91.194.158.133) I am running slapd with a bdb back end, and using ldapsearch to query it. My ldapsearch command looks like this: ldapsearch -h localhost -x -b "..........." -D ".........." -w .... -E \!sss=mail:caseIgnoreIA5Match -E \!vlv=0/10/0/10 which returns the first 11 records and then prompts: # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.474 false MAMKAQA= sortResult: (0) Success control: 2.16.840.1.113730.3.4.10 false MA8CAQACATkCAQAEBOhhowg= vlvResult: pos=0 count=57 context=6GGjCA== (0) Success # numResponses: 12 # numEntries: 11 Press [before/after(/offset/count|:value)] Enter for the next window. Then, when I press Enter ldapsearch outputs the following and exits: # extended LDIF # # LDAPv3 # base <......> with scope subtree # filter: (objectclass=*) # requesting: ALL # with server side sorting critical control # with virtual list view critical control: 0/10/10/57 # # search result search: 3 result: 4 Size limit exceeded # numResponses: 1 If I then try the search again ldapsearch outputs: # extended LDIF # # LDAPv3 # base <......> with scope subtree # filter: (objectclass=*) # requesting: ALL # with server side sorting critical control # with virtual list view critical control: 0/10/0/10 # # search result search: 2 result: 51 Server is busy text: Other sort requests already in progress # numResponses: 1 The "Size limit exceeded" error appears to come from slap_send_search_entry() in result.c: if ( op->ors_slimit >= 0 && rs->sr_nentries >= op->ors_slimit ) { return LDAP_SIZELIMIT_EXCEEDED; } because op->ors_slimit is 0 instead of SLAP_NO_LIMIT (-1). If I do the ldapsearch with an explicit size limit, using the -z flag, e.g. ldapsearch -h localhost -x -b "..........." -D ".........." -w .... -E \!sss=mail:caseIgnoreIA5Match -E \!vlv=0/10/0/10 -z 20 then I don't get the "Size limit exceeded" error, and all the records are output by ldapsearch with a prompt after each set of 11 records, but after all the records have been output there is a different error before ldapsearch exits: # extended LDIF # # LDAPv3 # base <dc=blackspider,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # with server side sorting critical control # with virtual list view critical control: 0/10/60/57 # # search result search: 8 result: 76 Virtual List View error control: 2.16.840.1.113730.3.4.10 false MA8CATICATkCAU0EBHBFIQo= vlvResult: pos=50 count=57 context=cEUhCg== (77) Unknown error # numResponses: 1 and again a subsequent ldapsearch request gets the "Server is busy" error.

1 0

Re: (ITS#6657) back-sql segfault in backsql_search
by hyc＠symas.com 14 Jun '11

14 Jun '11

Timo Teräs wrote: > On 06/14/2011 08:24 AM, hyc(a)symas.com wrote: >> On Tue, Jun 14, 2011 at 08:16:18AM +0300, Timo Ter?s wrote: >>> On 06/13/2011 11:56 PM, Howard Chu wrote: >>>> timo.teras(a)iki.fi wrote: >>>>> ITS#6691 seems to be same issue. >>>>> >>>>> I have a patch to fix this. >>>>> >>>>> It's available at: >>>>> http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-bac… >>>>> >>>> Thanks for the patch, now in git master. >>> >>> Good. Though, it would have been polite to credit me as the commit author. >> >> You were credited in the release branch. > > Oh, right. > >> In the future use git format-patch and things like this won't get overlooked. > > I did not have the git tree available on the 64-bit machine I was given > to work with. And at that point I did not even know which version > control you used. You are expected to have read this already before submitting code: http://www.openldap.org/devel/contributing.html -- -- 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#6657) back-sql segfault in backsql_search
by timo.teras＠iki.fi 13 Jun '11

13 Jun '11

On 06/14/2011 08:24 AM, hyc(a)symas.com wrote: > On Tue, Jun 14, 2011 at 08:16:18AM +0300, Timo Ter?s wrote: >> On 06/13/2011 11:56 PM, Howard Chu wrote: >>> timo.teras(a)iki.fi wrote: >>>> ITS#6691 seems to be same issue. >>>> >>>> I have a patch to fix this. >>>> >>>> It's available at: >>>> http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-bac… >>>> >>> Thanks for the patch, now in git master. >> >> Good. Though, it would have been polite to credit me as the commit author. > > You were credited in the release branch. Oh, right. > In the future use git format-patch and things like this won't get overlooked. I did not have the git tree available on the 64-bit machine I was given to work with. And at that point I did not even know which version control you used. git commit does have --author="" switch, so it's very easy to set the patch author properly even if it's not in git patch format.

1 0

Re: (ITS#6657) back-sql segfault in backsql_search
by hyc＠symas.com 13 Jun '11

13 Jun '11

On Tue, Jun 14, 2011 at 08:16:18AM +0300, Timo Ter?s wrote: > On 06/13/2011 11:56 PM, Howard Chu wrote: > > timo.teras(a)iki.fi wrote: > >> ITS#6691 seems to be same issue. > >> > >> I have a patch to fix this. > >> > >> It's available at: > >> http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-bac… > >> > > Thanks for the patch, now in git master. > > Good. Though, it would have been polite to credit me as the commit author. You were credited in the release branch. In the future use git format-patch and things like this won't get overlooked. > > Thanks, > Timo

1 0

RE: (ITS#6964) ./configure bug when specifying openssl as the TLS library to use
by the_uhu＠hotmail.com 13 Jun '11

13 Jun '11

--_d1f53d59-c756-486d-94a1-c6fa39a61c52_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=2C Am wondering what I am missing here? Because to get OpenLDAP to compile wit= h openssl as the TLS library to use=2C I had change this line. You said that line 19408 on your copy of configure is not the LIBS line bel= ow even though I downloaded openldap fresh - could you offer an explanation= please? Paul. From: the_uhu(a)hotmail.com To: openldap-its(a)openldap.org Subject: RE: (ITS#6964) ./configure bug when specifying openssl as the TLS = library to use Date: Thu=2C 9 Jun 2011 00:16:10 +0000 I've just downloaded openldap stable fresh=2C opened up configure and this = is at line 19408 without an if check: LIBS=3D"-lssl -lcrypto -lRSAglue -lrsaref $LIBS" Also checked the source repository on the website and it's there also. Can you please double check? Paul. > Date: Wed=2C 8 Jun 2011 22:13:55 +0000 > From: openldap-its(a)OpenLDAP.org > To: the_uhu(a)hotmail.com > Subject: Re: (ITS#6964) ./configure bug when specifying openssl as the TL= S library to use >=20 > I don't know where your configure script came from=2C but there's nothing= related > to OpenSSL at line 19408 of the current released configure script=2C and = our > script has had logic to detect -lrsaref since 1999. >=20 > Closing this ITS. Use the actual configure script supplied by the OpenLDA= P > Project. = --_d1f53d59-c756-486d-94a1-c6fa39a61c52_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style> </head> <body class=3D'hmmessage'> Hi=2C Am wondering what I am missing here? Because to get OpenLDAP t= o compile with openssl as the TLS library to use=2C I had change this line.= You said that line 19408 on your copy of configure is not the LIBS = line below even though I downloaded openldap fresh - could you offer an exp= lanation please? Paul. <hr id=3D"stopSpelling">From: the_uhu@= hotmail.com To: openldap-its(a)openldap.org Subject: RE: (ITS#6964) ./c= onfigure bug when specifying openssl as the TLS library to use Date: Thu= =2C 9 Jun 2011 00:16:10 +0000 <meta http-equiv=3D"Content-Type" content=3D"text/html=3B charset=3Dunicode= "> <meta name=3D"Generator" content=3D"Microsoft SafeHTML"> <style> .ExternalClass .ecxhmmessage P {padding:0px=3B} .ExternalClass body.ecxhmmessage {font-size:10pt=3Bfont-family:Tahoma=3B} </style> I've just downloaded openldap stable fresh=2C opened up configure and this = is at line 19408 without an if check: LIBS=3D"-lssl -lcrypto -lRSAgl= ue -lrsaref $LIBS" Also checked the source repository on the website= and it's there also. Can you please double check? Paul. <= br> &gt=3B Date: Wed=2C 8 Jun 2011 22:13:55 +0000 &gt=3B From: openld= ap-its(a)OpenLDAP.org &gt=3B To: the_uhu(a)hotmail.com &gt=3B Subject: Re= : (ITS#6964) ./configure bug when specifying openssl as the TLS library to = use &gt=3B &gt=3B I don't know where your configure script came from= =2C but there's nothing related &gt=3B to OpenSSL at line 19408 of the c= urrent released configure script=2C and our &gt=3B script has had logic = to detect -lrsaref since 1999. &gt=3B &gt=3B Closing this ITS. Use t= he actual configure script supplied by the OpenLDAP &gt=3B Project. = </body> </html>= --_d1f53d59-c756-486d-94a1-c6fa39a61c52_--

1 0

← Newer
1
2
3
4
5
6
7
8
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2011