openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#6548) Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by hyc＠symas.com 13 Jun '10

13 Jun '10

Mark A. Ziesemer wrote: > On Wed, May 12, 2010 at 10:05 AM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > online(a)mark.ziesemer.com <mailto:online@mark.ziesemer.com> wrote: > > Full_Name: Mark A. Ziesemer > Version: 2.4.21 > OS: Ubuntu Linux 10.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:470:1f11:3ae:4d6d:3d3e:faa6:ee3d) > > > Many "connection_read(): no connection!" warnings are written to > /var/log/debug > and /var/log/syslog by slapd. As stated at > http://www.openldap.org/lists/openldap-software/200811/msg00079.html , > this is > apparently not a problem with slapd, but a client that is > disconnecting without > first unbinding. > > > This also happens when the connection manager queues up a thread to handle > a "socket is readable" event on a socket that's in the process of closing. > Pretty much unavoidable, when a lot of threads are active. I don't see > this as a high enough priority to warrant fixing. > > > This was not happening under a high load, but with only 1-2 connections active. > > I might not have focused on it enough in the original report, but isn't this > looking like it is probably an issue with the libldap client library (provided > by OpenLDAP), rather than the slapd daemon? Looking at the provided logs, it > appears that no do_unbind request is received (not sent by the client) when > using ldapi:/// with a bind DN. > > If it can't / won't be fixed, can the logging of the "connection_read(): no > connection!" event in slapd at least be demoted to a lower level so that it > doesn't fill the default logging output, without having to change the overall > configured logging level and potentially missing other logged events that do > require attention? "Fixing" libldap, if there's even a bug there, obviously won't help with other clients using non-OpenLDAP libraries. At any rate, there's nothing that requires an Unbind request to be sent, so there's no bug here. I don't see messages filling the log. I don't see any issue here at all. I was only able to reproduce this by performing a Bind with invalid credentials. In the case with correct credentials, there were no extraneous messages. If you're seeing a lot of these cases, then you should think about why you're getting a lot of Binds with invalid passwords. Fix the problem, not the symptom. This ITS will be closed. > This appears to be an issue with the libldap client library provided > by OpenLDAP > itself (2.4.21), and not the slapd daemon. > > Issue is reproducible even by just using "ldapsearch -H ldapi:///", > but only if > a bind DN is specified (-D) and external authentication is not used. > > Running slapd with logging enabled (-d 8) shows the following 3 > sequences - > ldapsearch command followed by the slapd logs. Note that the > "connection_read(): no connection!" is only visible on the middle pair. > > > $ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "" > SASL/EXTERNAL authentication started > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > No such object (32) > > slap_listener_activate(9): > > slap_listener(ldapi:///) > > connection_get(14): got connid=1000 > connection_read(14): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 24 contents: > op tag 0x60, time 1273546410 > ber_get_next > conn=1000 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt ({m) ber: > ber_scanf fmt (m) ber: > ber_scanf fmt (}}) ber: > > dnPrettyNormal:<> > > <<< dnPrettyNormal:<>,<> > do_bind: dn () SASL mech EXTERNAL > ==>slap_sasl2dn: converting SASL name > gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth to a DN > <==slap_sasl2dn: Converted SASL name to<nothing> > SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" > send_ldap_sasl: err=0 len=-1 > do_bind: SASL/EXTERNAL bind: > dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" sasl_ssf=0 > send_ldap_response: msgid=1 tag=97 err=0 > ber_flush2: 14 bytes to sd 14 > <== slap_sasl_bind: rc=0 > connection_get(14): got connid=1000 > connection_read(14): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 37 contents: > op tag 0x63, time 1273546410 > ber_get_next > conn=1000 op=1 do_search > ber_scanf fmt ({miiiib) ber: > > dnPrettyNormal:<> > > <<< dnPrettyNormal:<>,<> > ber_scanf fmt (m) ber: > ber_scanf fmt ({M}}) ber: > send_ldap_result: conn=1000 op=1 p=3 > send_ldap_response: msgid=2 tag=101 err=32 > ber_flush2: 14 bytes to sd 14 > connection_get(14): got connid=1000 > connection_read(14): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 5 contents: > op tag 0x42, time 1273546410 > ber_get_next > conn=1000 op=2 do_unbind > connection_close: conn=1000 sd=14 > > $ ldapsearch -H ldapi:/// -D "cn=admin,dc=example,dc=com" -b "" -W > Enter LDAP Password: > ldap_bind: Invalid credentials (49) > > slap_listener_activate(9): > > slap_listener(ldapi:///) > > connection_get(14): got connid=1001 > connection_read(14): checking for input on id=1001 > ber_get_next > ber_get_next: tag 0x30 len 44 contents: > op tag 0x60, time 1273546420 > ber_get_next > conn=1001 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt (m}) ber: > > dnPrettyNormal:<cn=admin,dc=example,dc=com> > > <<< > dnPrettyNormal:<cn=admin,dc=example,dc=com>,<cn=admin,dc=example,dc=com> > do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128 > send_ldap_result: conn=1001 op=0 p=3 > send_ldap_response: msgid=1 tag=97 err=49 > ber_flush2: 14 bytes to sd 14 > connection_get(14): got connid=1001 > connection_read(14): checking for input on id=1001 > ber_get_next > ber_get_next on fd 14 failed errno=0 (Success) > connection_close: conn=1001 sd=14 > connection_read(14): no connection! > connection_read(14): no connection! > > $ ldapsearch -H ldap:/// -D "cn=admin,dc=example,dc=com" -b "" -W > Enter LDAP Password: > ldap_bind: Invalid credentials (49) > > slap_listener_activate(8): > > slap_listener(ldap:///) > > connection_get(14): got connid=1002 > connection_read(14): checking for input on id=1002 > ber_get_next > ber_get_next: tag 0x30 len 44 contents: > op tag 0x60, time 1273546425 > ber_get_next > conn=1002 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt (m}) ber: > > dnPrettyNormal:<cn=admin,dc=example,dc=com> > > <<< > dnPrettyNormal:<cn=admin,dc=example,dc=com>,<cn=admin,dc=example,dc=com> > do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128 > send_ldap_result: conn=1002 op=0 p=3 > send_ldap_response: msgid=1 tag=97 err=49 > ber_flush2: 14 bytes to sd 14 > connection_get(14): got connid=1002 > connection_read(14): checking for input on id=1002 > ber_get_next > ber_get_next on fd 14 failed errno=0 (Success) > connection_close: conn=1002 sd=14 -- -- 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#6548) Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by kralg＠robolution.eu 13 Jun '10

