openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#5513) back-ldap+ppolicy bind assertion failure
by ando＠sys-net.it 18 May '08

18 May '08

mbackes(a)symas.com wrote: > Thanks; this seems to fix the issue, at least in my test cases. OK, I've applied the fix to re23/re24 as well. 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: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5515) v2.4.9 + GnuTLS fails with wildcard certificate, OpenSSL works correctly
by hyc＠symas.com 17 May '08

17 May '08

bgoldsbury(a)gleim.com wrote: > Full_Name: Ben Goldsbury > Version: 2.4.9 > OS: Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.208.68.2) > > > When OpenLDAP 2.4.9 is compiled against GnuTLS (version 2.2.1 in my testing) and > using a valid Wildcard SSL certificate, TLS connections to OpenLDAP fail with: > > TLS certificate verification: Error, unable to get local issuer certificate > > When OpenLDAP 2.4.9 is compiled against OpenSSL (version 0.9.8c in my testing) > and using the same certificate, connections work properly. > > Please contact me if you need any additional information. This sounds an awful lot like ITS#5361, which is a known defect in GnuTLS. What exactly do you mean by "Wildcard SSL certificate" ? There are a couple different approaches to that. One uses the subjectAltName extension, and that is the officially sanctioned approach. One uses "*" in the certificate CN, and that is non-standard and generally not supposed to work. -- -- 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#5513) back-ldap+ppolicy bind assertion failure
by mbackes＠symas.com 17 May '08

17 May '08

> I've been able to reproduce the issue, and I think it's solved > (back-ldap/search.c 1.235 -> 1.236); however I'm afraid I didn't > understand all the details of your configuration, so I might have > tested something different. > > The bug was in ldap_back_entry_get() setting up a connection based > on the o_tag field, which is that of the current operation (a bind, > in your case). I fixed it by always re-setting the tag to > LDAP_REQ_SEARCH, under the assumption that ldap_back_entry_get() > doesn't need to know what operation required the entry to be looked > up. > > Please test and report; in case of further issues, I might need the > full slapd.conf of the proxy (unless the above is all, of course...) Thanks; this seems to fix the issue, at least in my test cases. Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

