openldap-bugs June 2008

openldap-bugs@openldap.org

46 participants
176 discussions

(ITS#5577) [BUG, PATCH] slapd unable to import CRL using GnuTLS backend
by arno＠natisbad.org 24 Jun '08

24 Jun '08

Full_Name: Arnaud Ebalard Version: 2.4.10 OS: Linux (Debian unstable) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.215.50.138) Hi, When openldap is linked with gnutls for TLS support, a file containing CRL in PEM format can be provided (in slapd.conf, using TLSCRLFile parameter). The following code in ldap_int_tls_init_ctx() (librairies/libldap/tls.c) prevents the daemon to start when the option is used: if ( lo->ldo_tls_crlfile ) { rc = gnutls_certificate_set_x509_crl_file( ((tls_ctx*) lo->ldo_tls_ctx)->cred, crlfile, GNUTLS_X509_FMT_PEM ); if ( rc < 0 ) goto error_exit; } because gnutls_certificate_set_x509_crl_file() returns the number of CRL files that have been imported which is stored in rc and returned later in the function. Caller expects 0, otherwise it reports an error, the value of rc (below, with 3 CRL in the file) and slapd fails to start: .... main TLS init def ctx failed: 3 The patch below is for 2.4.10, but should apply against all versions (it applies fine against current Debian version available under Unstable). Tell me if you have issues. I recompiled the Debian version with the patch applied and it works as expected. Cheers, a+ The patch is IMHO short enough to inline it here: Index: openldap-2.4.10/libraries/libldap/tls.c =================================================================== --- openldap-2.4.10.orig/libraries/libldap/tls.c 2008-06-24 16:10:00.128945991 +0200 +++ openldap-2.4.10/libraries/libldap/tls.c 2008-06-24 16:11:46.804929042 +0200 @@ -754,7 +754,10 @@ ((tls_ctx*) lo->ldo_tls_ctx)->cred, crlfile, GNUTLS_X509_FMT_PEM ); - if ( rc < 0 ) goto error_exit; + if ( rc < 0 ) + goto error_exit; + else + rc = 0; } if ( is_server ) { gnutls_dh_params_init (&((tls_ctx*)

1 0

Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by hyc＠symas.com 24 Jun '08

24 Jun '08

ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> michael(a)stroeder.com writes: >>> The following attribute type declaration references 'managedInfo' >>> which is not declared: >>> >>> ( 1.3.6.1.4.1.4203.666.1.55.0.1.2.1 NAME 'olmDbURIList' DESC 'List of URIs a >>> proxy is serving; can be modified run-time' SUP managedInfo ) >> Please mention where the code is which you refer to. >> >> Anyway, this is in back-ldap/monitor.c and managedInfo *is* declared - >> in back-monitor/init.c. Have you observed a failure, e.g. with >> back-ldap and ./configure --disable-monitor? > > I suspect something like: if back-monitor and/or back-ldap are built as > modules, and loaded in the wrong order (back-ldap first, back_monitor > then), 'olmDbURIList' is likely to be registered __before__ > 'managedInfo'. I don't see a quick fix (or anything but requiring > loading the modules in the right order) to this issue. In fact, the > only "clean" solution would be for back-ldap to register a function that > is executed when back-monitor is loaded, in order to register dependent > schema items and enable the monitoring feature it implements. The > safest thing to do right now is condition the registration of > 'olmDbURIList' to the existence of 'managedInfo', conditioning the > availability of the monitoring feature to loading the modules in the > right order. Of course this ought to be documented somewhere. Note > that probably similar issues exist in back-bdb's specific monitoring > features. The fact that I seldom develop while building backends and > overlays as modules might have an impact on this type of issues, though. We already solved this dependency in back-ldap and back-bdb - their monitor_init() functions will return without doing anything if backend_info("monitor") fails. As such, these schema items will only be registered if back-monitor has already beeen loaded. There's no issue here. -- -- 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#5576) Missing attribute type 'managedInfo' referenced with SUP
by Kurt＠OpenLDAP.org 24 Jun '08

24 Jun '08

On Jun 23, 2008, at 4:58 PM, michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.96.75) > > > The following attribute type declaration references 'managedInfo' > which is not > declared: > > ( 1.3.6.1.4.1.4203.666.1.55.0.1.2.1 NAME 'olmDbURIList' DESC 'List > of URIs a > proxy is serving; can be modified run-time' SUP managedInfo ) THe fact that this element is published with a .666 OID is a bug. . 666 are intended for experiments and should never be published. -- Kurt

1 0

Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by ando＠sys-net.it 24 Jun '08

24 Jun '08

h.b.furuseth(a)usit.uio.no wrote: > michael(a)stroeder.com writes: >> The following attribute type declaration references 'managedInfo' >> which is not declared: >> >> ( 1.3.6.1.4.1.4203.666.1.55.0.1.2.1 NAME 'olmDbURIList' DESC 'List of URIs a >> proxy is serving; can be modified run-time' SUP managedInfo ) > > Please mention where the code is which you refer to. > > Anyway, this is in back-ldap/monitor.c and managedInfo *is* declared - > in back-monitor/init.c. Have you observed a failure, e.g. with > back-ldap and ./configure --disable-monitor? I suspect something like: if back-monitor and/or back-ldap are built as modules, and loaded in the wrong order (back-ldap first, back_monitor then), 'olmDbURIList' is likely to be registered __before__ 'managedInfo'. I don't see a quick fix (or anything but requiring loading the modules in the right order) to this issue. In fact, the only "clean" solution would be for back-ldap to register a function that is executed when back-monitor is loaded, in order to register dependent schema items and enable the monitoring feature it implements. The safest thing to do right now is condition the registration of 'olmDbURIList' to the existence of 'managedInfo', conditioning the availability of the monitoring feature to loading the modules in the right order. Of course this ought to be documented somewhere. Note that probably similar issues exist in back-bdb's specific monitoring features. The fact that I seldom develop while building backends and overlays as modules might have an impact on this type of issues, though. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by h.b.furuseth＠usit.uio.no 24 Jun '08

24 Jun '08

michael(a)stroeder.com writes: > The following attribute type declaration references 'managedInfo' > which is not declared: > > ( 1.3.6.1.4.1.4203.666.1.55.0.1.2.1 NAME 'olmDbURIList' DESC 'List of URIs a > proxy is serving; can be modified run-time' SUP managedInfo ) Please mention where the code is which you refer to. Anyway, this is in back-ldap/monitor.c and managedInfo *is* declared - in back-monitor/init.c. Have you observed a failure, e.g. with back-ldap and ./configure --disable-monitor? -- Hallvard

1 0

(ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by michael＠stroeder.com 23 Jun '08

23 Jun '08

Full_Name: Michael Ströder Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.96.75) The following attribute type declaration references 'managedInfo' which is not declared: ( 1.3.6.1.4.1.4203.666.1.55.0.1.2.1 NAME 'olmDbURIList' DESC 'List of URIs a proxy is serving; can be modified run-time' SUP managedInfo )

1 0

Re: (ITS#5508) slapd process consumes all of CPU
by quanah＠zimbra.com 23 Jun '08

23 Jun '08

--On Monday, June 23, 2008 8:06 PM +0000 whm(a)stanford.edu wrote: > > > --On Monday, June 23, 2008 11:04:36 AM -0700 Howard Chu <hyc(a)symas.com> > wrote: > >> Bill MacAllister wrote: >>> Howard, >>> >>> We just upgraded to 2.3.42 and are seeing the problem again in our >>> production environment. I have attached a backtrace and db_stat output. >>> This output if from the busy server. I will disconnect the network next >>> and see what happens. >> >> The db_stat output seems to indicate that entries that are being fetched >> for read access are not getting unlocked. This behavior is new since >> 2.3.4x for you? What's the last release version where this does not >> occur? > > > The last version that we ran in production that did not exhibit this > behavior was 2.3.25. We have tried both 2.3.41 and 2.3.42 and seen the > problem. We backed out of 2.3.41 when we hit the problem. I believe you mean 2.3.35. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5508) slapd process consumes all of CPU
by whm＠stanford.edu 23 Jun '08

23 Jun '08

--On Monday, June 23, 2008 11:04:36 AM -0700 Howard Chu <hyc(a)symas.com> wrote: > Bill MacAllister wrote: >> Howard, >> >> We just upgraded to 2.3.42 and are seeing the problem again in our >> production environment. I have attached a backtrace and db_stat output. >> This output if from the busy server. I will disconnect the network next >> and see what happens. > > The db_stat output seems to indicate that entries that are being fetched > for read access are not getting unlocked. This behavior is new since > 2.3.4x for you? What's the last release version where this does not occur? The last version that we ran in production that did not exhibit this behavior was 2.3.25. We have tried both 2.3.41 and 2.3.42 and seen the problem. We backed out of 2.3.41 when we hit the problem. Bill +-------------------------------------------------------- | Bill MacAllister <whm(a)stanford.edu> | Systems Software Programmer, ITS Unix Systems, Stanford University

1 0

Re: (ITS#5508) slapd process consumes all of CPU
by hyc＠symas.com 23 Jun '08

23 Jun '08

Bill MacAllister wrote: > Howard, > > We just upgraded to 2.3.42 and are seeing the problem again in our > production environment. I have attached a backtrace and db_stat output. > This output if from the busy server. I will disconnect the network next > and see what happens. The db_stat output seems to indicate that entries that are being fetched for read access are not getting unlocked. This behavior is new since 2.3.4x for you? What's the last release version where this does not occur? > > Bill > > --On Tuesday, May 13, 2008 02:45:06 AM -0700 Howard Chu<hyc(a)symas.com> > wrote: > >> Bill MacAllister wrote: >>> Attached is the output of db4.2_stat -CA of the database. >>> >>> Thanks for looking at this. >>> >> So far it just looks like a very busy server. Can you turn off the >> network access to it and see if it settles down when the query traffic >> stops? >> >> It's a bit odd that a single transaction has so many pages of the >> suPrivilegeGroup index locked. >> >> The backtrace is somewhat suspicious, there are several<value optimized >> out> items in the trace. In thread 8, frames 5 and 6 the locker value is >> odd; usually in BDB the locker ID associated with a transaction has bit >> 31 set, yielding a very large 32 bit number. Also there is no locker with >> that ID in the db_stat output you provided. >> >> It looks like you'll have to try this again with a non-optimized binary >> to get a reliable backtrace. >> >>> Bill >>> >>> --On Tuesday, May 13, 2008 01:20:49 AM -0700 Howard Chu<hyc(a)symas.com> >>> wrote: >>> >>>> whm(a)stanford.edu wrote: >>>>> Full_Name: Bill MacAllister >>>>> Version: 2.3.41-1su2 >>>>> OS: debian etch kernel 2.6.18-4-amd64 >>>>> URL: http://www.stanford.edu/~whm/ldap-test1-bt.txt >>>>> Submission from: (NULL) (171.64.19.165) >>>>> >>>>> >>>>> The slapd process will sometimes consume all of available CPU. We >>>>> observed this when we upgraded our production servers from 2.3.35-2su2 >>>>> to 2.3.41-1su2. The problem was bad enough that we downgraded the >>>>> production servers to 2.3.35-2su2. We have been trying to provoke the >>>>> problem in our test environment and have not been successful in >>>>> making it happen on demand. Today, we noticed that one of our test >>>>> servers went completely CPU bound. I took a backtrace. It is >>>>> available at the URL below. The interesting thing about the problem >>>>> is that although top shows a pinned CPU and a high load the server is >>>>> still responsive and continues to answer LDAP searches. The test >>>>> server that exhibits the problem is still CPU bound and has been for >>>>> 2-3 hours now. We will leave this server in this state in case there >>>>> is other information that we should harvest in resolving the problem. >>>> Please also provide the output from db_stat -CA on the database in >>>> question, thanks. > > > > > +-------------------------------------------------------- > | Bill MacAllister<whm(a)stanford.edu> > | Systems Software Programmer, ITS Unix Systems, Stanford University > +---------------------------------------------------------- > | "My heart is warm with the friends I make, And better > | friends I'll not be knowing; Yet there isn't a train > | I wouldn't take, No matter where it's going." > | Edna St. Vincent Millay -- -- 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#5575) smbk5pwd and slapd disagree on rs_new.bv_val \0 termination
by laurent.pinchart＠skynet.be 23 Jun '08

23 Jun '08

Full_Name: Laurent Pinchart Version: 2.4.9 OS: Linux Ubuntu 8.04 URL: Submission from: (NULL) (194.78.198.49) When parsing password change extended operations, servers/slapd/passwd.c:slap_passwd_parse() calls ber_get_stringbv() with LBER_BV_NOTERM set. The resulting bv_val doesn't end with a \0. When changing the password, smbk5pwd assumes rs_new.bv_val is zero terminated and doesn't check its length. This results in garbage being appended to the password. Either smbk5pwd should zero-terminate rs_new.bv_val, or the password change EXOP parsing code should make sure a trailing \0 is appended to bv_val.

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
18
Older →

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