openldap-bugs

openldap-bugs@openldap.org

1 participants
21123 discussions

(ITS#7039) Use of uninitialized vars causes segfault when controls are parsed from LDIF
by masarati＠aero.polimi.it 08 Sep '11

08 Sep '11

Full_Name: Pierangelo Masarati Version: master, re24 OS: Linux on x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.1.31) Submitted by: ando See <http://www.openldap.org/lists/openldap-technical/201109/msg00099.html>. p.

1 0

(ITS#7037) slapd crashes with syncrepl when replica cleared out DB
by ml+openldap＠esmtp.org 07 Sep '11

07 Sep '11

Full_Name: Claus Assmann Version: 2.4.26 OS: Red Hat Enterprise Linux Server release 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.211.143.38) While trying to determine how syncrepl behaves in various error conditions, I encountered a crash of slapd. A MASTER is set up to use push replication to a REPLICA as follows: database ldap hidden on suffix "" rootdn "cn=slapd-ldap" uri ldap://REPLICA/ lastmod on restrict all sync_use_subentry true acl-bind bindmethod=simple binddn="cn=Monitor" credentials=password syncrepl rid=001 provider=ldapi://%2Fvar%2Frun%2Fldapi binddn="cn=Manager" bindmethod=simple credentials=passwd searchbase="" type=refreshAndPersist retry="5 5 60 +" Reproduce: On REPLICA: stop slapd, clear out directory for DB, start slapd. On MASTER: add an entry master which has to be "synced" to REPLICA; run ldapsearch to lookup up that entry on MASTER slapd dumps core, backtrace: #0 0x00002b7e51344265 in raise () from /lib64/libc.so.6 #1 0x00002b7e51345d10 in abort () from /lib64/libc.so.6 #2 0x00002b7e5133d6e6 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000549546 in ldap_add_ext (ld=0xbba1bc0, dn=0x0, attrs=0xbeb7ed0, sctrls=0x0, cctrls=0x0, msgidp=0x435224c4) at add.c:126 #4 0x00000000004dbe6d in ldap_back_add (op=0x43523150, rs=0x43522770) at add.c:102 #5 0x0000000000481152 in overlay_op_walk (op=0x43523150, rs=0x43522770, which=op_add, oi=0xb9eb6c0, on=0x0) at backover.c:671 #6 0x00000000004816a7 in over_op_func (op=0x43523150, rs=0x43522770, which=op_add) at backover.c:723 #7 0x0000000000473706 in syncrepl_add_glue_ancestors (op=0x43523150, e=0x2b7e56628fb8) at syncrepl.c:3149 #8 0x000000000047384e in syncrepl_add_glue (op=0x43523150, e=0x2b7e56628fb8) at syncrepl.c:3193 #9 0x0000000000474795 in syncrepl_entry (si=0xb9eb1c0, op=0x43523150, entry=0x0, modlist=0x43523ca0, syncstate=<value optimized out>, syncUUID=<value optimized out>, syncCSN=0xbeb86e0) at syncrepl.c:2448 #10 0x000000000047c39b in do_syncrep2 (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:982 #11 do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:1489 #12 0x000000000041eee3 in connection_read_thread (ctx=0x43523da0, argv=<value optimized out>) at connection.c:1276 #13 0x00000000005412dc in ldap_int_thread_pool_wrapper (xpool=0xb8fa1c0) at tpool.c:685 #14 0x00002b7e510ff73d in start_thread () from /lib64/libpthread.so.0 #15 0x00002b7e513e84bd in clone () from /lib64/libc.so.6 Note: this also happens with 2.4.23. On a VM instance, it causes a different error (see mail on list: "killed after 120 seconds")

1 0