13 Jun '10

Hi! Do we have any chance that this bug will be rectified recently? I believe a communication issue like this should do taken as being important. It makes the log check a huge pain, and I don't think ,,hiding'' the log is a real solution. Thank You, Gergely Kral

1 0

Re: (ITS#6572) slapd crash caused by refint's cn=config modification
by mbackes＠symas.com 12 Jun '10

12 Jun '10

> Here's a patch that fixes 6572. Heh, okay Quanah. This patch file is derived from OpenLDAP Software. All of the = modifications to OpenLDAP Software represented in the previous patch was = developed by me for Symas and the OpenLDAP project. I am authorized by = Symas, my employer, to release this work under the following terms. Portions Copyright 2010 Symas Corporation. Redistribution and use in source and binary forms, with or without = modification, are permitted only as authorized by the OpenLDAP Public = License. Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

Re: (ITS#6572) slapd crash caused by refint's cn=config modification
by mbackes＠symas.com 12 Jun '10

12 Jun '10

--Apple-Mail-322--405209956 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Here's a patch that fixes 6572. * Switch to use BER_BVISNULL, BER_BVZERO, and ch_free instead * Clean up Ozone's "breadcrumbs" while we're at it (unrelated but trivial) * Should apply cleanly to RE24 and HEAD * Older dyn-config refints (RE22, RE23) likely have the same problem Matthew Backes Symas Corporation mbackes(a)symas.com --Apple-Mail-322--405209956 Content-Disposition: attachment; filename=refint-patch-its-6572.txt Content-Type: text/plain; name="refint-patch-its-6572.txt" Content-Transfer-Encoding: 7bit Index: refint.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/refint.c,v retrieving revision 1.46 diff -u -r1.46 refint.c --- refint.c 13 Apr 2010 20:18:25 -0000 1.46 +++ refint.c 13 Jun 2010 04:02:09 -0000 @@ -76,7 +76,6 @@ } refint_q; typedef struct refint_data_s { - const char *message; /* breadcrumbs */ struct refint_attrs_s *attrs; /* list of known attrs */ BerValue dn; /* basedn in parent, */ BerValue nothing; /* the nothing value, if needed */ @@ -210,21 +209,17 @@ rc = 0; break; case REFINT_NOTHING: - if ( dd->nothing.bv_val ) - ber_memfree ( dd->nothing.bv_val ); - if ( dd->nnothing.bv_val ) - ber_memfree ( dd->nnothing.bv_val ); - dd->nothing.bv_len = 0; - dd->nnothing.bv_len = 0; + ch_free( dd->nothing.bv_val ); + ch_free( dd->nnothing.bv_val ); + BER_BVZERO( &dd->nothing ); + BER_BVZERO( &dd->nnothing ); rc = 0; break; case REFINT_MODIFIERSNAME: - if ( dd->refint_dn.bv_val ) - ber_memfree ( dd->refint_dn.bv_val ); - if ( dd->refint_ndn.bv_val ) - ber_memfree ( dd->refint_ndn.bv_val ); - dd->refint_dn.bv_len = 0; - dd->refint_ndn.bv_len = 0; + ch_free( dd->refint_dn.bv_val ); + ch_free( dd->refint_ndn.bv_val ); + BER_BVZERO( &dd->refint_dn ); + BER_BVZERO( &dd->refint_ndn ); rc = 0; break; default: @@ -256,22 +251,26 @@ } break; case REFINT_NOTHING: - if ( dd->nothing.bv_val ) - ber_memfree ( dd->nothing.bv_val ); - if ( dd->nnothing.bv_val ) - ber_memfree ( dd->nnothing.bv_val ); - dd->nothing = c->value_dn; - dd->nnothing = c->value_ndn; - rc = 0; + if ( !BER_BVISNULL( &c->value_ndn )) { + ch_free ( dd->nothing.bv_val ); + ch_free ( dd->nnothing.bv_val ); + dd->nothing = c->value_dn; + dd->nnothing = c->value_ndn; + rc = 0; + } else { + rc = ARG_BAD_CONF; + } break; case REFINT_MODIFIERSNAME: - if ( dd->refint_dn.bv_val ) - ber_memfree ( dd->refint_dn.bv_val ); - if ( dd->refint_ndn.bv_val ) - ber_memfree ( dd->refint_ndn.bv_val ); - dd->refint_dn = c->value_dn; - dd->refint_ndn = c->value_ndn; - rc = 0; + if ( !BER_BVISNULL( &c->value_ndn )) { + ch_free( &dd->refint_dn.bv_val ); + ch_free( &dd->refint_ndn.bv_val ); + dd->refint_dn = c->value_dn; + dd->refint_ndn = c->value_ndn; + rc = 0; + } else { + rc = ARG_BAD_CONF; + } break; default: abort (); @@ -299,7 +298,6 @@ slap_overinst *on = (slap_overinst *)be->bd_info; refint_data *id = ch_calloc(1,sizeof(refint_data)); - id->message = "_init"; on->on_bi.bi_private = id; ldap_pvt_thread_mutex_init( &id->qmutex ); return(0); @@ -335,7 +333,6 @@ { slap_overinst *on = (slap_overinst *)be->bd_info; refint_data *id = on->on_bi.bi_private; - id->message = "_open"; if ( BER_BVISNULL( &id->dn )) { if ( BER_BVISNULL( &be->be_nsuffix[0] )) @@ -354,7 +351,6 @@ ** foreach configured attribute: ** free it; ** free our basedn; -** (do not) free id->message; ** reset on_bi.bi_private; ** free our config data; ** @@ -369,7 +365,6 @@ slap_overinst *on = (slap_overinst *) be->bd_info; refint_data *id = on->on_bi.bi_private; refint_attrs *ii, *ij; - id->message = "_close"; for(ii = id->attrs; ii; ii = ij) { ij = ii->next; @@ -870,8 +865,6 @@ BackendDB *db = NULL; refint_attrs *ip; - id->message = "_refint_response"; - /* If the main op failed or is not a Delete or ModRdn, ignore it */ if (( op->o_tag != LDAP_REQ_DELETE && op->o_tag != LDAP_REQ_MODRDN ) || rs->sr_err != LDAP_SUCCESS ) --Apple-Mail-322--405209956--

1 0

(ITS#6572)
by daniel＠pluta.biz 09 Jun '10

09 Jun '10

short add-on note: any kind of modify operation on this attribute seems to crash slapd

1 0

Re: (ITS#6573) schema errors
by Kurt＠OpenLDAP.org 06 Jun '10

06 Jun '10

On Jun 6, 2010, at 8:27 PM, peychart(a)mail.pf wrote: > Full_Name: Philippe EYCHART > Version: last > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.185.181.157) >=20 >=20 > Hi, >=20 > 1/- It seems there is one schema definition error : the "street" = attribute is > defined twice in the "domain" objectClass (cosine.schema) ... > So, the LDAP database repeat this error ; see: ldapsearch -x -b = "cn=3Dsubschema" > -s base objectclasses As far as the old RFC 1274 version of 'domain', cosine.schema is = correct. (It's not an error to list attributes multiple times in schema = descriptions. There's a number of multiple listings found in RFC = specifications of object classes.) =20 Of course, all of cosine.schema should be replaced with a new file = derived directly from RFC 4524 with non-conflicting deprecated stuff at = the end of the file or moved to cosine-old.schema file. >=20 > 2/- the attribute "internationaliSDNNumber" is defined with a "i" for = "iSDN" but > with a "I" in the "domain" objectClass definition ... (so, a compare = with no > sensitive case option must be done to find it ...) Names are case insensitive. >=20 > (cf.: <http://home.gna.org/ldapcppei/Frontends/Howto-5.fr.html#S5>) > Regards, > Philippe EYCHART >=20

1 0

(ITS#6573) schema errors
by peychart＠mail.pf 06 Jun '10

06 Jun '10

Full_Name: Philippe EYCHART Version: last OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.185.181.157) Hi, 1/- It seems there is one schema definition error : the "street" attribute is defined twice in the "domain" objectClass (cosine.schema) ... So, the LDAP database repeat this error ; see: ldapsearch -x -b "cn=subschema" -s base objectclasses 2/- the attribute "internationaliSDNNumber" is defined with a "i" for "iSDN" but with a "I" in the "domain" objectClass definition ... (so, a compare with no sensitive case option must be done to find it ...) (cf.: <http://home.gna.org/ldapcppei/Frontends/Howto-5.fr.html#S5>) Regards, Philippe EYCHART

1 0

(ITS#6572) slapd crash caused by refint's cn=config modification
by daniel＠pluta.biz 06 Jun '10

06 Jun '10

Full_Name: Daniel Pluta Version: 2.4.21 OS: Lnx URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:9feb:ff02:6834:fd61:37f:67da) Hi, after a silly typo (removed the "," rdn-separator character) in refint's cn=config settings while modifying "olcRefintNothing" attribute the attribute contained the following escaped value: olcRefintNothing: cn=refintcn\3Dconfig Using ldapmodify with cn=config to correct this value back into e.g. "cn=refint,cn=config" caused slapd to crash. Re-starting slapd (recovering db files...) worked fine but the value of course is still the "ugly" one above. Trying to correct (using ldapmodify) this value once more caused slapd to crash again. Cheers Daniel

1 0

Re: (ITS#6556) test031 core dumps after applying first filter
by dieter＠dkluenter.de 06 Jun '10

06 Jun '10

Hi, I have run slapd in valgrind now, which produced following error: ==15353== 1 errors in context 1 of 5: ==15353== Invalid write of size 4 ==15353== at 0x80E64B5: slap_sl_free (sl_malloc.c:492) ==15353== by 0x80A0EEA: ch_free (ch_malloc.c:137) ==15353== by 0x80E3DC9: mra_free (mra.c:43) ==15353== by 0x80855B0: filter_free_x (filter.c:556) ==15353== by 0x80836CD: do_search (search.c:230) ==15353== by 0x8080588: connection_operation (connection.c:1109) ==15353== by 0x403B376: ldap_int_thread_pool_wrapper (tpool.c:685) ==15353== by 0x43046E4: start_thread (in /lib/libpthread-2.10.1.so) ==15353== by 0x43045FF: ??? (in /lib/libpthread-2.10.1.so) ==15353== Address 0x843692b1 is not stack'd, malloc'd or (recently) free'd Full valgrind log can be found at http://pastebin.de/6914 -Dieter

1 0

(ITS#6571) rebind-as-user only works on first connection attempt
by maci＠satgnu.net 04 Jun '10

04 Jun '10

Full_Name: Marcel Wysocki Version: 2.4.22 OS: Solaris/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.79.126.162) Hello, i have the same problem as described here: http://www.openldap.org/lists/openldap-software/200712/msg00283.html here are some logs: @(#) $OpenLDAP: slapd 2.4.22 (Jun 4 2010 11:56:46) $ slapd starting Initial connection: ########################## conn=1000 fd=11 ACCEPT from IP=127.0.0.1:45654 (IP=0.0.0.0:389) conn=1000 op=0 BIND dn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" method=128 conn=1000 op=0 BIND dn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" mech=SIMPLE ssf=0 conn=1000 op=0 RESULT tag=97 err=0 text= ########################## First ldapsearch: ########################## conn=1000 op=2 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 filter="(mobile=491721000227)" conn=1000 op=2 SRCH attr=objectclass conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= ########################## backend server has been restarted, sencond ldapsearch: ########################## conn=1000 op=3 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 filter="(mobile=491721000227)" conn=1000 op=3 SRCH attr=objectclass conn=1000 op=3 ldap_back_retry: retrying URI="ldap://10.2.163.13:389" DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" conn=1000 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= ########################## backend server has been stopped, third ldapsearch, fails as it should: ########################## conn=1000 op=4 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 filter="(mobile=491721000227)" conn=1000 op=4 SRCH attr=objectclass conn=1000 op=4 ldap_back_retry: retrying URI="ldap://10.2.163.13:389" DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" conn=1000 op=4 SEARCH RESULT tag=101 err=52 nentries=0 text= ########################## backend server has been restarted, fourth ldapsearch, rebind fails: ########################## conn=1000 op=5 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 filter="(mobile=491721000227)" conn=1000 op=5 SRCH attr=objectclass conn=1000 op=5 ldap_back_dobind_int: DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" without creds, binding anonymously conn=1000 op=5 SEARCH RESULT tag=101 err=0 nentries=0 text= ########################## following the configuration for back-ldap: database ldap suffix "o=bazbaz" uri ldap://10.2.163.13:389 rootdn "cn=PEX,o=bazbaz" rootpw secret idle-timeout 301 rebind-as-user yes single-conn yes chase-referrals no acl-bind bindmethod=simple binddn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" credentials=supersecret

1 0

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