(ITS#5516) acl_set_cb_gather() incorrectly handles multiple attrs
by ando＠sys-net.it 17 May '08

17 May '08

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Only the last attribute is considered. Reported in <http://www.openldap.org/lists/openldap-devel/200805/msg00075.html>. A fix is coming.

1 0

Re: (ITS#5513) back-ldap+ppolicy bind assertion failure
by ando＠sys-net.it 17 May '08

17 May '08

mbackes(a)symas.com wrote: > A basic back-ldap configuration with the password policy overlay stacked on top > results in an assertfail for the second bind. e.g. given a working (possibly > empty db) on ldap://localhost:1389/... > > include ...../core.schema > include ...../ppolicy.schema > > modulepath ..... > moduleload back_ldap.la > moduleload ppolicy.la > > database ldap > suffix "" > uri ldap://localhost:1389/ > > After performing a successful remote bind, the next bind attempt halts the > back-ldap directory with: > > slapd: bind.c:905: ldap_back_getconn: Assertion `( li->li_idassert.si_flags & > (0x02U) )' failed. > > where 0x02U here is LDAP_BACK_AUTH_OVERRIDE. > > This happens under both OpenLDAP 2.3 and 2.4. I've been able to reproduce the issue, and I think it's solved (back-ldap/search.c 1.235 -> 1.236); however I'm afraid I didn't understand all the details of your configuration, so I might have tested something different. The bug was in ldap_back_entry_get() setting up a connection based on the o_tag field, which is that of the current operation (a bind, in your case). I fixed it by always re-setting the tag to LDAP_REQ_SEARCH, under the assumption that ldap_back_entry_get() doesn't need to know what operation required the entry to be looked up. Please test and report; in case of further issues, I might need the full slapd.conf of the proxy (unless the above is all, of course...) 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: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5502) LDAP problem
by ando＠sys-net.it 17 May '08

17 May '08

javed_ansari(a)infosys.com wrote: > Full_Name: Javed Ansari > Version: 2.3.30 > OS: Sun > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (220.225.64.6) > > > Since yesterday, we are facing LDAP problems while insertion of data. When we > try to insert data in the ldap we get the following error: > > [LDAP: error code 80 - entry store failed] > > There however seems to be no problem with the login though, this occurs only > during registration You seem to be a little bit too confident on our capability to predict the server's behavior based on a very limited amount of information. Based on the accuracy of your issue report, all I can tell is that you seem to have a problem. Please follow guidelines at <http://www.openldap.org/faq/data/cache/56.html> and provide a decent issue report. 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: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5515) v2.4.9 + GnuTLS fails with wildcard certificate, OpenSSL works correctly
by bgoldsbury＠gleim.com 16 May '08

16 May '08

Full_Name: Ben Goldsbury Version: 2.4.9 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.208.68.2) When OpenLDAP 2.4.9 is compiled against GnuTLS (version 2.2.1 in my testing) and using a valid Wildcard SSL certificate, TLS connections to OpenLDAP fail with: TLS certificate verification: Error, unable to get local issuer certificate When OpenLDAP 2.4.9 is compiled against OpenSSL (version 0.9.8c in my testing) and using the same certificate, connections work properly. Please contact me if you need any additional information.

1 0

Re: (ITS#5510) Does GSSAPI failure kill slapd?
by h.b.furuseth＠usit.uio.no 16 May '08

16 May '08

hyc(a)symas.com writes: > This looks like a pretty major compiler bug, assuming the trace is > correct. Not necessarily, valid optimizations can rearrange memory beyond a debugger's ability to figure out what's going on. Still, this does look like a strange optimization if it's a valid one. > What version of compiler did you use, were you using optimization? Can > you try with a different version and/or without optimization? -- Hallvard

1 0

Re: (ITS#5133) Synchronous replication on slave doesn't notice lost network connection
by stelios.xx.grigoriadis＠ericsson.com 16 May '08

16 May '08

We also have a patch for the stable version should anybody be interested in it. ----- # This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software # represented in the following patch(es) were developed by Stelios Grigoriadis stelios.xx.grigoriadis(a)ericsson.com. # These modifications are not subject to any license of Ericsson AB. # I, Stelios Grigoriadis, 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. # Bug Fix - This patch fixes the bug ITS#5133. # The fix works as follows. A periodic check in the runqueue (called do_mastercheck). The intervall is determined by # a slapd.conf parameter (mastercheckint) in the syncrepl section and is optional. If it's not specified, it's not # inserted in the runqueue. --- servers/slapd/syncrepl.c 2007-10-05 10:36:13.000000000 +0200 +++ syncrepl.c 2008-05-13 14:27:09.000000000 +0200 @@ -78,6 +78,7 @@ int si_manageDSAit; int si_slimit; int si_tlimit; + int si_mastercheck_int; int si_refreshDelete; int si_refreshPresent; int si_syncdata; @@ -89,6 +90,9 @@ ldap_pvt_thread_mutex_t si_mutex; } syncinfo_t; +/* Necessary in order to use asynchronous searches in mastercheck */ +static ber_int_t ps_msgid; + static int syncuuid_cmp( const void *, const void * ); static void avl_ber_bvfree( void * ); static void syncrepl_del_nonpresent( Operation *, syncinfo_t *, BerVarray, struct berval * ); @@ -314,7 +318,6 @@ BerElement *ber = (BerElement *)&berbuf; LDAPControl c[2], *ctrls[3]; struct timeval timeout; - ber_int_t msgid; int rc; int rhint; char *base; @@ -402,7 +405,7 @@ rc = ldap_search_ext( si->si_ld, base, scope, filter, attrs, attrsonly, ctrls, NULL, si->si_tlimit > 0 ? &timeout : NULL, - si->si_slimit, &msgid ); + si->si_slimit, &ps_msgid ); ber_free_buf( ber ); return rc; } @@ -667,7 +670,7 @@ tout_p = NULL; } - while (( rc = ldap_result( si->si_ld, LDAP_RES_ANY, LDAP_MSG_ONE, + while (( rc = ldap_result( si->si_ld, ps_msgid, LDAP_MSG_ONE, tout_p, &res )) > 0 ) { if ( slapd_shutdown ) { @@ -2769,6 +2772,7 @@ #define OLDAUTHCSTR "bindprincipal" #define EXATTRSSTR "exattrs" #define MANAGEDSAITSTR "manageDSAit" +#define MASTERCHECKINTSTR "mastercheckint" /* FIXME: unused */ #define LASTMODSTR "lastmod" @@ -3198,6 +3202,17 @@ Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 ); return 1; } + } else if ( !strncasecmp( c->argv[ i ], MASTERCHECKINTSTR "=", + STRLENOF( MASTERCHECKINTSTR "=" ) ) ) + { + val = c->argv[ i ] + STRLENOF( MASTERCHECKINTSTR "=" ); + if ( lutil_atoi( &si->si_mastercheck_int, val ) != 0 || si->si_mastercheck_int < 0 ) { + snprintf( c->msg, sizeof( c->msg ), + "invalid master check interval value \"%s\".\n", + val ); + Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 ); + return 1; + } } else if ( !strncasecmp( c->argv[ i ], SYNCDATASTR "=", STRLENOF( SYNCDATASTR "=" ) ) ) { @@ -3273,6 +3288,7 @@ si->si_tlimit = 0; si->si_slimit = 0; si->si_conn_setup = 0; + si->si_mastercheck_int = 0; si->si_presentlist = NULL; LDAP_LIST_INIT( &si->si_nonpresentlist ); @@ -3435,6 +3451,68 @@ ber_dupbv( bv, &bc ); } +static void * +do_mastercheck( + void *ctx, + void *arg ) +{ + struct re_s* rtask = arg; + syncinfo_t *si = ( syncinfo_t * ) rtask->arg; + int rc; + char *search_attrs[] = { NULL }; + LDAPMessage *res = 0; + struct timeval timeout; + timeout.tv_sec = 0; + timeout.tv_usec = 0; + static int mc_msg=-1; + + ldap_pvt_thread_mutex_lock( &si->si_mutex ); + if (si->si_ld) { + if (mc_msg != -1) { + res=0; + ldap_result(si->si_ld, mc_msg, 1, &timeout, &res); + if (res) { ldap_msgfree(res);} + if (rc != LDAP_SUCCESS) { + ldap_abandon_ext(si->si_ld, mc_msg, NULL, NULL); + } + } + mc_msg=-1; + rc=ldap_search_ext(si->si_ld, "", LDAP_SCOPE_BASE, "(objectClass=*)", search_attrs, + 0, NULL, NULL, NULL, 0, &mc_msg); + if (rc != LDAP_SUCCESS) { + Debug(LDAP_DEBUG_ANY,"Failed to send\n",0,0,0); + } + } + + ldap_pvt_thread_mutex_lock( &slapd_rq.rq_mutex ); + + if ( ldap_pvt_runqueue_isrunning( &slapd_rq, rtask )) { + ldap_pvt_runqueue_stoptask( &slapd_rq, rtask ); + } + + rtask->interval.tv_sec = si->si_mastercheck_int; + ldap_pvt_runqueue_resched( &slapd_rq, rtask, 0 ); + + ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex ); + + ldap_pvt_thread_mutex_unlock( &si->si_mutex ); +} + +static int add_mastercheck( ConfigArgs *c ) { + int rc; + syncinfo_t *si = c->be->be_syncinfo; + + if ( si->si_mastercheck_int == 0 ) + return 0; + + rc = ldap_pvt_runqueue_insert( &slapd_rq, si->si_mastercheck_int * 60, + do_mastercheck, si, "do_mastercheck", c->be->be_suffix[0].bv_val ); + if (rc < 0) + Debug( LDAP_DEBUG_ANY, "failed to add syncinfo\n", 0, 0, 0 ); + + return rc; +} + int syncrepl_config( ConfigArgs *c ) { @@ -3470,5 +3548,6 @@ } else if ( add_syncrepl( c ) ) { return(1); } + add_mastercheck( c ); return config_sync_shadow( c ); }

1 0

Re: (ITS#5510) Does GSSAPI failure kill slapd?
by hyc＠symas.com 15 May '08

15 May '08

aej(a)WPI.EDU wrote: >>>>>> "rein" == Rein Tollevik<rein(a)OpenLDAP.org> writes: > > rein> Could you also "print *so" from frame 5, the entry from frame 4 looks > rein> corrupt. > > connection_read(33): no connection! > SASL [conn=27] Failure: GSSAPI Error: The context has expired (No error) > sb_sasl_write: failed to encode packet: generic failure > send_search_entry: conn 27 ber write failed. > slapd: rq.c:92: ldap_pvt_runqueue_remove: Assertion `e == entry' failed. > > Program received signal SIGABRT, Aborted. > [Switching to Thread 1986071456 (LWP 27434)] > 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > (gdb) where > #0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0x00ad8815 in raise () from /lib/tls/libc.so.6 > #2 0x00ada279 in abort () from /lib/tls/libc.so.6 > #3 0x00ad1d91 in __assert_fail () from /lib/tls/libc.so.6 > #4 0x08114473 in ldap_pvt_runqueue_remove (rq=0x82c1820, entry=0x6b2a) at rq.c:92 > #5 0x080ffd9f in syncprov_free_syncop (so=0x8403c88) at syncprov.c:744 > #6 0x0810011d in syncprov_qtask (ctx=0x76610210, arg=0x845e880) at syncprov.c:949 > #7 0x08113cfd in ldap_int_thread_pool_wrapper (xpool=0x82e6c78) at tpool.c:663 > #8 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0 > #9 0x00b7a1ae in clone () from /lib/tls/libc.so.6 > (gdb) frame 5 > #5 0x080ffd9f in syncprov_free_syncop (so=0x8403c88) at syncprov.c:744 > 744 ldap_pvt_runqueue_remove(&slapd_rq, so->s_qtask ); > (gdb) print so > $1 = (syncops *) 0x8403c88 > (gdb) print *so > $2 = {s_next = 0x0, s_base = {bv_len = 6, bv_val = 0x83f9b50 "cn=log"}, s_eid = 1, s_op = 0x83fe748, s_rid = 1, s_sid = -1, > s_filterstr = {bv_len = 46, bv_val = 0x7881811c "0\001.\b\022"}, s_flags = 2, s_inuse = 0, s_res = 0x0, s_restail = 0x0, > s_qtask = 0x845e880, s_mutex = {__m_reserved = 1, __m_count = 0, __m_owner = 0x6b2a, __m_kind = 0, __m_lock = {__status = 1, > __spinlock = 0}}} This is extremely odd - the structure definition clearly shows the value of s_qtask that should have been passed to ldap_pvt_runqueue_remove, and yet your trace shows that the value that actually got passed is s_mutex.__m_owner. This looks like a pretty major compiler bug, assuming the trace is correct. What version of compiler did you use, were you using optimization? Can you try with a different version and/or without optimization? -- -- 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

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