openldap-bugs December 2008

openldap-bugs@openldap.org

36 participants
131 discussions

Re: slapd hanging upon shutdown (ITS#5841)
by h.b.furuseth＠usit.uio.no 08 Dec '08

08 Dec '08

Yes, this sounds familiar. I guess I mentioned it but didn't have time to check it. The offending if() comes from tpool.c rev 1.81, which was apparently a wrong fix to ITS#5194. rev 1.82 was the right fix. (Except I'm not so sure it was the _complete_ fix - might need to lock ldap_pvt_thread_pool_mutex while changing or even accessing *tpool, or something like that...) Anyway, the patch looks correct to me, undoing rev 1.81. The current code is clear enough in retrospect - a thread pool pause in halts pool_destroy() since pool_resume() doesn't broadcast - and thus a cn=config update (or access?) aborts slapd shutdown:-( -- Hallvard

1 0

Re: slapd hanging upon shutdown (ITS#5841)
by rhafer＠suse.de 08 Dec '08

08 Dec '08

Am Freitag 05 Dezember 2008 09:07:53 schrieb Howard Chu: > I seem to recall there was a race such that the condvar had already been > destroyed before it got here. Don't remember the details at the moment, and > not in a position to look it up either, but perhaps trawling thru -devel > will reveal it. Sounds like something Hallvard brought up in the past. I failed to see how such a race could happen with the current code in HEAD. The condvar is only destroyed after ltp_open_count decreased to 0. There might have been such problems when _thread_pool_destroy just used a simple if statement (instead of a while loop) for checking ltp_open_count. But that has been changed long ago, as part of ITS#4943. Maybe Hallvard can shed some light on this. -- regards, Ralf

1 0

(ITS#5850) adding a new server to ammr pool switches mirror-mode off
by ando＠sys-net.it 06 Dec '08

06 Dec '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando When adding a new value to olcSyncrepl to a member of a mmr pool, in order to configure a new pool member, olcMirrorMode is automatically reset since the URI of the new olcSyncrepl differs from the olcServerID. A workaround consists in explicitly reseting olcMirrorMode to TRUE within the same modify operation. p.

1 0

Re: (ITS#5849) memory leak when using client certificates
by dhawes＠vt.edu 05 Dec '08

05 Dec '08

dhawes(a)vt.edu wrote: > dhawes(a)vt.edu wrote: >> Full_Name: David Hawes >> Version: 2.4.13 >> OS: Debian GNU/Linux 4.0 >> URL: >> Submission from: (NULL) (98.117.88.57) >> >> >> As outlined at: >> >> http://www.openldap.org/lists/openldap-software/200811/msg00136.html >> >> OpenLDAP 2.4 leaks memory when TLS client certificates are used. Running slapd >> under valgrind yields the following: >> >> ==13311== 4,906 (92 direct, 4,814 indirect) bytes in 1 blocks are >> definitely lost in loss record 19 of 23 >> ==13311== at 0x401D898: malloc (vg_replace_malloc.c:207) >> ==13311== by 0x41FCCC4: default_malloc_ex (mem.c:79) >> ==13311== by 0x41FD33F: CRYPTO_malloc (mem.c:304) >> ==13311== by 0x428CA65: asn1_item_ex_combine_new (tasn_new.c:191) >> ==13311== by 0x428C79C: ASN1_item_ex_new (tasn_new.c:85) >> ==13311== by 0x428ECAA: ASN1_item_ex_d2i (tasn_dec.c:399) >> ==13311== by 0x428E5F9: ASN1_item_d2i (tasn_dec.c:134) >> ==13311== by 0x4286A57: d2i_X509 (x_x509.c:136) >> ==13311== by 0x4194F26: ssl3_get_client_certificate (s3_srvr.c:2521) >> ==13311== by 0x4191897: ssl3_accept (s3_srvr.c:462) >> ==13311== by 0x41AD930: SSL_accept (ssl_lib.c:867) >> ==13311== by 0x815D00E: ldap_pvt_tls_accept (tls.c:1594) >> ==13311== by 0x8076926: connection_read_thread (connection.c:1286) >> ==13311== by 0x813CEE5: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==13311== by 0x415823F: start_thread (in >> /lib/tls/i686/cmov/libpthread-2.3.6.so) >> ==13311== by 0x43ED49D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so) >> >> Philip Guenther notes: >> >> In 2.4.x, tls_get_cert_dn() leaks a reference to the client's X509 cert: >> the call to SSL_get_peer_certificate() in tls_get_cert() increments the >> reference count on the cert and it never gets decremented by a call to >> X509_free(). Simply adding the call there might not be safe, depending on >> whether the berval that tls_get_cert_dn() sets up relies on the underlying >> X509 to stay valid for longer than this chain of calls, as the X509 may be >> invalidated by a rehandshake. > > Calling X509_free(x) before the return statement in tls_get_cert_dn() > does fix the memory leak, though I do not know if this is proper, as > Philip noted. My apologies for not checking the ITS before sending that message. The fix in HEAD works.

1 0

Re: (ITS#5849) memory leak when using client certificates
by dhawes＠vt.edu 05 Dec '08

05 Dec '08

dhawes(a)vt.edu wrote: > Full_Name: David Hawes > Version: 2.4.13 > OS: Debian GNU/Linux 4.0 > URL: > Submission from: (NULL) (98.117.88.57) > > > As outlined at: > > http://www.openldap.org/lists/openldap-software/200811/msg00136.html > > OpenLDAP 2.4 leaks memory when TLS client certificates are used. Running slapd > under valgrind yields the following: > > ==13311== 4,906 (92 direct, 4,814 indirect) bytes in 1 blocks are > definitely lost in loss record 19 of 23 > ==13311== at 0x401D898: malloc (vg_replace_malloc.c:207) > ==13311== by 0x41FCCC4: default_malloc_ex (mem.c:79) > ==13311== by 0x41FD33F: CRYPTO_malloc (mem.c:304) > ==13311== by 0x428CA65: asn1_item_ex_combine_new (tasn_new.c:191) > ==13311== by 0x428C79C: ASN1_item_ex_new (tasn_new.c:85) > ==13311== by 0x428ECAA: ASN1_item_ex_d2i (tasn_dec.c:399) > ==13311== by 0x428E5F9: ASN1_item_d2i (tasn_dec.c:134) > ==13311== by 0x4286A57: d2i_X509 (x_x509.c:136) > ==13311== by 0x4194F26: ssl3_get_client_certificate (s3_srvr.c:2521) > ==13311== by 0x4191897: ssl3_accept (s3_srvr.c:462) > ==13311== by 0x41AD930: SSL_accept (ssl_lib.c:867) > ==13311== by 0x815D00E: ldap_pvt_tls_accept (tls.c:1594) > ==13311== by 0x8076926: connection_read_thread (connection.c:1286) > ==13311== by 0x813CEE5: ldap_int_thread_pool_wrapper (tpool.c:663) > ==13311== by 0x415823F: start_thread (in > /lib/tls/i686/cmov/libpthread-2.3.6.so) > ==13311== by 0x43ED49D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so) > > Philip Guenther notes: > > In 2.4.x, tls_get_cert_dn() leaks a reference to the client's X509 cert: > the call to SSL_get_peer_certificate() in tls_get_cert() increments the > reference count on the cert and it never gets decremented by a call to > X509_free(). Simply adding the call there might not be safe, depending on > whether the berval that tls_get_cert_dn() sets up relies on the underlying > X509 to stay valid for longer than this chain of calls, as the X509 may be > invalidated by a rehandshake. Calling X509_free(x) before the return statement in tls_get_cert_dn() does fix the memory leak, though I do not know if this is proper, as Philip noted.

1 0

Re: add option for setting minimum TLS/SSL protocol (ITS#5655)
by guenther＠sendmail.com 04 Dec '08

04 Dec '08

I could have sworn I had uploaded the revised version of the patch back in August after some cleaning by Kurt, but have no way of confirming it. So I've uploaded it again as guenther-20081204.patch.

1 0

(ITS#5849) memory leak when using client certificates
by dhawes＠vt.edu 04 Dec '08

04 Dec '08

Full_Name: David Hawes Version: 2.4.13 OS: Debian GNU/Linux 4.0 URL: Submission from: (NULL) (98.117.88.57) As outlined at: http://www.openldap.org/lists/openldap-software/200811/msg00136.html OpenLDAP 2.4 leaks memory when TLS client certificates are used. Running slapd under valgrind yields the following: ==13311== 4,906 (92 direct, 4,814 indirect) bytes in 1 blocks are definitely lost in loss record 19 of 23 ==13311== at 0x401D898: malloc (vg_replace_malloc.c:207) ==13311== by 0x41FCCC4: default_malloc_ex (mem.c:79) ==13311== by 0x41FD33F: CRYPTO_malloc (mem.c:304) ==13311== by 0x428CA65: asn1_item_ex_combine_new (tasn_new.c:191) ==13311== by 0x428C79C: ASN1_item_ex_new (tasn_new.c:85) ==13311== by 0x428ECAA: ASN1_item_ex_d2i (tasn_dec.c:399) ==13311== by 0x428E5F9: ASN1_item_d2i (tasn_dec.c:134) ==13311== by 0x4286A57: d2i_X509 (x_x509.c:136) ==13311== by 0x4194F26: ssl3_get_client_certificate (s3_srvr.c:2521) ==13311== by 0x4191897: ssl3_accept (s3_srvr.c:462) ==13311== by 0x41AD930: SSL_accept (ssl_lib.c:867) ==13311== by 0x815D00E: ldap_pvt_tls_accept (tls.c:1594) ==13311== by 0x8076926: connection_read_thread (connection.c:1286) ==13311== by 0x813CEE5: ldap_int_thread_pool_wrapper (tpool.c:663) ==13311== by 0x415823F: start_thread (in /lib/tls/i686/cmov/libpthread-2.3.6.so) ==13311== by 0x43ED49D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so) Philip Guenther notes: In 2.4.x, tls_get_cert_dn() leaks a reference to the client's X509 cert: the call to SSL_get_peer_certificate() in tls_get_cert() increments the reference count on the cert and it never gets decremented by a call to X509_free(). Simply adding the call there might not be safe, depending on whether the berval that tls_get_cert_dn() sets up relies on the underlying X509 to stay valid for longer than this chain of calls, as the X509 may be invalidated by a rehandshake.

1 0

ITS#5847 back-ndb indexing
by hyc＠symas.com 04 Dec '08

04 Dec '08

This is a known limitation in the current version of back-ndb. (See this message for further details http://www.openldap.org/lists/openldap-devel/200810/msg00094.html ) Note that back-ndb is marked "Experimental". You should not use it unless you're prepared to write fixes for it.

1 0

Re: (ITS#5845) Distribution List support for OpenLDAP schema
by bejnet＠yahoo.com 03 Dec '08

03 Dec '08

--0-334172624-1228364660=:46006 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Andrew for the reply.=0A=0A=0AQMail schema didn't seem to work for a= distribution list. I am looking for other options as well.=0A=0AI agree th= at this is a mail system issue. I am using Exim/Dovecot for mails. I though= t it was the LDAP which gets the group mail id from the address book for th= e Mail Client. Eg. In Outlook+AD+Exchange we have the CTRL+K option which g= ets the group id that points to more than one mailing address. I think ther= e is a basic understanding between Exchange and AD that does the trick.=0A= =0AWith Regards=0ABejoy=0A=0A=0A=0A________________________________=0AFrom:= Andrew Findlay <andrew.findlay(a)skills-1st.co.uk>=0ATo: bejnet(a)yahoo.com=0A= Cc: openldap-its(a)openldap.org=0ASent: Wednesday, 3 December, 2008 2:02:05 P= M=0ASubject: Re: (ITS#5845) Distribution List support for OpenLDAP schema= =0A=0AOn Wed, Dec 03, 2008 at 05:02:52AM +0000, bejnet(a)yahoo.com wrote:=0A= =0A> I want to create distribution list in OpenLDAP. Meaning - If I have a = group=0A> called admins(a)ldap.com and there are two members - bejoy(a)ldap.com= and=0A> bejnet(a)ldap.com; and mail is sent to admins(a)ldap.com =3D both thes= e members must=0A> get the email. Exchange has this feature. This mail id s= hould have a display=0A> name feature as well - that would show up on searc= h of address books.=0A> =0A> At present the work around is using qmail's sc= hema for this distribution list. I=0A> believe inetOrgPerson schema could h= ave a group version too - which would need a=0A> compulsory attribute calle= d members which must have atleast one member mentioned=0A> under it.=0A=0AI= think you have just described groupOfNames. I do not like groupOfNames=0A*= because* it makes the member attribute mandatory, which makes management=0A= complicated.=0A=0AAnyway, I cannot see this as a defect in OpenLDAP. LDAP s= chema is=0Aextensible: if you want something that is not in the standard se= t=0Ayou can add it locally. You say that you have used qmail's schema:=0Ais= there anything wrong with that?=0A=0AMost LDAP-capable mail systems can be= persuaded to use groups as=0Amailing lists, but that is a mail system issu= e not an OpenLDAP one.=0AIt could be argued that simple groups are not rich= enough to use=0Afor list expansion (no way to keep track of per-member lis= t=0Apreferences etc) but if we are going to talk about defining an=0Aimprov= ed group this is the wrong place to do it: maybe IETF's=0Aldapext list woul= d be better.=0A=0AAndrew=0A-- =0A------------------------------------------= -----------------------------=0A| From Andrew Findlay, Skil= ls 1st Ltd |=0A| Consultant in large-scale systems, network= s, and directory services |=0A| http://www.skills-1st.co.uk/ = +44 1628 782565 |=0A-----------------------------------------------= ------------------------=0A=0A=0A=0A From Chandigarh to Chennai - find= friends all over India. Go to http://in.promos.yahoo.com/groups/citygroups= / --0-334172624-1228364660=:46006 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"></style></he= ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon= t-size:12pt"><div>Thanks Andrew for the reply. </div><div style=3D"font-= family: times new roman,new york,times,serif; font-size: 12pt;"> QMail s= chema didn't seem to work for a distribution list. I am looking for other o= ptions as well. I agree that this is a mail system issue. I am using= Exim/Dovecot for mails. I thought it was the LDAP which gets the group mai= l id from the address book for the Mail Client. Eg. In Outlook+AD+Exchange we have the CTRL+K option which g= ets the group id that points to more than one mailing address. I think ther= e is a basic understanding between Exchange and AD that does the trick. = With Regards Bejoy <div style=3D"font-family: arial,helvetica= ,sans-serif; font-size: 13px;"><hr size=3D"1">From: Andrew F= indlay <andrew.findlay(a)skills-1st.co.uk> To: bejnet(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Wednesday, 3 December, 2008 2:02:05 PM<b= r>Subject: Re: (ITS#5845) = Distribution List support for OpenLDAP schema On Wed, Dec 03,= 2008 at 05:02:52AM +0000, <a ymailto=3D"mailto:bejnet@yahoo.com" href=3D"m= ailto:bejnet@yahoo.com">bejnet(a)yahoo.com</a> wrote: > I want to c= reate distribution list in OpenLDAP. Meaning - If I have a group > ca= lled <a ymailto=3D"mailto:admins@ldap.com" href=3D"mailto:admins@ldap.com">= admins(a)ldap.com</a> and there are two members - <a ymailto=3D"mailto:bejoy@= ldap.com" href=3D"mailto:bejoy@ldap.com">bejoy(a)ldap.com</a> and > <a ymailto=3D"mailto:bejnet@ldap.com" href=3D"mailto:bejnet@ldap.com">bejnet@= ldap.com</a>; and mail is sent to <a ymailto=3D"mailto:admins@ldap.com" hre= f=3D"mailto:admins@ldap.com">admins(a)ldap.com</a> =3D both these members mus= t > get the email. Exchange has this feature. This mail id should hav= e a display > name feature as well - that would show up on search of = address books. > > At present the work around is using qmail's= schema for this distribution list. I > believe inetOrgPerson schema = could have a group version too - which would need a > compulsory attr= ibute called members which must have atleast one member mentioned > u= nder it. I think you have just described groupOfNames. I do not like= groupOfNames *because* it makes the member attribute mandatory, which m= akes management complicated. Anyway, I cannot see this as a defec= t in OpenLDAP. LDAP schema is extensible: if you want something that is = not in the standard set you can add it locally. You say that you have used = qmail's schema: is there anything wrong with that? Most LDAP-capa= ble mail systems can be persuaded to use groups as mailing lists, but th= at is a mail system issue not an OpenLDAP one. It could be argued that s= imple groups are not rich enough to use for list expansion (no way to ke= ep track of per-member list preferences etc) but if we are going to talk= about defining an improved group this is the wrong place to do it: mayb= e IETF's ldapext list would be better. Andrew -- ---------= -------------------------------------------------------------- |  &= nbsp;             From Andrew Findlay, Skill= s 1st Ltd                | | Co= nsultant in large-scale systems, networks, and directory services | |&nb= sp;   <a href=3D"http://www.skills-1st.co.uk/" target=3D"_blank">http://www.skills-1st.co.uk/</a>      &nb= sp;         +44 1628 782565    | --------= --------------------------------------------------------------- </div></= div></div> =0A <hr size=3D1></hr> Add more friends to your = messenger and enjoy! <a href=3D"http://in.rd.yahoo.com/tagline_messenger_6/= *http://messenger.yahoo.com/invite/"> Invite them now.</a></body></html> --0-334172624-1228364660=:46006--

1 0

Re: (ITS#5844) bdb backend hangs
by thomas＠koeller.dyndns.org 03 Dec '08

03 Dec '08

Am Mittwoch, 3. Dezember 2008 22:14:20 schrieb Quanah Gibson-Mount: > <http://www.oracle.com/technology/software/products/berkeley-db/db/index.ht >ml> > > Berkeley DB Release History > > > Latest Production Release > 4.7.25 > Requires log file format upgrade. change log - patches (1) > > Click on the "1", it's a link to the patch: > > <http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patc…> > After applying the patches, everything seems to be working working now. Thank you very much for your assistance! tk

1 0

← Newer
1
...
7
8
9
10
11
12
13
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 December 2008