Re: (ITS#7036) ldapsearch should attempt DNS-based fallback if possible
by seanius＠seanius.net 07 Sep '11

07 Sep '11

On Wed, Sep 07, 2011 at 12:51:10PM +0000, Pierangelo Masarati wrote: > As far as I understand from the code, libldap already behaves like that, i.e. it > loops through all the hosts returned by getaddrinfo(3). What's missing (in your > configuration of ldapsearch) is a network timeout parameter. Right now, you can > set it either using NETWORK_TIMEOUT in ldap.conf(5) or passing the command-line > switch -o nettimeout=<timeout>. I understand the latter is not documented in > ldapsearch(1), although it appears in the usage message of all tools. wonderful, confirmed that it works. so then yes, just a minor omission from the documentation :) sean

1 0

Re: (ITS#7036) ldapsearch should attempt DNS-based fallback if possible
by Pierangelo Masarati 07 Sep '11

07 Sep '11

As far as I understand from the code, libldap already behaves like that, i.e. it loops through all the hosts returned by getaddrinfo(3). What's missing (in your configuration of ldapsearch) is a network timeout parameter. Right now, you can set it either using NETWORK_TIMEOUT in ldap.conf(5) or passing the command-line switch -o nettimeout=<timeout>. I understand the latter is not documented in ldapsearch(1), although it appears in the usage message of all tools. As I'd consider this issue a software usage question rather than a bug (except for the missing documentation), I encourage you to continue discussion on the openldap-technical mailing list. p.

1 0

(ITS#7036) ldapsearch should attempt DNS-based fallback if possible
by seanius＠seanius.net 07 Sep '11

07 Sep '11

Full_Name: Sean Finney Version: 2.4.21-0ubuntu5.5 OS: Ubuntu Lucid URL: Submission from: (NULL) (213.115.10.98) We have an ldap.conf with URI ldap://corp.net where corp.net resolves to a list of about 20 round-robin balanced A records, all of which are windows-based domain controllers for the site. Recently, a hiccup in change control ended up with 3 of these servers being offline but remaining in DNS. Therefore, with about 3/20 probability ldapsearch and friends will just sit and hang waiting for packets to return from the void until the TCP/IP RTT timeout is reached. It would be nice if ldapsearch could, either by default or as an option, have some way of iteratively trying all of the returned DNS records in the face of such failure (which could also be from some form of network hiccup, or a crashed server). Bonus points if it could somehow be pre-emptive (i.e. not waiting for the entire TCP/IP RTT timeout before trying another server). Of course another alternative would be for us to duplicate the information from DNS into multiple servers listed in URI, but that seems... duplicative. But in any event I did a quick search of the issue system and didn't see a documented position on the matter so I figured I could at least post this and see what you think :)

1 0

Re: (ITS#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hans.moser＠ofd-z.niedersachsen.de 07 Sep '11

07 Sep '11

Hi, hans.moser(a)ofd-z.niedersachsen.de schrieb am 26.08.2011 16:49 Uhr: > hyc(a)symas.com schrieb am 24.08.2011 23:54 Uhr: > >> A patch for backglue.c is in git master, please test. Thanks. > Does not help. :( Any new patch to test? Marc

1 0

(ITS#7035) libldap wait4msg loops forever
by hyc＠OpenLDAP.org 07 Sep '11

07 Sep '11

Full_Name: Howard Chu Version: git master OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc In test060 slapd-mtread will frequently get into an endless loop if slapd dies during the multi-threaded reader+writer test. poll() returns a POLL_HANGUP event but libldap only handles POLL_WRITE and POLL_READ; since nothing handles the hangup event poll keeps returning the event. Patch coming shortly.

1 0

Re: (ITS#7034) Patch - Mozilla NSS - SSL_ForceHandshake not thread safe with PEM module
by rmeggins＠redhat.com 06 Sep '11

06 Sep '11

Found another thread-safety problem with SSL_ConfigServerSessionIDCache() updated patch: ftp://ftp.openldap.org/incoming/0001-use-mutex-for-connection-handshake-whe…

1 0

(ITS#7034) Patch - Mozilla NSS - SSL_ForceHandshake not thread safe with PEM module
by rmeggins＠redhat.com 06 Sep '11

06 Sep '11

Full_Name: Rich Megginson Version: current tip of master branch OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/0001-use-mutex-for-connection-handshake-whe… Submission from: (NULL) (76.26.104.137) The establishment of the TLS/SSL connection (accept or connect) using SSL_ForceHandshake() is not thread safe when using the PEM module. This patch adds a mutex to protect the call. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7033) suffix invalid dn :21
by Pierangelo Masarati 06 Sep '11

06 Sep '11

The OpenLDAP-ITS address is for reporting bugs in OpenLDAP software. Nothing in your report is indicative of a bug in OpenLDAP. If you have questions about use of OpenLDAP Software which are not answered in the documentation, FAQ, and archives, use the OpenLDAP-technical list (subscription required; instructions here <http://www.openldap.org/lists/mm/listinfo/openldap-technical>). This issue report will be closed. p.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs