openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

(ITS#8430) Improved handling for large number of databases
by juerg.bircher＠helmedica.com 27 May '16

27 May '16

Full_Name: Juerg Bircher Version: lmdb (master) OS: MacOS / Linux URL: ftp://ftp.openldap.org/incoming/Juerg_Bircher_160527-Improved-handling-for-… Submission from: (NULL) (178.82.37.195) There is a increased performance penalty the more databases are created within the same environment. I was looking for a way the improve that by keeping the simplicity of tracking databases within a list with direct access by index (MDB_dbi). mdb_dbi_open() is however not improved with the assumption that the database handle (dbi) is cached in the application. So mdb_dbi_open() should happen only once for each database during the life time of an application. One issue is that mdb_txn_begin() (for read-only transactions) calloc the sizeof(MDB_txn) + me_maxdbs * sizeof(MDB_db + 1). The plus 1 for the dbflags. However it is sufficient only to malloc that size and clear the sizeof(MDB_txn) memset(txn, 0, sizeof(MDB_txn) After that the data beyond the MDB_txn is not initialized which is ok for the moment. The next improvement happens in mdb_txn_renew0() where the dbflags are only set to DB_UNUSED (a new flag) for each database currently opened in the environment. memset(txn->mt_dbflags, DB_UNUSED, txn->mt_numdbs); The former code used to to loop through each database to calculate the dbflags. This is still done but lazily for each accessed database with the assumption that a read only transaction rarely uses all databases of the environment. The lazy initialization of the dbflag happens in the macro TXN_DBI_EXIST which is always used when a database handle (dbi) is passed to an function. The flags are updated in mdb_setup_db_info() once a database is access which is marked as unused (DB_UNUSED). static int mdb_setup_db_info(MDB_txn *txn, MDB_dbi dbi) { /* Setup db info */ uint16_t x = txn->mt_env->me_dbflags[dbi]; txn->mt_dbs[dbi].md_flags = x & PERSISTENT_FLAGS; txn->mt_dbflags[dbi] = (x & MDB_VALID) ? DB_VALID|DB_USRVALID|DB_STALE : 0; return (txn->mt_dbflags[dbi] & validity); } /** Check \b txn and \b dbi arguments to a function and initialize db info if needed */ #define TXN_DBI_EXIST(txn, dbi, validity) \ ((txn) && (dbi#C3C(txn)->mt_numdbs && (((txn)->mt_dbflags[dbi] & (validity)) || (((txn)->mt_dbflags[dbi] & DB_UNUSED) && mdb_setup_db_info((txn), (dbi), (validity))))) The next improvement is done in any function which needs to loop through the databases for example in mdb_cursors_close(). Again the more databases in the environment the longer the execution time. It should be best if looping only through dbflags and searching for those databases which are used (!DB_UNUSED). This could be done byte wise or more efficient in 8/4 byte steps comparing with an extended mask DB_UNUSED_LONG instead of DB_UNUSED. So we can skip 8 or 4 (32 bit) unused databases in one step (still with the assumption that a transaction rarely uses all databases of the environment). So the loop looks as follows always starting at the lower index to avoid alignment issues with ARM prior v6. #define DB_UNUSED 0x20 /**< DB not used in this txn */ #ifdef MDB_VL32 #define DB_UNUSED_LONG 0x20202020 /* DB_UNUSED long mask for fast tracking */ #else #define DB_UNUSED_LONG 0x2020202020202020 /* DB_UNUSED long mask for fast tracking */ #endif #ifdef MDB_VL32 #define MDB_WORD unsigned int #else #define MDB_WORD unsigned long long #endif MDB_dbi %3= src->mt_numdbs; MDB_dbi i = 0; while (1) { unsigned int upper = i + sizeof(MDB_WORD); if (upper < n) { // skip unused if ((*(MDB_WORD *)(tdbflags + i)) == DB_UNUSED_LONG) { i = upper; continue; } } else { upper = n; } for (; i < upper; i++) { // any other filter criteria appropriate to the function .... } if (i >= n) { break; } }

1 0

Re: (ITS#8427) Incorrect value of tls_reqcert in syncrepl
by mkp37215＠gmail.com 20 May '16

20 May '16

Howard, thanks for the reply. I just noticed a small error in what I wrote, the corrected fragment should be: "This was because sb->sb_tls_do_init was FALSE and bindconf_tls_set(sb, ld) was not called." I also would like to add that my patch changes the semantics of bindconf_tls_set, in regard of how TLS context is set, and that this is deliberate. I think that previous semantics was unclear and bug-prone, and that the new one is not only more straightforward, but also matches better the way bindconf_tls_set is used. As a result both bindconf_tls_set code and the code around its invocations is simplified. However, I was focused on its usage in slap_client_connect (because this is what was causing me problems), and I did not put much attention into other three places where bindconf_tls_set is called. All of those code fragments were basically identical, so I modified them the same way, but I think someone should review these modifications to see if they make sense. I originally intended to limit the impact of my patch to slap_client_connect, and to keep the changes inside config.c file. However, this resulted in making bad code worse, even less clear and manageable.

1 0

Re: (ITS#8427) Incorrect value of tls_reqcert in syncrepl
by hyc＠symas.com 19 May '16

19 May '16

mkp37215(a)gmail.com wrote: > The root cause of the problem: Thanks for the analysis, will look into it soon. > On syncrepl retry, code in slap_client_connect > (servers/slapd/config.c) initialized ld (LDAP) object with default > values, rather than values saved in sb (slap_bindconf). This was > because sb->sb_tls_do_init was true and bindconf_tls_set(sb, ld) was > not called. > This issue is not related to any specific TLS library. All syncrepl > retries are executed with wrong TLS settings in ld->ld_options, > including ldo_tls_require_cert, ldo_tls_keyfile, ldo_tls_certfile, > ldo_tls_cacertfile, and other (ldo_tls_require_cert has default value > 2 (demand), while string fields have nulls). However, the bug is > usually masked, because sb->sb_tls_ctx contains TLS context correctly > initialized during initial connection attempt, and this context is > assigned to ld as LDAP_OPT_X_TLS_CTX, and then used by the TLS > library, while incorrect values in ld->ld_options are ignored in most > places. But the host-checking code in ldap_int_tls_start > (libraries/libldap/tls2.c) uses ld->ld_options and triggers the bug. That description makes sense, OK. > Explanation of the patch: > The patch modifies function bindconf_tls_set that copies values from > slap_bindconf to LDAP object. Code that calls bindconf_tls_set is also > modified. > 1. If slap_bindconf object has TLS context, assign it to LDAP object. > 2. if slap_bindconf does not have a TLS context, create new context > and assign it it to both slap_bindconf and LDAP objects. > 3. Removed context replacement functionality and related conditions > (newctx). The intent of this functionality was unclear, but did not > appear to be compatible with how binconf_tls_set was used. > 4. The result of the above code changes is that TLS context is always > present and correctly assigned, while previously it sometimes was, and > sometimes wasn't. > 5. Simplified calls of bindconf_tls_set in the following files: > servers/slapd/config.c > servers/slapd/back-ldap/bind.c > servers/slapd/back-meta/conn.c > servers/slapd/back-asyncmeta/conn.c > > Things to do: > I tested the modified slap_client_connect (servers/slapd/config.c), > but the modifications to files in back-{ldap,meta,asyncmeta} were done > without proper code and functionality analysis, and without any > testing. I am hoping for a review from someone knowledgeable. > > Thank you > > > > -- -- 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#8427) Incorrect value of tls_reqcert in syncrepl
by mkp37215＠gmail.com 19 May '16

19 May '16

The root cause of the problem: On syncrepl retry, code in slap_client_connect (servers/slapd/config.c) initialized ld (LDAP) object with default values, rather than values saved in sb (slap_bindconf). This was because sb->sb_tls_do_init was true and bindconf_tls_set(sb, ld) was not called. This issue is not related to any specific TLS library. All syncrepl retries are executed with wrong TLS settings in ld->ld_options, including ldo_tls_require_cert, ldo_tls_keyfile, ldo_tls_certfile, ldo_tls_cacertfile, and other (ldo_tls_require_cert has default value 2 (demand), while string fields have nulls). However, the bug is usually masked, because sb->sb_tls_ctx contains TLS context correctly initialized during initial connection attempt, and this context is assigned to ld as LDAP_OPT_X_TLS_CTX, and then used by the TLS library, while incorrect values in ld->ld_options are ignored in most places. But the host-checking code in ldap_int_tls_start (libraries/libldap/tls2.c) uses ld->ld_options and triggers the bug. Explanation of the patch: The patch modifies function bindconf_tls_set that copies values from slap_bindconf to LDAP object. Code that calls bindconf_tls_set is also modified. 1. If slap_bindconf object has TLS context, assign it to LDAP object. 2. if slap_bindconf does not have a TLS context, create new context and assign it it to both slap_bindconf and LDAP objects. 3. Removed context replacement functionality and related conditions (newctx). The intent of this functionality was unclear, but did not appear to be compatible with how binconf_tls_set was used. 4. The result of the above code changes is that TLS context is always present and correctly assigned, while previously it sometimes was, and sometimes wasn't. 5. Simplified calls of bindconf_tls_set in the following files: servers/slapd/config.c servers/slapd/back-ldap/bind.c servers/slapd/back-meta/conn.c servers/slapd/back-asyncmeta/conn.c Things to do: I tested the modified slap_client_connect (servers/slapd/config.c), but the modifications to files in back-{ldap,meta,asyncmeta} were done without proper code and functionality analysis, and without any testing. I am hoping for a review from someone knowledgeable. Thank you

1 0

Re: (ITS#8427) Incorrect value of tls_reqcert in syncrepl
by mkp37215＠gmail.com 19 May '16

19 May '16

Proposed patch: diff -ru servers/slapd.orig/config.c servers/slapd/config.c --- servers/slapd.orig/config.c 2016-05-16 16:49:08.000000000 -0500 +++ servers/slapd/config.c 2016-05-19 20:28:54.002163670 -0500 @@ -1864,7 +1864,7 @@ int bindconf_tls_set( slap_bindconf *bc, LDAP *ld ) { - int i, rc, newctx = 0, res = 0; + int i, rc, res = 0; char *ptr = (char *)bc, **word; bc->sb_tls_do_init = 0; @@ -1878,8 +1878,7 @@ "bindconf_tls_set: failed to set %s to %s\n", bindtlsopts[i].key, *word, 0 ); res = -1; - } else - newctx = 1; + } } } if ( bc->sb_tls_reqcert ) { @@ -1890,8 +1889,7 @@ "bindconf_tls_set: failed to set tls_reqcert to %s\n", bc->sb_tls_reqcert, 0, 0 ); res = -1; - } else - newctx = 1; + } } if ( bc->sb_tls_protocol_min ) { rc = ldap_pvt_tls_config( ld, LDAP_OPT_X_TLS_PROTOCOL_MIN, @@ -1901,8 +1899,7 @@ "bindconf_tls_set: failed to set tls_protocol_min to %s\n", bc->sb_tls_protocol_min, 0, 0 ); res = -1; - } else - newctx = 1; + } } #ifdef HAVE_OPENSSL_CRL if ( bc->sb_tls_crlcheck ) { @@ -1913,17 +1910,15 @@ "bindconf_tls_set: failed to set tls_crlcheck to %s\n", bc->sb_tls_crlcheck, 0, 0 ); res = -1; - } else - newctx = 1; + } } #endif - if ( newctx ) { + if ( bc->sb_tls_ctx ) { + rc = ldap_set_option( ld, LDAP_OPT_X_TLS_CTX, bc->sb_tls_ctx ); + if ( rc ) + res = rc; + } else { int opt = 0; - - if ( bc->sb_tls_ctx ) { - ldap_pvt_tls_ctx_free( bc->sb_tls_ctx ); - bc->sb_tls_ctx = NULL; - } rc = ldap_set_option( ld, LDAP_OPT_X_TLS_NEWCTX, &opt ); if ( rc ) res = rc; @@ -2000,14 +1995,7 @@ slap_client_keepalive(ld, &sb->sb_keepalive); #ifdef HAVE_TLS - if ( sb->sb_tls_do_init ) { - rc = bindconf_tls_set( sb, ld ); - - } else if ( sb->sb_tls_ctx ) { - rc = ldap_set_option( ld, LDAP_OPT_X_TLS_CTX, - sb->sb_tls_ctx ); - } - + rc = bindconf_tls_set( sb, ld ); if ( rc ) { Debug( LDAP_DEBUG_ANY, "slap_client_connect: " diff -ru servers/slapd.orig/back-ldap/bind.c servers/slapd/back-ldap/bind.c --- servers/slapd.orig/back-ldap/bind.c 2016-05-16 16:49:07.000000000 -0500 +++ servers/slapd/back-ldap/bind.c 2016-05-19 19:41:35.654431746 -0500 @@ -735,11 +735,7 @@ sb = &li->li_tls; } - if ( sb->sb_tls_do_init ) { - bindconf_tls_set( sb, ld ); - } else if ( sb->sb_tls_ctx ) { - ldap_set_option( ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); - } + bindconf_tls_set( sb, ld ); /* if required by the bindconf configuration, force TLS */ if ( ( sb == &li->li_acl || sb == &li->li_idassert.si_bc ) && diff -ru servers/slapd.orig/back-meta/conn.c servers/slapd/back-meta/conn.c --- servers/slapd.orig/back-meta/conn.c 2016-05-16 16:49:07.000000000 -0500 +++ servers/slapd/back-meta/conn.c 2016-05-19 19:42:33.365580781 -0500 @@ -433,11 +433,7 @@ sb = &mt->mt_tls; } - if ( sb->sb_tls_do_init ) { - bindconf_tls_set( sb, msc->msc_ld ); - } else if ( sb->sb_tls_ctx ) { - ldap_set_option( msc->msc_ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); - } + bindconf_tls_set( sb, msc->msc_ld ); if ( !is_ldaps ) { if ( sb == &mt->mt_idassert.si_bc && sb->sb_tls_ctx ) { diff -ru servers/slapd.orig/back-asyncmeta/conn.c servers/slapd/back-asyncmeta/conn.c --- servers/slapd.orig/back-asyncmeta/conn.c 2016-05-16 16:49:07.000000000 -0500 +++ servers/slapd/back-asyncmeta/conn.c 2016-05-19 19:43:24.164354246 -0500 @@ -277,11 +277,7 @@ sb = &mt->mt_tls; } - if ( sb->sb_tls_do_init ) { - bindconf_tls_set( sb, msc->msc_ld ); - } else if ( sb->sb_tls_ctx ) { - ldap_set_option( msc->msc_ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); - } + bindconf_tls_set( sb, msc->msc_ld ); if ( !is_ldaps ) { if ( sb == &mt->mt_idassert.si_bc && sb->sb_tls_ctx ) { -------- END OF PATCH

1 0

Re: (ITS#8429) deadlock on a modification operation with replication
by hyc＠symas.com 19 May '16

19 May '16

elecharny(a)apache.org wrote: > Full_Name: Emmanuel Lecharny > Version: 2.4.44 > OS: Linux CentOS 6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.169.142.218) > > > I have a server blocked on a modification operation, which can neither be > shutdown nicely. Looking at the backtrace, I see that two threads are mutually > blocked (thread 2 and thread 3) : using gdb, I saw that the threads were blocked on a rmutex whose owning thread had already exited. The fact that the thread exited is due to the fact that a slapd shutdown was requested. Since the thread was gone already, there's nothing more we can extract from this process. This shows that there's a bug in the accesslog overlay, where an operation may get interrupted without releasing the rmutex. Someone will need to track that down. > > Thread 4 (Thread 0x7f305fc97700 (LWP 28853))A%A > #0 0x0000003a9ba0b63c in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f30a46395ab in ldap_pvt_thread_pool_destroy (tpool=0x727100, > run_pending=1) at /home/build/sold-2.4.44.2/openldap/libraries/libldap_r/tpool.c:817 > #2 0x000000000042c619 in slapd_daemon_task (ptr=<value optimized out>) at > /home/build/sold-2.4.44.2/openldap/servers/slapd/daemon.c:2851 > #3 0x0000003a9ba07a51 in start_thread () from /lib64/libpthread.so.0 > #4 0x0000003a9b6e896d in clone () from /lib64/libc.so.6 > > Thread 3 (Thread 0x7f305f496700 (LWP 28854)): > #0 0x0000003a9ba0b63c in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f30a463839b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized > out>, owner=139845733803776) at > /home/build/sold-2.4.44.2/openldap/libraries/libldap_r/rmutex.c:129 > #2 0x00007f30a09cf0cf in accesslog_op_mod (op=0x7f305f495450, rs=<value > optimized out>) at /home/build/sold-2.4.44.2/openldap/servers/slapd/overlays/accesslog.c:1984 > #3 0x0000000000496dc2 in overlay_op_walk (op=0x7f305f495450, rs=0x7f305f494740, > which=op_modify, oi=0x886a30, on=0x88ba10) at > /home/build/sold-2.4.44.2/openldap/servers/slapd/backover.c:661 > #4 0x0000000000497873 in over_op_func (op=0x7f305f495450, rs=<value optimized > out>, which=<value optimized out>) at > /home/build/sold-2.4.44.2/openldap/servers/slapd/backover.c:730 > #5 0x000000000048bea6 in syncrepl_updateCookie (si=0x886650, op=0x7f305f495450, > syncCookie=<value optimized out>) at > /home/build/sold-2.4.44.2/enenldap/servers/slapd/syncrepl.c:3889 > #6 0x000000000048cf1b in do_syncrep2 (op=0x7f305f495450, si=0x886650) at > /home/build/sold-2.4.44.2/openldap/servers/slapd/syncrepl.c:1187 > #7 0x00000000004932a2 in do_syncrepl (ctx=<value optimized out>, arg=0x885b50) > at /home/build/sold-2.4.44.2/openldap/servers/slapd/syncrepl.c:1561 > #8 0x00007f30a463a058 in ldap_int_thread_pool_wrapper (xpool=0x817d80) at > /home/build/sold-2.4.44.2/openldap/libraries/libldap_r/tpool.c:956 > #9 0x0000003a9ba07a51 in start_thread ()rfrom /lib62F2Flibpthread.so.0 > #10 0x0000003a9b6e896d in clone () from /lib64/libc.so.6 > > Thread 2 (Thread 0x7f305ec95700 (LWP 28855)): > #0 0x0000003a9ba0b63c in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f30a463839b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized > out>, owner=139845725411072) at > /home/build/sold-2.4.44.2/openldap/libraries/libldap_r/rmutex.c:129 > #2 0x00007f30a09cf0cf in accesslog_op_mod (op=0x7f3050114290, rs=<value > optimized out>) at /home/build/sold-2.4.44.2%2pepenldap/servers/slapd/overlays/accesslog.c:1984 > #3 0x0000000000496dc2 in overlay_op_walk (op=0x7f3050114290, rs=0x7f305ec949f0, > which=op_modify, oi=0x886a30, on=0x88ba10) at > /home/build/sold-2.4.44.2/openldap/servers/slapd/backover.c:661 > #4 0x0000000000497873 in over_op_func (op=0x7f3050114290, rs=<value optimized > out>, which=<value optimized out>) at > /home/build/sold-2.4.44.2/openldap/servers/slapd/backover.c:730 > #5 0x00000000004464eb in fe_op_modify (op=0x7f3050114290, rs=0x7f305ec949f0) at > /home/build/sold-2.4.44.2/openldap/servers/slapd/modify.c:303 > #6 0x0000000000446e16 in do_modify (op=0x7f3050114290, rs=0x7f305ec949f0) at > /home/build/sold-2.4.44.2/openldap/servers/slapd/modify.c:177 > #7 0x000000000042ea79 in connection_operation (ctx=0x7f305ec94b70, > arg_v=0x7f3050114290) at > /home/build/sold-2.4.44.2/openldap/servers/slapd/connection.c:1158 > #8 0x000000000042f265 in connection_read_thread (ctx=0x7f305ec94b70, > argv=<value optimized out>) at > /home/build/sold-2.4.44.2/openldap/servers/slapd/connection.c:1294 > #9 0x00007f30a463a058 in ldap_int_thread_pool_wrapper (xpool=0x817d80) at > /home/build/sold-2.4.44.2/openldap/libraries/libldap_r/tpool.c:956 > #10 0x0000003a9ba07a51 in start_thread () from /lib64/libpthread.so.0 > #11 0x0000003a9b6e896d in clone () from /lib64/libc.so.6 > > Thread 1 (Thread 0x7f30a3565700 (LWP 28852)): > #0 0x0000003a9ba082ad in pthread_join () from /lib64/libpthread.so.0 > #1 0x0000000000428fc9 in slapd_daemon () at > /home/build/sold-2.4.44.2/openldap/servers/apapd/daemon.c:2932 > #2 0x0000000000415135 in main (argc=9, argv=<value optimized out>) at > /home/build/sold-2.4.44.2/openldap/servers/slapd/main.c:1016 -- -- 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#8429) deadlock on a modification operation with replication
by elecharny＠apache.org 19 May '16

19 May '16

Full_Name: Emmanuel Lecharny Version: 2.4.44 OS: Linux CentOS 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.169.142.218) I have a server blocked on a modification operation, which can neither be shutdown nicely. Looking at the backtrace, I see that two threads are mutually blocked (thread 2 and thread 3) : Thread 4 (Thread 0x7f305fc97700 (LWP 28853))A%A #0 0x0000003a9ba0b63c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30a46395ab in ldap_pvt_thread_pool_destroy (tpool=0x727100, run_pending=1) at /home/build/sold-2.4.44.2/openldap/libraries/libldap_r/tpool.c:817 #2 0x000000000042c619 in slapd_daemon_task (ptr=<value optimized out>) at /home/build/sold-2.4.44.2/openldap/servers/slapd/daemon.c:2851 #3 0x0000003a9ba07a51 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003a9b6e896d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7f305f496700 (LWP 28854)): #0 0x0000003a9ba0b63c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30a463839b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=139845733803776) at /home/build/sold-2.4.44.2/openldap/libraries/libldap_r/rmutex.c:129 #2 0x00007f30a09cf0cf in accesslog_op_mod (op=0x7f305f495450, rs=<value optimized out>) at /home/build/sold-2.4.44.2/openldap/servers/slapd/overlays/accesslog.c:1984 #3 0x0000000000496dc2 in overlay_op_walk (op=0x7f305f495450, rs=0x7f305f494740, which=op_modify, oi=0x886a30, on=0x88ba10) at /home/build/sold-2.4.44.2/openldap/servers/slapd/backover.c:661 #4 0x0000000000497873 in over_op_func (op=0x7f305f495450, rs=<value optimized out>, which=<value optimized out>) at /home/build/sold-2.4.44.2/openldap/servers/slapd/backover.c:730 #5 0x000000000048bea6 in syncrepl_updateCookie (si=0x886650, op=0x7f305f495450, syncCookie=<value optimized out>) at /home/build/sold-2.4.44.2/enenldap/servers/slapd/syncrepl.c:3889 #6 0x000000000048cf1b in do_syncrep2 (op=0x7f305f495450, si=0x886650) at /home/build/sold-2.4.44.2/openldap/servers/slapd/syncrepl.c:1187 #7 0x00000000004932a2 in do_syncrepl (ctx=<value optimized out>, arg=0x885b50) at /home/build/sold-2.4.44.2/openldap/servers/slapd/syncrepl.c:1561 #8 0x00007f30a463a058 in ldap_int_thread_pool_wrapper (xpool=0x817d80) at /home/build/sold-2.4.44.2/openldap/libraries/libldap_r/tpool.c:956 #9 0x0000003a9ba07a51 in start_thread ()rfrom /lib62F2Flibpthread.so.0 #10 0x0000003a9b6e896d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7f305ec95700 (LWP 28855)): #0 0x0000003a9ba0b63c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30a463839b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=139845725411072) at /home/build/sold-2.4.44.2/openldap/libraries/libldap_r/rmutex.c:129 #2 0x00007f30a09cf0cf in accesslog_op_mod (op=0x7f3050114290, rs=<value optimized out>) at /home/build/sold-2.4.44.2%2pepenldap/servers/slapd/overlays/accesslog.c:1984 #3 0x0000000000496dc2 in overlay_op_walk (op=0x7f3050114290, rs=0x7f305ec949f0, which=op_modify, oi=0x886a30, on=0x88ba10) at /home/build/sold-2.4.44.2/openldap/servers/slapd/backover.c:661 #4 0x0000000000497873 in over_op_func (op=0x7f3050114290, rs=<value optimized out>, which=<value optimized out>) at /home/build/sold-2.4.44.2/openldap/servers/slapd/backover.c:730 #5 0x00000000004464eb in fe_op_modify (op=0x7f3050114290, rs=0x7f305ec949f0) at /home/build/sold-2.4.44.2/openldap/servers/slapd/modify.c:303 #6 0x0000000000446e16 in do_modify (op=0x7f3050114290, rs=0x7f305ec949f0) at /home/build/sold-2.4.44.2/openldap/servers/slapd/modify.c:177 #7 0x000000000042ea79 in connection_operation (ctx=0x7f305ec94b70, arg_v=0x7f3050114290) at /home/build/sold-2.4.44.2/openldap/servers/slapd/connection.c:1158 #8 0x000000000042f265 in connection_read_thread (ctx=0x7f305ec94b70, argv=<value optimized out>) at /home/build/sold-2.4.44.2/openldap/servers/slapd/connection.c:1294 #9 0x00007f30a463a058 in ldap_int_thread_pool_wrapper (xpool=0x817d80) at /home/build/sold-2.4.44.2/openldap/libraries/libldap_r/tpool.c:956 #10 0x0000003a9ba07a51 in start_thread () from /lib64/libpthread.so.0 #11 0x0000003a9b6e896d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f30a3565700 (LWP 28852)): #0 0x0000003a9ba082ad in pthread_join () from /lib64/libpthread.so.0 #1 0x0000000000428fc9 in slapd_daemon () at /home/build/sold-2.4.44.2/openldap/servers/apapd/daemon.c:2932 #2 0x0000000000415135 in main (argc=9, argv=<value optimized out>) at /home/build/sold-2.4.44.2/openldap/servers/slapd/main.c:1016 This server is configured to use delta-syncrepl. Here is the slapd.conf file : #----------------------------------------------------------------------- # Main configuration # # MMR delta-syncrepl with TLS # # Server 1 will be replicated with Server 2 : # # +--------+ +--------+ # | Server |---[TLS]---->| Server | # | 1 |<---[TLS]----| 2 | # +--------+ +--------+ # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. #----------------------------------------------------------------------- serverid 2 #----------------------------------------------------------------------- # SCHEMA INCLUDES # Use only those you need and leave the rest commented out. include /opt/symas/etc/openldap/schema/core.schema include /opt/symas/etc/openldap/schema/ppolicy.schema include /opt/symas/etc/openldap/schema/cosine.schema include /opt/symas/etc/openldap/schema/inetorgperson.schema include /opt/symas/etc/openldap/schema/krb5-kdc.schema include /opt/symas/etc/openldap/schema/rfc2307bis.schema include /opt/symas/etc/openldap/schema/openssh.schema #----------------------------------------------------------------------- # PID / STARTUP ARGS # Files in which to store the process id and startup arguments. # These files are needed by the init scripts, so only change # these if you are prepared to edit those scripts as well. pidfile /var/symas/run/mmr-delta/slapd.pid argsfile /var/symas/run/mmr-delta/slapd.args #----------------------------------------------------------------------- # TLS Setup Section TLSCACertificateFile /opt/symas/ssl/mmr-delta/cacert.pem TLSCertificateFile /opt/symas/ssl/mmr-delta/slapdcert.pem TLSCertificateKeyFile /opt/symas/ssl/mmr-delta/slapdkey.pem TLSCipherSuite HIGH:MEDIUM TLSVerifyClient try TLSProtocolMin 3.1 security ssf=128 tls=128 # This is the user that do the replication authz-regexp "email=elecharny(a)symas.com,cn=([^,]*),ou=symas,o=symas corp,l=new york,st=new jersey,c=us" "cn=replicator,dc=symas,dc=com" #----------------------------------------------------------------------- # Symas OpenLDAP supports threaded slapadd. This is only useful if running # slapadd on a multi-cpu box. Generally, assign 1 thread per # cpu, so if it is a 4 cpu box, use tool-threads 4. This # specifically affects the creation of index databases, so if # your database has fewer indices than CPUs, set it to the # number of indices. #tool-threads 2 #----------------------------------------------------------------------- # MODULE PATH # Choose the directory for loadable modules. modulepath /opt/symas/lib64/openldap # Uncomment the moduleloads as needed to enable additional # functionalityi when configured. NOTE: We package many # more modules options than those found below. moduleload back_mdb.la moduleload back_monitor.la moduleload ppolicy.la moduleload syncprov.la moduleload accesslog.la moduleload pw-sha2 D%D #----------------------------------------------------------------------- # Sample access control policy: #----------------------------------------------------------------------- access to dn="" by * read # The replicator user has write access to the while DIT # The users authenticated through a secured connection can read the DIT access to dn.subtree="dc=symas,dc=com" by dn.exact="cn=replicator,dc=symas,dc=com" write # by * tls_ssf=128 read # Allow self write access # Allow auenenticated uss s read access # Allow anonymous users to authenticate access to * by self write by users read by anonymous auth # rootdn can always write! #----------------------------------------------------------------------- # LOGGING loglevel stats sync ####################################################################### # config database ####################################################################### database config rootdn "cn=admin,cn%coconfig" rootpw {SSHA256}################### ####################################################################### # Symas LMDB database definitions #######################################################################% dAdatabase mdb suffix "dc=symas,dc=com" rootdn "dc=symas,dc=com" rootpw {SSHA256}############# limits dn.exact="cn=replicator,dc=symas,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Indices to maintain index default eq index objectClass index cn eq,sub index memberUID index givenName eq,sub index uniqueMember index mail eq,sub index entryUUID eq index entryCSN eq index uid eq,sub directory /var/symas/openldap-data/mmr-delta/symas maxsize 1073741824 #----------------------------------------------------------------------- # SYNCREPL [LDAP1, server1] syncrepl rid=1 provider=ldap://<server1>:1389 bindmethod=sasl saslmech=external starttls=yes tls_cacert=/opt/symas/ssl/mmr-delta/cacert.pem tls_cert=/opt/symas/ssl/mmr-delta/slapdcert.pem tls_key=/opt/symas/ssl/mmr-delta/slapdkey.pem tls_reqcert=demand type=refreshAndPersist searchbase="dc=symas,dc=com" filter="(objectclass=*)" scope=sub schemachecking=on retry="5 10 60 +" logbase="cn=accesslog" loilteter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog sizeLimit=unlimited timelimit=unlimited # # SYNCREPL [LDAP2, server2] syncrepl rid=2 provider=ldap://<server2>:1389 bindmethod=sasl saslmech=external starttls=yes tls_cacert=/opt/symas/ssl/mmr-delta/cacert.pem tls_cert=/opt/symas/ssl/mmr-delta/slapdcert.pem tls_key=/opt/symas/ssl/mmr-delta/slapdkey.pem tls_reqcert=demand type=refreshAndPersist searchbase="dc=symas,dc=com" filter="(objectclass=*)" scope=sub schemachecking=on retry="5 10 60 +" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject9%9(reqResult=0))" syncdata=accesslog sizeLimit=unlimited timelimit=unlimited # ENABLE MIRROR MODE mirrormode TRUE #----------------------------------------------------------------------- # Load an instance of the ppolicy overlay for the current database: overlay ppolicy # Specify the default password policy subentry to use when none is # specified in an account's entry ppolicy_default "cn=default,ou=Policies,dc=symas,dc=com" #----------------------------------------------------------------------- # Symas database overlays (syncprov and accesslog) # OVERLAY [SYNCPROV] overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 10000 syncprov-reloadhint TRUE #----------------------------------------------------------------------- # OVERLAY [ACCESSLOG] overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 24:00 01+00:00 ########################################################"3%2############# # AccessLog database ####################################################################### database mdb directory /var/symas/openldap-data/mmr-delta/accesslog maxsize 5120000 suffix "cn=accesslog" rootdn "cn=accesslog" index default eq index objectClass,entryCSN,entryUUID,reqEnd,reqResult,reqStart access to * by dn.base="cn=replicator,dc=symas,dc=com" read by dn.base="dc=symas,dc=com" write #----------------------------------------------------------------------- # AccessLog overlay (syncprov) overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE syncprov-checkpoint 100 10 syncprov-sessionlog 10000 limits dn.exact="cn=replicator,dc=symas,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited ####################################################################### # Monitor database #################################################################%#%3#### database monitor When I try to shutdown the server nicely, the logs in syslog show : May 19 04:18:15 cantal slapd[28852]: slapd shutdown: waiting for 2 operations/tasks to finish

1 0

Re: (ITS#8428) slapd segfaults under load when back-relay is used
by hyc＠symas.com 18 May '16

18 May '16

andrew.howard(a)anu.edu.au wrote: > Full_Name: Andrew Howard > Version: 2.4.40 > OS: Centos 7 3.10.0-327.18.2.el7.x86_6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (150.203.248.180) > > > When using back-relay slapd segfaults after a few minutes. > > To reproduce: I run 5 instances of getent passwd;getent group > on a system using nslcd pointing to the openldap server and > then a loop of > > ldapsearch -x -LLL -h acmeldap1.acme.org.au -b "dc=newacme,dc=edu,dc=au" > > causes slapd to segfault in a few minutes. > Thanks for the detailed report. Should be fixed now by commit 2e60bf5ed00c1a8794131f53a6c72a78c0766e21 in git master. -- -- 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#8428) slapd segfaults under load when back-relay is used
by andrew.howard＠anu.edu.au 17 May '16

17 May '16

Full_Name: Andrew Howard Version: 2.4.40 OS: Centos 7 3.10.0-327.18.2.el7.x86_6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (150.203.248.180) When using back-relay slapd segfaults after a few minutes. To reproduce: I run 5 instances of getent passwd;getent group on a system using nslcd pointing to the openldap server and then a loop of ldapsearch -x -LLL -h acmeldap1.acme.org.au -b "dc=newacme,dc=edu,dc=au" causes slapd to segfault in a few minutes. [root@acmeldap1 ~]# gdb /usr/sbin/slapd GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/sbin/slapd...Reading symbols from /usr/lib/debug/usr/sbin/slapd.debug...done. done. (gdb) run -u ldap -h "ldap:/// ldapi:///" -d 0 The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/sbin/slapd -u ldap -h "ldap:/// ldapi:///" -d 0 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". May 18 15:02:21 acmeldap1 slapd[12262]: @(#) $OpenLDAP: slapd 2.4.40 (Mar 31 2016 15:24:52) $#012#011mockbuild@worker1.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.40/openldap-2.4.%2/servers/slapd [New Thread 0x7fff37ea2700 (LWP 12263)] [New Thread 0x7fff376a1700 (LWP 12264)] [New Thread 0x7fff36ea0700 (LWP 12265)] [New Thread 0x7fff36499700 (LWP 12266)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff36499700 (LWP 12266)] 0x00007fff36498960 in ?? () (gdb) thread apply all bt Thread 5 (Thread 0x7fff36499700 (LWP 12266)): #0 0x00007fff36498960 in ?? () #1 0x00005555555a8541 in slap_writewait_play (op=0x7fff200026f0) at result.c:294 #2 send_ldap_ber (op=op@entry=0x7fff200026f0, ber=ber@entry=0x7fff36306eb0) at result.c:367 #3 0x00005555555ac11c in slap_send_search_entry (op=0x7fff200026f0, rs=<optimized out>) at result.c:1430 #4 0x0000555555645398 in mdb_search (op=<optimized out>, rs=<optimized out>) at search.c:1072 #5 0x0000555555606926 in overlay_op_walk (op=op@entry=0x7fff200026f0, rs=0x7fff36498960, which=op_search, oi=0x555555acaf90, on=0x0) at backover.c:671 #6 0x0000555555606a94 in over_op_func (op=0x7fff200026f0, rs=<optimized out>, which=<optimized out>) at backover.c:723 #7 0x00007ffff3ec1d16 in relay_back_op (op=0x7fff200026f0, rs=0x7fff36498960, which=<optimized out>) at op.c:210 #8 0x0000555555606926 in overlay_op_walk (op=op@entry=0x7fff200026f0, rs=0x7fff36496960, which=op_search, oi=0x555555aaf250, on=0x0) at backover.c:671 #9 0x0000555555606a94 in over_op_func (op=0x7fff200026f0, rs=<optimized out>, which=<optimized out>) at backover.c:723 #10 0x000055555559ad31 in fe_op_search (op=0x7fff200026f0, rs=0x7fff36498960) at search.c:402 #11 0x000055555559a5e6 in do_search (op=<optimized out>, rs=<optimized out>) at search.c:247 #12 0x0000555555597cbc in connection_operation (ctx=ctx@entry=0x7fff36498bd0, arg_v=arg_v@entry=0x7fff200026f0) at connection.c:1155 #13 0x000055555559802b in connection_read_thread (ctx=0x7fff36498bd0, argv=0x12) at connection.c:1291 #14 0x00007ffff7b92eda in ldap_int_thread_pool_wrapper (xpool=0x5555559ef2f0) at tpool.c:688 #15 0x00007ffff6e5adc5 in start_thread (arg=0x7fff36499700) at pthread_create.c:308 #16 0x00007ffff631bced in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 4 (Thread 0x7fff36ea0700 (LWP 12265)): #0 0x00007ffff6e6150d in connect () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007ffff7baa9bc in ldap_pvt_connect (async=0, addrlen=16, sin=0x7fff2c100cf0, s=17, ld=0x7fff2c100910) at os-ip.c:443 #2 ldap_connect_to_host (ld=ld@entry=0x7fff2c100910, sb=0x7fff2c108d30, proto=proto@entry=1, srv=srv@entry=0x7fff2c108e00, async=async@entry=0) at os-ip.c:657 #3 0x00007ffff7b9430e in ldap_int_open_connection (ld=ld@entry=0x7fff2c100910, conn=conn@entry=0x7fff2c108d60, srv=0x7fff2c108e00, async=async@entry=0) at open.c:379 #4 0x00007ffff7ba7bbd in ldap_new_connection (ld=ld@entry=0x7fff2c100910, srvlist=srvlist@entry=0x7fff2c1009d8, use_ldsb=use_ldsb@entry=1, connect=connect@entry=1, bind=bind@entry=0x0, m_req=m_req@entry=0, m_res=m_res@entry=0) at request.c:484 #5 0x00007ffff7b938bf in ldap_open_defconn (ld=ld@entry=0x7fff2c100910) at open.c:41 #6 0x00007ffff7ba90e8 in ldap_send_initial_request (ld=ld@entry=0x7fff2c100910, msgtype=msgtype@entry=96, dn=dn@entry=0x555555ad4b70 "cn=replicator,ou=admins,dc=acme,dc=org,dc=au", ber=ber@entry=0x7fff2c100c60, msgid=msgid@entry=1) at request.c:130 #7 0x00007ffff7b9dbd6 in ldap_sasl_bind (ld=ld@entry=0x7fff2c100910, dn=dn@entry=0x555555ad4b70 "cn=replicator,ou=admins,dc=acme,dc=org,dc=au", mechanism=mechanism@entry=0x0, cred=cred@entry=0x555555ad48b8, sctrls=sctrls@entry=0x0, cctrls=<optimized out>, msgidp=msgidp@entry=0x7fff36e9f3f4) at sasl.c:148 #8 0x00007ffff7b9e159 in ldap_sasl_bind_s (ld=0x7fff2c100910, dn=0x555555ad4b70 "cn=replicator,ou=admins,dc=acme,dc=org,dc=au", mechanism=mechanism@entry=0x0, cred=cred@entry=0x5555adad48b8, sctrls=sctrls@entry=0x0, cctrls=cctrls@entry=0x0, servercredp=servercredp@entry=0x0) at sasl.c:182 #9 0x000055555558f0ba in slap_client_connect (ldp=ldp@entry=0x555555ad4aa8, sb=sb@entry=0x555555ad4880) at config.c:2104 #10 0x00005555555ffe2d in do_syncrep1 (si=0x555555ad4850, op=0x7fff36e9f7b0) at syncrepl.c:613 #11 do_syncrepl (ctx=<optimized out>, arg=0x555555ace0a0) at syncrepl.c:1527 #12 0x00007ffff7b92eda in ldap_int_thread_pool_wrapper (xpool=0x5555559ef2f0) at tpool.c:688 #13 0x00007ffff6e5adc5 in start_thread (arg=0x7fff36ea0700) at pthread_create.c:308 #14 0x00007ffff631bced in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 3 (Thread 0x7fff376a1700 (LWP 12264)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/ux/2Fsysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007ffff7b92f2b in ldap_int_thread_pool_wrapper (xpool=0x5555559ef2f0) at tpool.c:675 #2 0x00007ffff6e5adc5 in start_thread (arg=0x7fff376a1700) at pthread_create.c:808 #3 0x00007ffff631bced in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 2 (Thread 0x7fff37ea2700 (LWP 12263)): #0 0x00007ffff631c2c3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81 #1 0x0000555555592e98 in slapd_daemon_task (ptr=<optimized out>) at daemon.c:2536 #2 0x00007ffff6e5adc5 in start_thread (arg=0x7fff37ea2700) at pthread_create.c:308 #3 0x00007ffff631bced in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 1 (Thread 0x7ffff7fe7740 (LWP 12262)): ---Type <return> to continue, or q <return> to quit--- #0 0x00007ffff6e5bef7 in pthread_join (threadid=140734131480320, thread_return=thread_return@entry=0x0) at pthread_join.c:92 #1 0x00007ffff7b935f5 in ldap_pvt_thread_join (thread=<optimized out>, thread_return=thread_return@entry=0x0) at thr_posix.c:197 #2 0x0000555555594d91 in slapd_daemon () at daemon.c:2929 #3 0x000055555557bb12 in main (argc=<optimized out>, argv=0x7fffffffe548) at main.c:1016 (gdb) (gdb) bt full #0 0x00007fff36498960 in ?? () No symbol table info available. #1 0x00005555555a8541 in slap_writewait_play (op=0x7fff200026f0) at result.c:294 sc = 0x7fff364975b0 #2 send_ldap_ber (op=op@entry=0x7fff200026f0, ber=ber@entry=0x7fff36306eb0) at result.c:367 err = <optimized out> conn = 0x555555aeaa80 bytes = 181 ret = 0 #3 0x00005555555ac11c in slap_send_search_entry (op=0x7fff200026f0, rs=<optimized out>) at result.c:1430 berbuf = { buffer = "\002\0%0\001\000\000\000\000\000\377\377\377\377\377\377\377\377", '\000' <repeats 16 times>, "\310J\000 \377\177\000\000}K\000 \377\177\000\000]P\000 \377\177\000\000\000\000\000\000\000\000\000\000\036K\000 \377\177\000\000`,\000 \377\177\000\000D\234\221UUU\0%0\000/\214[UUU\000\000\000\000\000\000\000\000\000\000\330E\000 \377\177\000\000\270\001\000\000\000\000\000\000\v\000\000\000\000\000\000\000(\000\000\000\000\000\000\000\020P\342\367\377\177\000\000\320\027\021 \377\177\000\000\314\322gUUU\000\000\320q06\377\177\000\000pg\213\071\377\177\000\000\360&\000 \377\177\000\000R\346gUUU\000\000\320\027\021 \377\177\000\000"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = 0x7fff36306eb0 a = <optimized out> i = <optimized out> j = <optimized out> rc = <optimized out> bytes = <optimized out> userattrs = 1 acl_state = {as_desc = 0x555555ad5590, as_access = ACL_READ, as_vd_acl = 0x0, as_vd_acl_present = 0, as_vd_acl_count = 0, as_vd_mask = 1, as_result = 1, as_fe_done = 0} attrsonly = 0 ad_entry = <optimized out> e_flags = 0x0 #4 0x0000555555645398 in mdb_search (op=<optimized out>, rs=<optimized out>) at search.c:1072 scopeok = 1 edata = {mv_size = 568, mv_data = 0x7fff398b6770} mdb = <optimized out> id = 8597 cursor = 8597 nsubs = 10732 ncand = <optimized out> c cscope = <optimized out> lastid = 18446744073709551615 candidates = {18446744073709551615, 1, 18446744073709551615, 0 <repeats 129310 times>, 140733730259056, 18446603339605394369, 140737323345855, 140734104157247, 140733730259056, 18446603339605394337, 140737323345855, 140734104157279, 1060864, 140733730258944, 4096, 1085440, 1081344, 0, 140733730259064, 18446603339605394193, 2, 18446603339605394177, 2, 0, 0, 390842023984, 140734104157440, 0, 0, 511101108334, 0, 140734104157439, 140733730259056, 18446603339605394145, 140734104157472, 140734104157471, 140734104157520, 0, 0, 511101108334, 0, 140734104157519, 140733730258976, 24, 140733731370544, 140734104170384, 140733730258976, 140733730258976, 2304, 2048, 2064, 93824997886480, 140737323347669, 18446603339605393921, 129, 32, 4, 408021893200, 140734104157696, 0, 0, 511101108334, 0, 140734104157695, 429496729600, 140733731370552, 140733193388032, 140733193388156, 8589934592, 64, 140734104170352, 6, 2, 140734104162064, 140733730258976, 140734104170496, 2304, 2048, 140733731370752, 93824997886480, 3, 140734104170496, 140734104157936, 3, 93824997886480, 93824997886480, 140737322968600, 140733731322016, 140733731370096, 140733731319648, 140733731322016, 140733731370320, 140733731319648, 140733731322016, 140733731370544, 140733731319648, 3, 140734104170496, 140737322967413, 8589934594, 140733731321904, 8589934594, 140733731351664, 4294967297, 140733731356192, 4294967297, 140733731356224, 0 <repeats 504 times>, 17592186044416, 0, 0, 0, 0, 2097152, 0, 0, 18446726481523507198, 18446744073707454463, 18446744073709551615, 18446744073709551615, 18446726481523507198, 18446744073709535229, 18446744073709551615, 18446744073709551615, 0 <repeats 690 times>, 16, 140734104167776, 140734104167712, 0, 16, 140734104167808, 140734104167744, 0, 0, 0, 2050, 140737347298278, 0, 140733730261184, 140734104173392, 140737347299401, 0 <repeats 33 times>, 93824993543904, 140734104168208, 93824993543904, 140734104168224, 140734104171472, 140733730271418, 93824992798118, 140734104171496, 93824992789205, 0, 0, 0, 0, 0, 140737351926868, 0, 93824997521440, 2, 93824997012688, 11, 140733730271418, 0...} iscopes = {0 <repeats 65536 times>} scopes = <optimized out> stack = <optimized out> e = 0x7fff200045d8 ---Type <return> to continue, or q <return> to quit--- base = 0x7fff200040e0 matched = 0x0 attrs = <optimized out> mask = 4159 stoptime = 1463547740 manageDSAit = <optimized out> isc = {mt = 0x7fff201117d0, mc = 0x7fff201132e0, id = 8597, scopes = 0x7fff35998010, sctmp = 0x7fff34997010, numrdns = 2, nscope = 1, oscope = 2, rdns = {{bv_len = 6, bv_val = 0x7fff3867f9e7 "cn=h75"}, {bv_len = 8, bv_val = 0x7fff39b6dfef "ou=Group"}, {bv_len = 0, bv_val = 0x0} <repeats 2046 times>}, nrdns = {{bv_len = 6, bv_val = 0x7fff3867f9e0 "cn=h75"}, {bv_len = 8, bv_val = 0x7fff39b6dfe6 "ou=group"}, {bv_len = 0, bv_val = 0x0} <repeats 2046 times>}} mci = 0x7fff20113150 mcd = 0x7fff201132e0 wwctx = {txn = 0x7fff201117d0, mcd = 0x0, key = 2999, data = {mv_size = 29, mv_data = 0x29ec}, flag = 1} cb = {sc_next = 0x7fff36497390, sc_response = 0x0, sc_cleanup = 0x0, sc_writewait = 0x555555642cd0 <mdb_writewait>, sc_private = 0x7fff36307280} opinfo = {moi_oe = {oe_next = {sle_next = 0x7fff36497590}, oe_key = 0x7ffff7e25010}, moi_txn = 0x7fff201117d0, moi_ref = 1, moi_flag = 1 '\001'} moi = 0x7fff36307230 ltid = 0x7fff201117d0 #5 0x0000555555606926 in overlay_op_walk (op=op@entry=0x7fff200026f0, rs=0x7fff36498960, which=op_search, oi=0x555555acaf90, on=0x0) at backover.c:671 func = <optimized out> rc = 32768 #6 0x0000555555606a94 in over_op_func (op=0x7fff200026f0, rs=<optimized out>, which=<optimized out>) at backover.c:723 oi = <optimized out> on = <optimized out> be = 0x555555ad0370 db = {bd_info = 0x555555919800 <slap_binfo+2240>, bd_self = 0x555555ad0370, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 55560, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x555555aca430, be_nsuffix = 0x555555aca4a0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 31, bv_val = 0x555555aca560 "cn=Manager,dc=acme,dc=org,dc=au"}, be_rootn % = {bv_len = 31, bv_val = 0x555555ad4150 "cn=manager,dc=acme,dc=org,dc=au"}, be_rootpw = {bv_len = 12, bv_val = 0x555555acaaa0 "its.a.secret"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x555555ad2d10, be_acl = 0x555555aca5f0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_uatate_refs = 0x0, be_pending_csn_list = 0x555555a4e300, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x555555ad42f0, be_pb = 0x0, be_cf_ocs = 0x55555591e8c0 <mdbocs>, be_private = 0x7ffff7e25010, be_next = {stqe_next = 0x555555ad1bc0}} cb = {sc_next = 0x7fff364975b0, sc_response = 0x555555605c60 <over_back_response>, sc_cleanup = 0x0, sc_writewait = 0x0, sc_private = 0x555555acaf90} sc = <optimized out> rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #7 0x00007ffff3ec1d16 in relay_back_op (op=0x7fff200026f0, rs=0x7fff36498960, which=<optimized out>) at op.c:210 wrap_oex = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x555555aaf152}, oe_db = 0x7fff364976a0} wrap_bd = 0x7fff364976a0 rcb = {rcb_sc = {sc_next = 0x7fff20002fb0, sc_response = 0x7ffff3ec1a70 <relay_back_response_cb>, sc_cleanup = 0x7ffff3ec1a50 <relay_back_cleanup_cb>, sc_writewait = 0x7fff36498960, sc_private = 0x7fff364976a0}, rcb_bd = 0x7fff364973c0} bd = <optimized out> func = <optimized out> fail_mode = <optimized out> rc = <optimized out> #8 0x0000555555606926 in overlay_op_walk (op=op@entry=0x7fff200026f0, rs=0x7fff36498960, which=op_search, oi=0x555555aaf250, on=0x0) at backover.c:671 func = <optimized out> rc = 32768 #9 0x0000555555606a94 in over_op_func (op=0x7fff200026f0, rs=<optimized out>, which=<optimized out>) at backover.c:723 oi = <optimized out> on = <optimized out> be = 0x555555aba870 db = {bd_info = 0x7ffff40c3120 <bi>, bd_self = 0x555555aba870, be_ctrls = '\000' <repeats 32 times>, be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = { ---Type <return> to continue, or q <return> to quit--- sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl % 0 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x555555aaf1a0, be_nsuffix = 0x555555abaa40, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x555555abab50, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x555555a3f530, be_pcl_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7ffff40c3000 <relayocs>, be_private = 0x555555aaf150, be_next = {stqe_next = 0x555555ad0370}} cb = {sc_next = 0x0, sc_response = 0x555555605c60 <over_back_response>, sc_cleanup = 0x0, sc_writewait = 0x0, sc_private = 0x555555aaf250} sc = <optimized out> rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #10 0x000055555559ad31 in fe_op_search (op=0x7fff200026f0, rs=0x7fff36498960) at search.c:402 bd = 0x555555920960 <slap_frontendDB> #11 0x000055555559a5e6 in do_search (op=<optimized out>, rs=<optimized out>) at search.c:247 base = {bv_len = 23, bv_val = 0x7fff20102cb7 "dc=newacme,dc=edu,dc=au"} siz = 0 off = 0 i = <optimized out> #12 0x0000555555597cbc in connection_operation (ctx=ctx@entry=0x7fff36498bd0, arg_v=arg_v@entry=0x7fff200026f0) at connection.c:1155 rc = 80 cancel = <optimized out> op = 0x7fff200026f0 rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 33, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 8596, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x21}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x555555aeaa80 memctx = 0x7fff20002c60 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #13 0x000055555559802b in connection_read_thread (ctx=0x7fff36498bd0, argv=0x12) at connection.c:1291 rc = <optimized out> cri = {op = 0x7fff200026f0, func = 0x0,rarg = 0x0, ctx = <optimized out>, nullop = <optimized out>} s = <optimized out> #14 0x00007ffff7b92eda in ldap_int_thread_pool_wrapper (xpool=0x5555559ef2f0) at tpool.c:688 pool = 0x5555559ef2f0 task = 0x7fff30000d80 work_list = <optimized out> ctx = {ltu_id = 140734104180480, ltu_key = {{ltk_key = 0x555555595dc0 <conn_counter_init>, ltk_data = 0x7fff20002b50, ltk_free = 0x555555595ea0 <conn_counter_destroy>}, { ltk_key = 0x5555555f04c0 <slap_sl_mem_init>, ltk_data = 0x7fff20002c60, ltk_free = 0x5555555f0380 <slap_sl_mem_destroy>}, {ltk_key = 0x5555555ac590 <slap_op_free>, ltk_data = 0x0, ltk_free = 0x5555555ac4f0 <slap_op_q_destroy>}, {ltk_key = 0x555555a4d620, ltk_data = 0x7fff201117d0, ltk_free = 0x55555567d310 <mdb_reader_free>}, { ltk_key = 0x5555556428f0 <search_stack>, ltk_data = 0x7fff34997010, ltk_free = 0x555555642a00 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 27 times>}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #15 0x00007ffff6e5adc5 in start_thread (arg=0x7fff36499700) at pthread_create.c:308 __res = <oimimized out> pd = 0x7fff36499700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140734104180480, 1625288578173050950, 1, 140734104181184, 140734104180480, 93824996187204, -1625724926964981690, ---Type <return> to continue, or q <return> to quit--- -1625304055555612602}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = %3ptimimized out> sp = <optimized out> freesize = <optimized out> #16 0x00007ffff631bced in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. (gdb) slapd.conf # # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/local/rfc2307bis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/local/eduperson.schema include /etc/openldap/schema/local/aueduperson.schema include /etc/openldap/schema/local/schac.schema include /etc/openldap/schema/local/adapns.schema include /etc/openldap/schema/local/kerberos.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openlp.ororg pidfile /run/openldap/slapd.pid argsfile /run/openldap/slapd.args # Global section serverID 1 ldap://acmeldap1.acme.org.au serverID 2 ldap://acmeldap2.acme.org.au serverID 3 ldap://acmeldap3.acme.org.au # Load dynamic backend modules: modulepath /usr/lib64/openldap moduleload back_mdb.la moduleload syncprov.la # moduleload back_ldap.la moduleload back_relay.la moduleload memberof.la moduleload auditlog.la moduleload rwm.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 #TLSCertificateFile /etc/openldap/certs/acme.crt #TLSCertificateKeyFile /etc/openldap/certs/acme.key #TLSCipherSuite HIGH:MEDIUM:+SSLv2 #TLSCACertificateFile /etc/openldap/certs/acmeca.crt sizelimit unlimited timelimit unlimited # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: access to dn.base="" by * read access to dn.base="cn=Subschema" by * read #access to * # by self write # by users read # by anonymous auth access to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ###########################################################3#23########## # MDB database definitions ####################################################################### database relay suffix "dc=newacme,dc=edu,dc=au" relay "dc=acme,dc=org,dc=au" access to attrs=userPassword,userPKCS12 by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn.exact="cn=Manager,dc=acme,dc=org,dc=au" read by self write by anonymous auth by * none access to attrs=shadowLastChange by self write by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none access to dn.subtree="dc=newacme,dc=edu,dc=au" by * read access to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,%3=external,cn=auth" write by * none overlay rwm rwm-rewriteEngine on rwm-suffixmassage "dc=newacme,dc=edu,dc=au" "dc=acme,dc=org,dc=au" database mdb #maxsize 1073741824 maxsize 3145728000 suffix "dc=acme,dc=org,dc=au" roon 09 "cn=Manager,dc=acme,dc=org,dc=au" rootpw its.a.secret # Let the replica DN have limitless searches limits dn.exact="cn=replicator,dc=acme,dc=org,dc=au" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited #updatedn "cn=replicator,dc=acme,dc=org,dc=au" # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uid eq,sub index entryUUID eq index entryCSN eq index memberuid eq index member eq index memberOf eq index gidNumber eq index uidNumber eq access to attrsDuDuserPasswor2C2CuserPKCS12 by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn.exact="cn=Manager,dc=acme,dc=org,dc=au" read by dn.exact="cn=replicator,ou=admins,dc=acme,dc=org,dc=au" read by self write by anonymous auth by * none access to attrs=shadowLastChange by self write by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn.exact="cn=Manager,dc=acme,dc=org,%c=au" read by * none access to dn.subtree="cn=kerberos,ou=services,dc=acme,dc=org,dc=au" by dn.exact="cn=krbadmin,ou=People,dc=acme,dc=org,dc=au" write by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by * none access to dn.subtree="dc=acme,dc=org,dc=au" by dn.exact="cn=Manager,dc=acme,dc=org,dc=au" write by * read #access to dn.subtree="dc=acme,dc=org,dc=au" # by dn.exact="cn=Manager,dc=acme,dc=org,dc=au" write # by * none #access to dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" write # by * none access to * by dn.base="cn=replicator,ou=Admins,dc=acme,dc=org,dc=au" read by * break overlay memberof memberof-group-oc groupOfNames memberof-member-ad member memberof-memberof-ad memberOf memberof-dangling ignore overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=004 provider=ldap://acmeldap1.acme.org.au type=refreshAndPersist retry="5 5 300 +"D%D timeout=3 searchbase="dc=acme,dc=org,dc=au" attrs="*,+" bindmethod=simple binddn="cn=replicator,ou=Admins,dc=acme,dc=org,dc=au" credentials=replicatorsecret syncrepl rid=005 provider=ldap://acmeldap2.acme.org.au type=refreshAndPersist% %A retry="5 5 300 +" timeout=3 searchbase="dc=acme,dc=org,dc=au" attrs="*,+" bindmethod=simple binddn="cn=replicator,ou=Admins,dc=acme,dc=org,dc=au" credentials=replicatorsecret syncrepl rid=006 provider=ldap://acmeldap3.acme.org.%0 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=acme,dc=org,dc=au" attrs="*,+" bindmethod=simple binddn="cn=replicator,ou=Admins,dc=acme,dc=org,dc=au" credentials=replicatorsecret database monitor access to dn="cn=monitor" byn.n.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.base="cn=Manager,dc=acme,dc=org,dc=au" read by * none database config rootpw its.a.secret

1 0

(ITS#8427) Incorrect value of tls_reqcert in syncrepl
by mkp37215＠gmail.com 16 May '16

16 May '16

Full_Name: Maciej Puzio Version: 2.4.44 and git head OS: Ubuntu 16.04 amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.112.109.41) Incorrect handling of TLS options causes syncrepl to use different values for first connection attempt and subsequent retries. In some circumstances this may result in syncrepl unable to recover from a temporary network outage. Note: This bug has very similar symptoms and occurs in similar circumstances as ITS# 8385 (that has already been fixed). However, my investigation indicates that this is a separate issue. Steps to reproduce the problem: 1. Configure two LDAP servers in dual master replication setup using slapd.conf config file as described below. 2. Provide the servers with TLS certificates that are correct but do not include an address used in syncrepl provider setting. (Note: SECURE256 requires 4096-bit RSA key) 3. Set tls_reqcert to allow in both slapd.conf and ldap.conf. 4. Start slapd on both servers. 5. Stop and restart slapd on server A. 6. Server B will write errors to syslog: slapd: do_syncrep2: rid=001 (-1) Can't contact LDAP server slapd: do_syncrepl: rid=001 rc -1 retrying (9 reieies left) Expected result: After predefined time server B will retry replication, and we will see messages: slapd: do_syncrep1: rid=001 starting refresh slapd: do_syncrep1: rid=001 finished refresh Observed result: Server B produces theollolowing messages in a loop: slapd: do_syncrepl: rid=001 rc -1 retrying (8 retries left) slapd: slap_client_connect: URI=ldaps://10.0.0.1 DN="cn=root,dc=test" ldap_sasl_bind_s failed (-1) The relevant parts of slapd.conf: (for server A at 10.0.0.1) loglevel 1 serverID 001 moduleload syncprov TLSCipherSuite SECURE256:-VERS-SSL3.0 TLSCACertificateFile /etc/ldap/ssl/ca.pem TLSCertificateFile /etc/ldap/ssl/srvA.pemATATLSCertificateKeyFile /etc/ldap/ssl/srvA.key syncrepl rid=001 provider=ldaps://10.0.0.2 type=refreshAndPersist retry="30 10 300 +" searchbase="dc=test" attrs="*,+" bindmethod=simple binddn="cn=root,dc=test" credentials="plaintext-password" tls_reqcert=allow keepalive="240:5:10" mirrormode TRUE overlay syncprov syncprov-checkpoint 10 1440 OpenLDAP was build with this configuration: ./configure --prefix=/opt/openldap --enable-debug --enable-dynamic --enable-syslog --enable-local --enable-slapd --enable-crypt --enable-modules --enable-backends --enable-ndb=no --enable-shell=no --enable-perl=no --enable-sql=no --enable-wt=no --enable-overlays --with-tls=gnutls CPPFLAGS="-Wno-format-extra-args" Note that GnuTLS was used, following Debian and Ubuntu practice. I did not test this issue with other TLS libraries, and I do not know if this issue is GnuTLS-related or not. Debug findings: The above symptoms are caused by the following lines located at the end of ldap_int_tls_start in file libraries/libldap/tls2.c: if (ld->ld_options.ldo_tls_require_cert != LDAP_OPT_X_TLS_NEVER && ld->ld_options.ldo_tls_require_cert != LDAP_OPT_X_TLS_ALLOW) { ld->ld_errno = ldap_pvt_tls_check_hostname( ld, ssl, host ); if (ld->ld_errno != LDAP_SUCCESS) { return ld->ld_errno; } } The value of ld->ld_options.ldo_tls_require_cert is correct during first syncrepl connection attempt, but incorrect during retries. During my tests I noticed that it tended to equal 2 (demand), even when tls_reqcert was set to allow or never. On other occasions I noticed this variable to assume the value of TLS_REQCERT from ldap.conf, giving a peculiar result of first syncrepl connection using setting from slapd.conf, and subsequent ones from ldap.conf. It is possible that the value is uninitialized. Further debugging showed that this situation results from slap_client_connect (servers/slapd/config.c) not calling bindconf_tls_set on retries. The relevant code is: if ( sb->sb_tls_do_init ) { rc = bindconf_tls_set( sb, ld ); } else if ( sb->sb_tls_ctx ) { rc = ldap_set_option% l ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); } Due to my limited familiarity with OpenLDAP design, I did not debug the issue further and did not find the root cause of this problem. Discusonon about relationship of this bug to ITS# 8385: On surface these bugs appear similar to each other like twins, both causing failures of syncrepl retries due to incorrect value of tls_reqcert. In fact, I found this bug while testing Ubuntu slapd and libldap packages with patch for #8385 backported. There are however some subtle differences: 1. A TLS certificate incorrect in a different way is needed to reproduce #8385: in my tests it listed a correct host, but had a key too weak for specified cipher strength. 2. Bug #8385 has much lower reproducibility (as expected for unallocated memory issue). 3. Symptoms of #8385 are a result of code in tls_g.c (tlsg_session_accept does wrong tests), while this bug results from host tests in tls2.c (ldap_int_tls_start). Both are triggered by an incorrect value of tls_reqcert. 4. I suspect a different cause leading to wrong tls_reqcert value in both bugs. Please let me know if you need further information. Thank you very much. Maciej Puzio

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