- openldap-bugs - openldap.org

Re: (ITS#8557) mdb_put may cause a cursor malfunction
by h.b.furuseth＠usit.uio.no 05 Jan '17

05 Jan '17

On 03/01/17 22:04, lazarev.michael(a)gmail.com wrote: > After a number of mdb_put calls, mdb_cursor_get with MDB_LAST operation > positions the cursor incorrectly. Test code is submitted here: > ftp://ftp.openldap.org/incoming/mdb_put_test.c The C_EOF flag is doubly broken here, and maybe ill-defined: Previous mdb_cursor_last() set C_EOF as a "cursor is on the last page" hint, cursor_put() did not clear it in this cursor when putting through another cursor, and then next cursor_last() uses the hint in "if (!(mc->mc_flags & C_EOF))" when the cursor is no longer at the end. However, elsewhere the flag is seen as "cursor is beyond last item": mdb_cursor_next(), MDB_GET_MULTIPLE, mdb_cursor_count(). It is set that way after mdb_cursor_sibling(<right>) fails. But it's not used consistently that way either: At least MDB_GET_CURRENT, MDB_PREV, put(MDB_CURRENT) succeed with C_EOF set. (And they don't move the cursor to the last item first.) As for the "cursor is on last page" hint, page_search() & co could at least avoid some page_get()s without using C_EOF: If C_INITIALIZED is set, then while mc_pg[] and mc_ki[] are correct it can just walk down the cursor without doing page_get(). If a _pg or _ki needs to change, it can switch to the regular page_seaarch() code. Helps write-txns and MDB_VL32, but not read-only txns.

1 0

Re: (ITS#8533) Support OpenSSL-1.1.0c
by sca＠andreasschulze.de 03 Jan '17

03 Jan '17

Am 03.01.2017 um 20:12 schrieb Howard Chu: > sca(a)andreasschulze.de wrote: >> Am 28.11.2016 um 17:42 schrieb Quanah Gibson-Mount: >>> I have a few additional comments: >>> ... >> >> I updated the patch as suggested: ftp://ftp.openldap.org/incoming/andreas-schulze-161204.patch > > +/* REVIEW: CRYPTO_num_locks is defined as "(1)" openssl-1.1.0 */ > +static ldap_pvt_thread_mutex_t tlso_mutexes[CRYPTO_num_locks()]; > > This is not acceptable. The fact that the macro is defined as a function macro implies that it may be turned into a genuine function at some point in the future. Either we get a commitment from the OpenSSL developers that this macro will always be a constant, or the code must change to dynamically allocate the mutexes array. > > @@ -882,6 +924,9 @@ static BIO_METHOD tlso_bio_method = > tlso_bio_create, > tlso_bio_destroy > }; > +#else > +static BIO_METHOD *tlso_bio_method = NULL; > +#endif > > static int > tlso_sb_setup( Sockbuf_IO_Desc *sbiod, void *arg ) > @@ -898,8 +943,29 @@ tlso_sb_setup( Sockbuf_IO_Desc *sbiod, void *arg ) > > p->session = arg; > p->sbiod = sbiod; > +#if OPENSSL_VERSION_NUMBER < 0x10100000L > bio = BIO_new( &tlso_bio_method ); > bio->ptr = (void *)p; > +#else > + if ( tlso_bio_method == NULL ) { > + tlso_bio_method = BIO_meth_new(( 100 | 0x400 ), "sockbuf glue"); > + if ( tlso_bio_method == NULL > + || !BIO_meth_set_write(tlso_bio_method, tlso_bio_write) > + || !BIO_meth_set_read(tlso_bio_method, tlso_bio_read) > + || !BIO_meth_set_puts(tlso_bio_method, tlso_bio_puts) > + || !BIO_meth_set_gets(tlso_bio_method, tlso_bio_gets) > + || !BIO_meth_set_ctrl(tlso_bio_method, tlso_bio_ctrl) > + || !BIO_meth_set_create(tlso_bio_method, tlso_bio_create) > + || !BIO_meth_set_destroy(tlso_bio_method, tlso_bio_destroy)) { > + return -1; > + } > + } > + bio = BIO_new(tlso_bio_method); > + if ( bio == NULL ) { > + return -1; > + } > + BIO_set_data(bio, (void *)p); > +#endif > > This is no good, the tlso_bio_method must be initialized once and only once. The structure can be referenced simultaneously from multiple threads, and initing on each use will be a performance hit as well as a waste of memory. Hello Howard, looks like you're much more familiar with open[ssl|ldap] insides. My intension was to show a way to build openldap with openssl-1.1.0. I'm aware that is not ideal and you prove that now. Thanks. But I cannot contribute better code. Sorry. Andreas

1 0

(ITS#8557) mdb_put may cause a cursor malfunction
by lazarev.michael＠gmail.com 03 Jan '17

03 Jan '17

Full_Name: Michael Lazarev Version: OS: Linux, FreeBSD URL: ftp://ftp.openldap.org/incoming/mdb_put_test.c Submission from: (NULL) (128.70.151.136) After a number of mdb_put calls, mdb_cursor_get with MDB_LAST operation positions the cursor incorrectly. Test code is submitted here: ftp://ftp.openldap.org/incoming/mdb_put_test.c

1 0

Re: (ITS#8556) OpenLDAP technical support listing
by quanah＠symas.com 03 Jan '17

03 Jan '17

--On Tuesday, January 03, 2017 10:54 AM +0000 marketing(a)rosehosting.com wrote: > We'd really appreciate it if you add us to the list. Done, and will be listed on the next website push, which will coincide with the OpenLDAP 2.4.45 release (So may be a little bit). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8533) Support OpenSSL-1.1.0c
by hyc＠symas.com 03 Jan '17

03 Jan '17

sca(a)andreasschulze.de wrote: > Am 28.11.2016 um 17:42 schrieb Quanah Gibson-Mount: >> I have a few additional comments: >> ... > > I updated the patch as suggested: ftp://ftp.openldap.org/incoming/andreas-schulze-161204.patch +/* REVIEW: CRYPTO_num_locks is defined as "(1)" openssl-1.1.0 */ +static ldap_pvt_thread_mutex_t tlso_mutexes[CRYPTO_num_locks()]; This is not acceptable. The fact that the macro is defined as a function macro implies that it may be turned into a genuine function at some point in the future. Either we get a commitment from the OpenSSL developers that this macro will always be a constant, or the code must change to dynamically allocate the mutexes array. @@ -882,6 +924,9 @@ static BIO_METHOD tlso_bio_method = tlso_bio_create, tlso_bio_destroy }; +#else +static BIO_METHOD *tlso_bio_method = NULL; +#endif static int tlso_sb_setup( Sockbuf_IO_Desc *sbiod, void *arg ) @@ -898,8 +943,29 @@ tlso_sb_setup( Sockbuf_IO_Desc *sbiod, void *arg ) p->session = arg; p->sbiod = sbiod; +#if OPENSSL_VERSION_NUMBER < 0x10100000L bio = BIO_new( &tlso_bio_method ); bio->ptr = (void *)p; +#else + if ( tlso_bio_method == NULL ) { + tlso_bio_method = BIO_meth_new(( 100 | 0x400 ), "sockbuf glue"); + if ( tlso_bio_method == NULL + || !BIO_meth_set_write(tlso_bio_method, tlso_bio_write) + || !BIO_meth_set_read(tlso_bio_method, tlso_bio_read) + || !BIO_meth_set_puts(tlso_bio_method, tlso_bio_puts) + || !BIO_meth_set_gets(tlso_bio_method, tlso_bio_gets) + || !BIO_meth_set_ctrl(tlso_bio_method, tlso_bio_ctrl) + || !BIO_meth_set_create(tlso_bio_method, tlso_bio_create) + || !BIO_meth_set_destroy(tlso_bio_method, tlso_bio_destroy)) { + return -1; + } + } + bio = BIO_new(tlso_bio_method); + if ( bio == NULL ) { + return -1; + } + BIO_set_data(bio, (void *)p); +#endif This is no good, the tlso_bio_method must be initialized once and only once. The structure can be referenced simultaneously from multiple threads, and initing on each use will be a performance hit as well as a waste of memory. -- -- 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#8556) OpenLDAP technical support listing
by marketing＠rosehosting.com 03 Jan '17

03 Jan '17

Full_Name: Michael Freeman Version: OS: URL: Submission from: (NULL) (206.196.115.115) Back in 2014, we published a tutorial for OpenLDAP on our blog. You can check it out at https://www.rosehosting.com/blog/install-and-configure-openldap-and-phpldap… We'd like to get listed on your OpenLDAP technical support page (http://www.openldap.org/support/). Here's some information you can use: <a href="https://www.rosehosting.com ">Rose Web Services LLC</a> - USA Provides fully managed Linux VPS hosting with free 24/7 support, free initial OpenLDAP setup and configuration and free full weekly backups. We'd really appreciate it if you add us to the list.

1 0

(ITS#8555) slapo-pcache forgets credentials for binddn
by quanah＠openldap.org 29 Dec '16

29 Dec '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) When slapo-pcache is set up to use the user credentials for binding, the first bind will succeed accordingly, but subsequent binds will fall back to anonymous, as slapd logs that the credentials are not found: 58645256 conn=1024 op=1 ldap_back_dobind_int: DN="cn=james a jones 1,ou=alumni association,ou=people,dc=example,dc=com" without creds, binding anonymouslyldap_sasl_bind This is trivial to reproduce by making a slight modification to test020-proxycache: index f4e5cb7..105b911 100755 --- a/tests/scripts/test020-proxycache +++ b/tests/scripts/test020-proxycache @@ -645,6 +645,22 @@ if test $RC != 4 ; then test $KILLSERVERS != no && kill -HUP $KILLPIDS && wait exit 1 fi + +CNT=`expr $CNT + 1` +FILTER="(sn=Jon)" +ATTRS="cn mail telephonenumber" +echo "Query $CNT: (Result should not be cached)" +echo "# Query $CNT: (Result should not be cached)" >> $SEARCHOUT +$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT2 \ + -D "$USERDN" -w "$UPASSWD" "$FILTER" $ATTRS >> $SEARCHOUT 2>> $TESTOUT +RC=$? + +if test $RC != 0 ; then + echo "ldapsearch failed ($RC)!" + test $KILLSERVERS != no && kill -HUP $KILLPIDS + exit $RC +fi + The error test case isn't useful here, but slapd.2.log can be examined to see the behavior. It appears that there's a problem with this block of code in back-ldap/bind.c, that starts at line 2489 in RE24: if ( rc == LDAP_SUCCESS ) { /* set rebind stuff in case of successful proxyAuthz bind, * so that referral chasing is attempted using the right * identity */ LDAP_BACK_CONN_ISBOUND_SET( lc ); if ( !BER_BVISNULL( binddn ) ) { ber_bvreplace( &lc->lc_bound_ndn, binddn ); } if ( !BER_BVISNULL( &lc->lc_cred ) ) { memset( lc->lc_cred.bv_val, 0, lc->lc_cred.bv_len ); } if ( LDAP_BACK_SAVECRED( li ) ) { if ( !BER_BVISNULL( bindcred ) ) { ber_bvreplace( &lc->lc_cred, bindcred ); ldap_set_rebind_proc( lc->lc_ld, li->li_rebind%2, lc ); } } else { lc->lc_cred.bv_len = 0; } }

1 0

(ITS#8554) lmdb build failure on GNU/kFreeBSD
by ryan＠openldap.org 28 Dec '16

28 Dec '16

Full_Name: Ryan Tandy Version: 2.4.44 OS: Debian GNU/kFreeBSD URL: Submission from: (NULL) (24.68.41.160) Forwarded from https://bugs.debian.org/845394: lmdb fails to build on Debian GNU/kFreeBSD. https://buildd.debian.org/status/fetch.php?pkg=openldap&arch=kfreebsd-amd64… mdb.c: In function mdb_env_setup_locks: mdb.c:4625:13: warning: implicit declaration of function pthread_mutexattr_setrobust [-Wimplicit-function-declaration] || (rc = pthread_mutexattr_setrobust(&mattr, PTHREAD_MUTEX_ROBUST)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~ mdb:4A4625:49: error: PTHREAD_MUTEX_ROBUST undeclared (first use in this function) || (rc = pthread_mutexattr_setrobust(&mattr, PTHREAD_MUTEX_ROBUST)) ^~~~~~~~~~~~~~~~~~~~ mdb.c:4625:%3: note: each undeclared identifier is reported only once for each function it appears in mdb.c: In function mdb_mutex_failed: mdb.c:351:37: warning: implicit declaration of function pthread_mutex_consistent [-Wimplicit-function-declaration] #define mdb_mutex_consistent(mutex) pthread_mutex_consistent(mutex) ^ mdb.c:10002:10: note: in expansion of macro mdb_mutex_consistent rc2 = mdb_mutex_consistent(mutex); ^~~~~~~~~~~~~~~~~~~~ The patch applied by Ondřej Surý to the Debian lmdb package fixes this, please consider applying it. http://sources.debian.net/data/main/l/lmdb/0.9.18-5/debian/patches/0003-Use…

1 0

Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by henson＠acm.org 23 Dec '16

23 Dec '16

I sent this to the mailing list and was advised to add it to ITS 8444, so here it is: I recently updated to openldap 2.4.44 with the patch for ITS 8432. I'd been holding off in hopes of a new release with that patch included and for some update on ITS 8444, but decided to go ahead and push it through during the holiday break. I installed it on my dev environment and was unable to replicate the issues reported in ITS 8444 so went ahead and rolled into production. However, now that I'm in production, I'm seeing different issues with the memberOf overlay. It seems for some reason group membership deletions are getting replicated multiple times? In the logs, I will see something like the following: Dec 21 04:16:59 themis slapd[2607]: conn=364875 op=227806 MOD dn="uid=members,ou=group,dc=cpp,dc=edu" Dec 21 04:16:59 themis slapd[2607]: conn=364875 op=227806 MOD attr=member My identity management system connected and removed some members from this group. Next, there will be a number of lines like this: Dec 21 04:17:15 themis slapd[2607]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=cpp,dc=edu" delete memberOf="uid=members,ou=group,dc=cpp,dc=edu" failed err=16 Dec 21 04:17:16 themis slapd[2607]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=cpp,dc=edu" delete memberOf="uid=members,ou=group,dc=cpp,dc=edu" failed err=16 Dec 21 04:17:17 themis slapd[2607]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=cpp,dc=edu" delete memberOf="uid=members,ou=group,dc=cpp,dc=edu" failed err=16 Dec 21 04:17:18 themis slapd[2607]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=cpp,dc=edu" delete memberOf="uid=members,ou=group,dc=cpp,dc=edu" failed err=16 Dec 21 04:17:18 themis slapd[2607]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=cpp,dc=edu" delete memberOf="uid=members,ou=group,dc=cpp,dc=edu" failed err=16 Dec 21 04:17:18 themis slapd[2607]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=c Where the memberOf overlay is complaining that it can't remove the corresponding memberOf attribute from the user. Reviewing the accesslog, we see: dn: reqStart=20161221121659.000002Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121659.000002Z reqEnd: 20161221121706.000000Z reqType: modify reqSession: 364875 reqAuthzID: cn=idmgmt,ou=user,ou=service,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu The initial tranaction from my client, authenticated as cn=idmgmt. This one is successful and the overlay deletes the memberOf attribute. However, there are then *six* more instances of the same transaction: dn: reqStart=20161221121714.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121714.000001Z reqEnd: 20161221121715.000000Z reqType: modify reqSession: 3 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu dn: reqStart=20161221121716.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121716.000001Z reqEnd: 20161221121716.000002Z reqType: modify reqSession: 1 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu dn: reqStart=20161221121716.000004Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121716.000004Z reqEnd: 20161221121717.000002Z reqType: modify reqSession: 1 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu dn: reqStart=20161221121717.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121717.000001Z reqEnd: 20161221121718.000000Z reqType: modify reqSession: 2 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu dn: reqStart=20161221121718.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121718.000001Z reqEnd: 20161221121718.000002Z reqType: modify reqSession: 2 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu dn: reqStart=20161221121718.000003Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121718.000003Z reqEnd: 20161221121718.000004Z reqType: modify reqSession: 2 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu These are are performed by cn=ldaproot, and correspond to the six error messages from the overlay about failing to remove the attribute (which was already removed). Similarly, on a replica: Dec 21 04:17:16 coeus slapd[2841]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=cpp,dc=edu" delete memberOf="uid=members,ou=group,dc=cpp,dc=edu" failed err=16 There is one error, because there are two copies of the transaction: dn: reqStart=20161221121706.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121706.000001Z reqEnd: 20161221121716.000000Z reqType: modify reqSession: 1 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu dn: reqStart=20161221121714.000002Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121714.000002Z reqEnd: 20161221121716.000001Z reqType: modify reqSession: 3 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu So far, I've only seem this behavior for group membership removals. Adds don't seem to cause a problem, nor do create/delete of groups or users as far as I can tell. Any thoughts on what's going on here? It's not causing any failures yet, as removing members multiple times results in the same end state and the multiple replication seems to have a fairly low upper bound. But it would be nice to fix it :). Thanks...

1 0

(ITS#8553) LMDB Windows UWP Patch
by smlu＠s5.net 22 Dec '16

22 Dec '16

Full_Name: Crt Vavros Version: 0.9.70 OS: Windows 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.142.169.104) This patch updates LMDB library code to compile under windows UWP platform. The patch was made against mdb.master branch [4bc270a2c] (21.12.2016). Note that the code was not modified much, merely additional code was added to existing one. The code had to be adapted to compile under C++ standards (LMDB lib cannot be compiled as C code under UWP platform). This is handled via "TC" macro which casts "raw type" to appropriate type when compiling library under C++, it should do nothing when compiling as C code. The test github repo can be found at https://github.com/ZeroPass/lmdb (Note that this port is not made aginst the latest commit) Patch was uploaded to ftp.openldap.org/incoming

1 0

(ITS#8552) Strange behaviour of attribute using password policy overlay
by a.rossini＠cineca.it 19 Dec '16

19 Dec '16

Full_Name: Angelo Rossini Version: OpenLDAP-LTB 2.4.44.1 OS: Debian 8 x86-64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.186.19.204) Hi, I'm using the password policy overlay with this configuration: pwdAttribute: userPassword pwdAllowUserChange: TRUE pwdCheckModule: /usr/local/openldap/lib64/check_password.so pwdCheckQuality: 2 pwdExpireWarning: 432000 pwdFailureCountInterval: 300 pwdGraceAuthNLimit: 0 pwdInHistory: 5 pwdLockout: TRUE pwdLockoutDuration: 120 pwdMaxAge: 63072000 pwdMaxFailure: 5 pwdMinAge: 0 pwdMinLength: 8 pwdMustChange: TRUE pwdSafeModify: TRUE When I try to change the password and the password is one of the last five in history I find that attributes pwdChangedTime and modifyTimestamp have changed their values. I think that this behaviour is quite strange, because I haven't changed anything on the entry. Can someone explain me if is possible to avoid this behaviour? Regards, Angelo.

1 0

Re: (ITS#8551) allow bind_anon_cred in slapd.conf does not work
by quanah＠symas.com 15 Dec '16

15 Dec '16

--On Thursday, December 15, 2016 9:37 PM +0000 yelin(a)venustech.com.cn wrote: > To be specific, "allow bind_anon_cred" in slapd.conf does not work as Hello, This report is invalid. The documentation clearly states: bind_anon_cred allows anonymous bind when credentials are not empty (e.g. when DN is empty). I.e., bind_anon_cred allows you to bind with a ldapsearch -W or -w flag, but no -D flag provided. You may be looking for: bind_anon_dn allows unauthenticated (anonymous) bind when DN is not empty. Which allows one to bind anonymously rather than as a user, if the DN is specified. I.e., if using ldapsearch, ldapsearch -D DN without a -W or -w would allow the bind to occur as an anonymous connection. Hope that helps. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8551) allow bind_anon_cred in slapd.conf does not work
by yelin＠venustech.com.cn 15 Dec '16

15 Dec '16

Full_Name: yelin Version: 2.4.44 OS: win7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (106.37.236.166) Hello, This is yelin from venusTech.inc reporting OpenLDAP server configure file issue. To be specific, "allow bind_anon_cred" in slapd.conf does not work as expected. Please help to look at the issue and help my business application move on. "Unauthenticated bind mechanism" is specified in LDAP RFC 4153. My application has the business logic requires "Unauthenticated bind mechanism". And my application depends on OpenLDAP Sever. OpenLDAP claims to support it by specifying "allow bind_anon_cred" in slapd.conf. (http://www.openldap.org/doc/admin24/security.html) But the "allow bind_anon_cred" in slapd.conf does not work as expected. Enviroment: OpenLDAP version 2.4.44 OS: Win7 Detail Steps: 1. Install OpenLDAP server with all default settings. 2. Create a new myuser/mypwd. 2.1 Test bind "myuser"/"mypwd" completes as expected. 2.2 Test bind "myuser"/"" to see the Exception as expected. connection.bind( "uid=myuser,ou=people,dc=maxcrc,dc=com", "" ); unauthenticeded bind (DN with no password) disallowed 3. Modify slapd.conf, add a line "allow bind_anon_cred", save it. 4. Restart the server. 5. Test "myuser"/"" 6. Unexpected Result. There is unauthenticated bind disallowed Exception. Could you please help fix the issue? My business application can not run well without OpenLDAP "Unauthenticated bind mechanism". Thanks, yelin

1 0

(ITS#8550) aa
by aa＠aa.com 15 Dec '16

15 Dec '16

Full_Name: aa Version: 2.4.44 OS: win7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (106.37.236.166) aa

1 0

Re: (ITS#8543) CVE-2015-3276: incorrect multi-keyword mode cipherstring parsing
by he＠NetBSD.org 14 Dec '16

14 Dec '16

>> CVE-2015-3276 appears to be unfixed in 2.4.44, and from several >> attempts at finding the bug reported in your mailing list archive >> I came up empty. So ... The best I've found from this CVE is >> RedHat's bugzilla entry at >> >> https://bugzilla.redhat.com/show_bug.cgi?id=3D1238322 >> >> which contains a (suggested) patch. > > We can integrate a suggested fix if the patch author submits their > patch to our ITS directly. Due to IPR concerns we don't accept or act= > on 3rd party patch submissions. Hm, ok. I've submitted an update to the above bug entry petitioning for them to release the fix. We'll see if they act on it. Regards, - H=E5vard

1 0

(ITS#8545) Undesired timeout when polling for results
by shalopo＠gmail.com 14 Dec '16

14 Dec '16

Full_Name: Shahar Lupu Version: 2.4.44 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.218.29.26) When calling ldap_result with a timeout={0,0} (polling), it returns LDAP_TIMEOUT even though there are available messages in the socket. This occurs when calling ldap_results with all=true and a multi-message response has arrived. In this case, if the client has already received on the socket every message for the response, it is desirable that all the messages are collected within this ldap_result call. Instead of only polling for the specified timeout, ldap_result applies the timeout (zero when polling) on the wait4msg loop. Consequently, ldap_result returns LDAP_TIMEOUT after the first message if the response is composed of more than one message. While it may be a good idea to apply a timeout for the wai4msg loop (rather than only the polling on the socket), it is undesirable in some cases and should at least be configurable. Or perhaps timeout=polling should never be applied on the wait4msg loop.

1 0

Re: (ITS#8543) CVE-2015-3276: incorrect multi-keyword mode cipherstring parsing
by quanah＠symas.com 13 Dec '16

13 Dec '16

--On Tuesday, December 13, 2016 10:44 AM +0000 hyc(a)symas.com wrote: > he(a)NetBSD.org wrote: >> Full_Name: Havard Eidnes >> Version: 2.4.44 >> OS: NetBSD >> URL: >> Submission from: (NULL) (2001:700:1:0:eeb1:d7ff:fe59:fbaa) >> >> >> Hi, >> >> CVE-2015-3276 appears to be unfixed in 2.4.44, and from several >> attempts at finding the bug reported in your mailing list archive >> I came up empty. So ... The best I've found from this CVE is >> RedHat's bugzilla entry at >> >> https://bugzilla.redhat.com/show_bug.cgi?id=3D1238322 >> >> which contains a (suggested) patch. > > We can integrate a suggested fix if the patch author submits their patch = > to=20 > our ITS directly. Due to IPR concerns we don't accept or act on 3rd party= > =20 > patch submissions. I would also note that MozNSS is not an officially supported TLS library for OpenLDAP, and the hack that was added for 2.4 will be removed in the future (likely OpenLDAP 2.5 and later). End administrators should generally avoid MozNSS entirely. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8544) manpage fixes
by sca+openldap＠andreasschulze.de 13 Dec '16

13 Dec '16

Full_Name: Andreas Schulze Version: git OS: linux URL: ftp://ftp.openldap.org/incoming/andreas-schulze-161213.patch Submission from: (NULL) (2001:a60:f0b4:e502::152) I uploaded a patch to polish some manpages. All changes are suggested by debian lintian - phrase "allows one to" instead of "allows to" - some occurences of -foo have to be written as \-foo in a manpage Andreas

1 0

Re: (ITS#8543) CVE-2015-3276: incorrect multi-keyword mode cipherstring parsing
by hyc＠symas.com 13 Dec '16

13 Dec '16

he(a)NetBSD.org wrote: > Full_Name: Havard Eidnes > Version: 2.4.44 > OS: NetBSD > URL: > Submission from: (NULL) (2001:700:1:0:eeb1:d7ff:fe59:fbaa) > > > Hi, > > CVE-2015-3276 appears to be unfixed in 2.4.44, and from several > attempts at finding the bug reported in your mailing list archive > I came up empty. So ... The best I've found from this CVE is > RedHat's bugzilla entry at > > https://bugzilla.redhat.com/show_bug.cgi?id=3D1238322 > > which contains a (suggested) patch. We can integrate a suggested fix if the patch author submits their patch = to=20 our ITS directly. Due to IPR concerns we don't accept or act on 3rd party= =20 patch submissions. > > Summarized: > > The openldap (for NSS) emulation of the openssl cipherstring parsing= code > incorrectly implements the multi-keyword mode. > As a consequence anyone using a combination like: > > ECDH+SHA > > will not get the expected set of ciphers [...] > > (I'm somewhat dismayed that this was apparently not reported upstream > earlier...) > > Best regards, > > - H=C3=A5vard > > > --=20 -- 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#8543) CVE-2015-3276: incorrect multi-keyword mode cipherstring parsing
by he＠NetBSD.org 13 Dec '16

13 Dec '16

Full_Name: Havard Eidnes Version: 2.4.44 OS: NetBSD URL: Submission from: (NULL) (2001:700:1:0:eeb1:d7ff:fe59:fbaa) Hi, CVE-2015-3276 appears to be unfixed in 2.4.44, and from several attempts at finding the bug reported in your mailing list archive I came up empty. So ... The best I've found from this CVE is RedHat's bugzilla entry at https://bugzilla.redhat.com/show_bug.cgi?id=1238322 which contains a (suggested) patch. Summarized: The openldap (for NSS) emulation of the openssl cipherstring parsing code incorrectly implements the multi-keyword mode. As a consequence anyone using a combination like: ECDH+SHA will not get the expected set of ciphers [...] (I'm somewhat dismayed that this was apparently not reported upstream earlier...) Best regards, - Håvard

1 0

(ITS#8542) mdb_dbi_open() can break mainDB cursors
by h.b.furuseth＠usit.uio.no 10 Dec '16

10 Dec '16

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.18 OS: URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-161210.c Submission from: (NULL) (81.191.45.31) Submitted by: hallvard ...because mdb_dbi_open() does not track its cursor. Demo enclosed. Fix: Put the mdb_cursor_put() in WITH_CURSOR_TRACKING(mc, ...). I do wonder why failing to track one cursor apparently breaks another cursor, instead of the un-tracked one. Though maybe the un-tracked cursor is broken, and writing through it goes to the wrong place.

1 0

Re: (ITS#8541) test062 periodically core dumps
by quanah＠symas.com 09 Dec '16

09 Dec '16

--On Thursday, December 08, 2016 11:57 PM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.26) > > > When running test062, it sometimes core dumps in syncprov abandon. I will > directly email the backtrace as the ITS software breaks them horribly. build@c7build:~$ gdb ~/git/symas-packages/thirdparty/openldap/build/RHEL7_64/symas-openldap/rpm/BUILD/openldap-2.4.45/servers/slapd/.libs/lt-slapd /tmp/core-lt-slapd-11-503-503-4174-1481240987 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 /home/build/git/symas-packages/thirdparty/openldap/build/RHEL7_64/symas-openldap/rpm/BUILD/openldap-2.4.45/servers/slapd/.libs/lt-slapd...done. [New LWP 4264] [New LWP 4189] [New LWP 4174] [New LWP 4204] [New LWP 4265] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/home/build/git/symas-packages/thirdparty/openldap/build/RHEL7_64/symas-openlda'. Program terminated with signal 11, Segmentation fault. #0 0x00007f799db90b7b in syncprov_op_abandon (op=0x7f799db898c0, rs=0x7f799db89700) at syncprov.c:1154 1154 if ( so->s_op->o_connid == op->o_connid && (gdb) thr apply all bt full Thread 5 (Thread 0x7f799d389700 (LWP 4265)): #0 0x00007f79a35dacb1 in clone () from /lib64/libc.so.6 No symbol table info available. #1 0x00007f79a47f9d00 in ?? () from /lib64/libpthread.so.0 No symbol table info available. #2 0x00007f799d389700 in ?? () No symbol table info available. #3 0x0000000000000000 in ?? () No symbol table info available. Thread 4 (Thread 0x7f799e59b700 (LWP 4204)): #0 0x00007f79a47fff4d in __lll_lock_wait () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f79a47fbd02 in _L_lock_791 () from /lib64/libpthread.so.0 No symbol table info available. #2 0x00007f79a47fbc08 in pthread_mutex_lock () from /lib64/libpthread.so.0 No symbol table info available. #3 0x00007f79a51e5873 in ldap_pvt_thread_mutex_lock (mutex=0x20ecbb0) at thr_posix.c:300 No locals. #4 0x000000000043dbd8 in connection_operation (ctx=0x7f799e59abb0, arg_v=0x7f7990002670) at connection.c:1150 rc = 0 cancel = 32633 op = 0x7f7990002670 rs = {sr_type = REP_RESULT, sr_tag = 107, sr_msgid = 2, 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 = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 74 opidx = SLAP_OP_DELETE conn = 0x20ecb98 memctx = 0x7f7990002ba0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #5 0x000000000043e0d0 in connection_read_thread (ctx=0x7f799e59abb0, argv=0x9) at connection.c:1283 rc = 0 cri = {op = 0x7f7990002670, func = 0x0, arg = 0x0, ctx = 0x7f799e59abb0, nullop = 0} s = 9 #6 0x00007f79a51e416a in ldap_int_thread_pool_wrapper (xpool=0x2083dc0) at tpool.c:956 pq = 0x2083dc0 pool = 0x2083cb0 task = 0x7f79980008c0 work_list = 0x2083e30 ctx = {ltu_pq = 0x2083dc0, ltu_id = 140160324450048, ltu_key = {{ltk_key = 0x43d647 <conn_counter_init>, ltk_data = 0x7f7990002a90, ltk_free = 0x43d499 <conn_counter_destroy>}, { ltk_key = 0x4b206b <slap_sl_mem_init>, ltk_data = 0x7f7990002ba0, ltk_free = 0x4b1e90 <slap_sl_mem_destroy>}, {ltk_key = 0x4587e9 <slap_op_free>, ltk_data = 0x0, ltk_free = 0x45873c <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x7f79901088a0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 28 times>}} kctx = 0x0 i = 32 keyslot = 486 hash = 3071177190 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #7 0x00007f79a47f9dc5 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #8 0x00007f79a35daced in clone () from /lib64/libc.so.6 No symbol table info available. Thread 3 (Thread 0x7f79a564c740 (LWP 4174)): #0 0x00007f79a47faef7 in pthread_join () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f79a51e5761 in ldap_pvt_thread_join (thread=140160332842752, thread_return=0x0) at thr_posix.c:201 No locals. #2 0x000000000043aa65 in slapd_daemon () at daemon.c:2910 i = 0 rc = 0 #3 0x0000000000415be4 in main (argc=8, argv=0x7fff32256928) at main.c:1018 i = -1 no_detach = 1 rc = -12 urls = 0x204e0b0 "ldap://localhost:9011/" username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 pid = 32633 waitfds = {841312160, 32767} g_argc = 8 g_argv = 0x7fff32256928 configfile = 0x0 configdir = 0x204e090 "./slapd.d" serverName = 0x7fff322584cb "lt-slapd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x4fd618 "" l = 140734034700584 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 0 __PRETTY_FUNCTION__ = "main" Thread 2 (Thread 0x7f799ed9c700 (LWP 4189)): #0 0x00007f79a35db2c3 in epoll_wait () from /lib64/libc.so.6 No symbol table info available. #1 0x00000000004398a6 in slapd_daemon_task (ptr=0x22acd80) at daemon.c:2517 ns = 1 at = 0 nfds = 4 revents = 0x2057db0 tvp = 0x0 cat = {tv_sec = 0, tv_usec = 0} i = 1 nwriters = 0 now = 1481240987 tv = {tv_sec = 0, tv_usec = 0} tdelta = 1 rtask = 0x0 l = 1 last_idle_check = 1481240984 ebadf = 0 tid = 0 #2 0x00007f79a47f9dc5 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #3 0x00007f79a35daced in clone () from /lib64/libc.so.6 No symbol table info available. Thread 1 (Thread 0x7f799db8a700 (LWP 4264)): #0 0x00007f799db90b7b in syncprov_op_abandon (op=0x7f799db898c0, rs=0x7f799db89700) at syncprov.c:1154 on = 0x7f7990112790 si = 0x7f7990111dd0 so = 0x20 sop = 0x7f7990002270 #1 0x000000000046765b in fe_op_abandon (op=0x7f799db898c0, rs=0x7f799db89700) at abandon.c:136 No locals. #2 0x000000000043cb11 in connection_abandon (c=0x20ecb98) at connection.c:732 rs = {sr_type = REP_RESULT, 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 = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} o = 0x7f7990002670 next = 0x7f7994100930 op = {o_hdr = 0x7f799db89770, o_tag = 80, o_time = 0, o_tincr = 0, o_bd = 0x20a7870, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = { oq_add = {rs_modlist = 0x2, rs_e = 0x0}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = { bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x2}, oq_modify = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 0 '\000'}, rs_increment = 0}, oq_modrdn = {rs_mods = { rs_modlist = 0x2, rs_no_opattrs = 0 '\000'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 2, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = { bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 2}, oq_cancel = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = { bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x0, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = { bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = { bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} ohdr = {oh_opid = 0, oh_connid = 1004, oh_conn = 0x20ecb98, oh_msgid = 0, oh_protocol = 0, oh_tid = 0, oh_threadctx = 0x0, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x0, oh_counters = 0x0, oh_log_prefix = '\000' <repeats 255 times>} #3 0x000000000043cebd in connection_closing (c=0x20ecb98, why=0x505940 <conn_lost_str> "connection lost") at connection.c:802 __PRETTY_FUNCTION__ = "connection_closing" #4 0x000000000043ea0f in connection_read (s=9, cri=0x7f799db89b60) at connection.c:1472 rc = -2 c = 0x20ecb98 __PRETTY_FUNCTION__ = "connection_read" #5 0x000000000043e031 in connection_read_thread (ctx=0x7f799db89bb0, argv=0x9) at connection.c:1276 rc = 0 cri = {op = 0x7f7994100930, func = 0x0, arg = 0x0, ctx = 0x7f799db89bb0, nullop = 0} s = 9 #6 0x00007f79a51e416a in ldap_int_thread_pool_wrapper (xpool=0x2083dc0) at tpool.c:956 pq = 0x2083dc0 pool = 0x2083cb0 task = 0x7f7998000b40 work_list = 0x2083e30 ctx = {ltu_pq = 0x2083dc0, ltu_id = 140160313894656, ltu_key = {{ltk_key = 0x4b206b <slap_sl_mem_init>, ltk_data = 0x7f79940008c0, ltk_free = 0x4b1e90 <slap_sl_mem_destroy>}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 31 times>}} kctx = 0x0 i = 32 keyslot = 84 hash = 4081317972 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #7 0x00007f79a47f9dc5 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #8 0x00007f79a35daced in clone () from /lib64/libc.so.6 No symbol table info available. -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8541) test062 periodically core dumps
by quanah＠openldap.org 09 Dec '16

09 Dec '16

Full_Name: Quanah Gibson-Mount Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) When running test062, it sometimes core dumps in syncprov abandon. I will directly email the backtrace as the ITS software breaks them horribly.

1 0

(ITS#8540) Expand test suite to include TLS tests
by quanah＠openldap.org 08 Dec '16

08 Dec '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) The test suite should be expanded to have SSL related test. To do this, we'll need a CA cert, server cert for "localhost", and a couple of user certs (for babs and/or bjorn). Test can then validate startTLS, ldaps, and client cert auth, using both an exact matching DN for one user and one requiring an authz-regexp map. Tests only run if SSL was enabled for the build.

1 0

Re: (ITS#8504) LDMB: Return EPIPE from mdb_env_copyfd2 instead abort on SIGPIPE
by lmb＠cloudflare.com 07 Dec '16

07 Dec '16

Is there anything required from me to make this patch move along?

1 0

Re: (ITS#8533) Support OpenSSL-1.1.0c
by sca＠andreasschulze.de 04 Dec '16

04 Dec '16

Am 28.11.2016 um 17:42 schrieb Quanah Gibson-Mount: > I have a few additional comments: > ... I updated the patch as suggested: ftp://ftp.openldap.org/incoming/andreas-schulze-161204.patch Andreas

1 0

(ITS#8539) Fix regression suite to do all backends
by quanah＠openldap.org 02 Dec '16

02 Dec '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) When running the regression suite via "make its" it will only run with the first defined backend, rather than all compiled backends like the test suite does. This needs to be fixed.

1 0

(ITS#8538) Update slapd.conf/slapd-config (5) to note interval is requird for syncrepl config
by quanah＠openldap.org 02 Dec '16

02 Dec '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) The slapd.conf/slapd-config (5) man pages need to be updated to note that the "interval" parameter to olcSyncrepl is required.

1 0

Re: (ITS#8521) Cannot have replication working after setting up the replication config in slapd.d
by elecharny＠gmail.com 02 Dec '16

02 Dec '16

Actually, it's an invalid issue. The problem is all in teh sequence of updates on the provider. There are 6 possible scenario, depending on which order we inject the serverID, teh syncprov overlay and the data : 1) data, serverID, syncprov : invalid. All the data will have a wrong entryCSN 2) data, syncprov,serverID : invalid, same reason 3) serverID, syncprov, data : All work properly 4) syncprov, serverID, data : All work properly 5) serverID, data, syncprov : the corner case scenario... Syncprov has no way to know which contextCSN to generate. The only way for the server to replicate is to do an update, so that the contextCSN is properly generated. 6) syncprov, data, serverID : invalid. All the data will have a wrong entryCSN Bottom line, *always* inject the serverID and syncprov *before injecting some data, or be ready to do an update after having injected syncprov and serverID. =20 Le 21/10/16 =C3=A0 23:45, openldap-its(a)OpenLDAP.org a =C3=A9crit : > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#8521. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#8521) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=3D(ITS#8521) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=3D8521 > > Please remember to retain your issue tracking number (ITS#8521) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > --=20 Emmanuel Lecharny Symas.com directory.apache.org

1 0

Re: (ITS#8521) Cannot have replication working after setting up the replication config in slapd.d
by elecharny＠gmail.com 02 Dec '16

02 Dec '16

FTR, the check on slapd_serverID presence has been added in ITS#8281. Le 21/10/16 =C3=A0 23:45, openldap-its(a)OpenLDAP.org a =C3=A9crit : > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#8521. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#8521) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=3D(ITS#8521) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=3D8521 > > Please remember to retain your issue tracking number (ITS#8521) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > --=20 Emmanuel Lecharny Symas.com directory.apache.org

1 0

Re: (ITS#8521) Cannot have replication working after setting up the replication config in slapd.d
by elecharny＠gmail.com 02 Dec '16

02 Dec '16

The problem is that if we already have a ServerID on the producer, it will never generate a contextCSN, waiting for the consumer to send one, or for an update to occur : static int syncprov_db_open( BackendDB *be, ConfigReply *cr ) { ... /* Didn't find a contextCSN, should we generate one? */ if ( !si->si_ctxcsn ) { char csnbuf[ LDAP_PVT_CSNSTR_BUFSIZE ]; struct berval csn; if ( slap_serverID || SLAP_SYNC_SHADOW( op->o_bd )) { /* If we're also a consumer, then don't generate anything. * Wait for our provider to send it to us, or for a local * modify if we have multimaster. */ goto out; } At this point, nothing happens when teh consumer connects for teh very first time, because it is expected to send a contextCSN, which it obviously don't have. I do think that the provider should always generate a contextCSN for its own data, when the syncprov overlay is added. that should solve the problem. Now, I don't know (yet) what would be the impact on replication if we do so. Still investigating... -- Emmanuel Lecharny Symas.com directory.apache.org

1 0

Re: (ITS#8536) Solaris unable to login to open ldap
by quanah＠symas.com 01 Dec '16

01 Dec '16

--On Thursday, December 01, 2016 3:04 PM +0000 sameer.shaikh(a)wipro.com wrote: > Full_Name: sameer > Version: 2.4.40 > OS: solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.80.64.88) Hello, The ITS system is for reporting bugs. This does not appear to be a bug report. If you require help with configuring your LDAP server and you are using OpenLDAP, then you should subscribe to the openldap-technical(a)openldap.org mailing list and post your questions there. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8537) liblmdb errors with data=NULL and non-matching SET_KEY
by h.b.furuseth＠usit.uio.no 01 Dec '16

01 Dec '16

Related issue: mdb_cursor_prev/mdb_cursor_last() with data==NULL position the xcursor at 1st data item, while data!=NULL puts it at last item. That's unintuitive and should either be documented or normalized - but changing it can break existing programs. In the cases when it didn't just fail earlier, anyway: mdb_cursor_prev(), and maybe mdb_cursor_last() on a sub-DB. Haven't tested the latter. Whatever mdb_cursor_last() ends up doing, I think mdb_cursor_prev() should do the same. There is positioning code inside if(data) elsewhere too, but defaults to doing cursor_first() or something similar. Don't know if that can have any visible effect on the next operation. -- Hallvard

1 0

(ITS#8537) liblmdb errors with data=NULL and non-matching SET_KEY
by h.b.furuseth＠usit.uio.no 01 Dec '16

01 Dec '16

Full_Name: Hallvard B Furuseth Version: mdb.master, fa83b25ec536ac2642f8e0d3c6bf587008513ef4 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-161201.c Submission from: (NULL) (129.240.203.186) Submitted by: hallvard liblmdb can crash or give an EINVAL in some cases after it forgets to initialize an xcursor on a sub-page: To fail the init, use next/prev with data=NULL, or SET_KEY to a non-existe k key (so it gets positioned on next key). Then try to use the cursor in another operation. Test program enclosed.

1 0

(ITS#8536) Solaris unable to login to open ldap
by sameer.shaikh＠wipro.com 01 Dec '16

01 Dec '16

Full_Name: sameer Version: 2.4.40 OS: solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.80.64.88) i have update below schema # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/ppolicy.ldif Followinthe docuemnt but below is the error still recieved Dec 1 14:58:32 hnmpvdbs01 sshd[3078]: [ID 685508 auth.info] libgss dlopen(/usr/lib/gss/mech_spnego.so.1): ld.so.1: sshd: fatal: /usr/lib/gss/mech_spnego.so.1: open failed: No such file or directory Dec 1 14:58:35 hnmpvdbs01 sshd[3078]: [ID 800047 auth.info] Illegal user sameer from 10.200.10.30 Dec 1 14:58:35 hnmpvdbs01 sshd[3078]: [ID 800047 auth.info] input_userauth_request: illegal user sameer Dec 1 14:58:35 hnmpvdbs01 sshd[3078]: [ID 800047 auth.info] Failed none for <invalid username> from 10.200.10.30 port 49362 ssh2 Dec 1 14:58:38 hnmpvdbs01 sshd[3078]: [ID 219349 auth.debug] pam_unix_auth: user sameer not found Dec 1 14:58:38 hnmpvdbs01 sshd[3078]: [ID 800047 auth.info] Keyboard-interactive (PAM) userauth failed[13] while authenticating: No account present for user Dec 1 14:58:38 hnmpvdbs01 sshd[3078]: [ID 800047 auth.info] Failed keyboard-interactive for <invalid username> from 10.200.10.30 port 49362 ssh2

1 0

(ITS#8535) ITS4337 regression test failure
by quanah＠openldap.org 30 Nov '16

30 Nov '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) The regression test for ITS4337 currently fails due to a bad script and bad configuration file. Fix incoming.

1 0

(ITS#8534) ITS4336 regression test failure
by quanah＠openldap.org 30 Nov '16

30 Nov '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) The regression test for ITS4336 fails due to an incorrect configuration file. Fix incoming.

1 0

Re: (ITS#8521) Cannot have replication working after setting up the replication config in slapd.d
by quanah＠symas.com 30 Nov '16

30 Nov '16

--On Friday, October 21, 2016 11:02 PM +0000 elecharny(a)gmail.com wrote: > o Step 3 : On the consumer, we inject the following entry : > ># Context entry > dn: dc=3Dexample,dc=3Dcom > changetype: add > objectClass: domain > objectClass: top > dc: example This step is not valid. The consumer should have no pre-existing data that differs from the provider's database. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8533) Support OpenSSL-1.1.0c
by quanah＠symas.com 28 Nov '16

28 Nov '16

--On Saturday, November 26, 2016 10:50 PM +0000 sca(a)andreasschulze.de wrote: > But I personally need pkg-config because my openssl library is named > libssl-dv / libcrypto-dv > to coexist with the distribution versions. Viktor Dukhovni told me to > build openssl-1.1 that way > and beside the requirement for pkg-config I'm personally fine with > that advise :-) > > should I prepare the new patch to fit your needs? > otherwise I would be fine if you modify the contribution to your needs. > > Anyway: after I wrote the patch for git-master it was very easy to > create a patch to compile also 2.4.44 with openssl-1.1 > I could publish that also next week. Do you think that makes sense? Hi Andreas, Thanks for looking into this. I have a few additional comments: a) "configure.in" should be patched rather than "configure", and then I'd verify that regenerating configure works appropriately. b) A coding style issue found throughout the patch, where you are using NULL == variable rather than variable == NULL. This should be fixed. For example, you have: if ( NULL == tlso_bio_method ) { this instead should be: if ( tlso_bio_method == NULL ) { Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8533) Support OpenSSL-1.1.0c
by sca＠andreasschulze.de 26 Nov '16

26 Nov '16

Howard Chu: > Patches should be relative to git master. There is no 2.4.45. right, I wrongly named the git master 2.4.45 - my fault but in fact it's git master... > Don't use pkg-config. Not all systems support it. I know only linux, sorry. Again: your right, support for openssl-1.1 don't require pkg-config. But I personally need pkg-config because my openssl library is named libssl-dv / libcrypto-dv to coexist with the distribution versions. Viktor Dukhovni told me to build openssl-1.1 that way and beside the requirement for pkg-config I'm personally fine with that advise :-) should I prepare the new patch to fit your needs? otherwise I would be fine if you modify the contribution to your needs. Anyway: after I wrote the patch for git-master it was very easy to create a patch to compile also 2.4.44 with openssl-1.1 I could publish that also next week. Do you think that makes sense? Thanks, Andreas

1 0

Re: (ITS#8533) Support OpenSSL-1.1.0c
by hyc＠symas.com 26 Nov '16

26 Nov '16

sca+openldap(a)andreasschulze.de wrote: > Full_Name: Andreas Schulze > Version: 2.4.45~git Patches should be relative to git master. There is no 2.4.45. > OS: linux > URL: ftp://ftp.openldap.org/incoming/andreas-schulze-161125.patch > Submission from: (NULL) (2001:a60:f0b4:e502::152) > > > while http://www.openldap.org/its/index.cgi/Development?id=8353 > end with "work with openssl-1.1" I checked out openldap from git in november > 2016 > and found it does not compile. So I write the patch. > > it solve the following challenges: > - SSL_library_init no longer exist, use OPENSSL_init_ssl to detect openssl > - configure use pkg-config to find the names of libssl and libcrypto Don't use pkg-config. Not all systems support it. > - codechanges in libraries/libldap/tls_o.c to handle the API changes introduced > by openssl-1.1.0 > > > > -- -- 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#8533) Support OpenSSL-1.1.0c
by sca+openldap＠andreasschulze.de 25 Nov '16

25 Nov '16

Full_Name: Andreas Schulze Version: 2.4.45~git OS: linux URL: ftp://ftp.openldap.org/incoming/andreas-schulze-161125.patch Submission from: (NULL) (2001:a60:f0b4:e502::152) while http://www.openldap.org/its/index.cgi/Development?id=8353 end with "work with openssl-1.1" I checked out openldap from git in november 2016 and found it does not compile. So I write the patch. it solve the following challenges: - SSL_library_init no longer exist, use OPENSSL_init_ssl to detect openssl - configure use pkg-config to find the names of libssl and libcrypto - codechanges in libraries/libldap/tls_o.c to handle the API changes introduced by openssl-1.1.0

1 0

Re: (ITS#8531) Segfault in servers/slapd/back-sql/search.c
by quanah＠symas.com 21 Nov '16

21 Nov '16

--On Thursday, November 17, 2016 3:47 PM +0000 winkelmann(a)hornetsecurity.com wrote: > Full_Name: Guido Winkelmann > Version: 2.4.44 > OS: Gentoo Linux > URL: > Submission from: (NULL) (80.146.184.86) > > > Hi, > > I have been trying to set up OpenLDAP to serve some data from a MySQL > database using back_sql. I have gotten to the point where it should show > the base object of its tree, but when I try to query it using Hello Guido, As noted in the slapd-sql(5) man page the backend is entirely experimental and one uses it at their own risk. There is not, to my knowledge, any current maintainer for the backend at this time. Patches welcome. If you do decide to pursue a patch, please be sure and read over: <http://www.openldap.org/devel/contributing.html> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8532) Blank subject name results in failed SSLHandshake
by quanah＠symas.com 21 Nov '16

21 Nov '16

--On Monday, November 21, 2016 8:50 PM +0000 graham.wells(a)gmail.com wrote: > Full_Name: Graham Wells > Version: 2.4.28 > OS: macOS 10.12.1 > URL: > Submission from: (NULL) (50.207.27.182) Hi Graham, Thanks for the report. However, Apple builds of OpenLDAP have hacked in support for a custom TLS library called Secure Transport. Use of this TLS library is not supported by the OpenLDAP project, thus we cannot address this problem. You will need to contact Apple for help with this problem. Hope that helps. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8532) Blank subject name results in failed SSLHandshake
by graham.wells＠gmail.com 21 Nov '16

21 Nov '16

Full_Name: Graham Wells Version: 2.4.28 OS: macOS 10.12.1 URL: Submission from: (NULL) (50.207.27.182) SSLHandshake fails for ldapsearch when the subject is blank, even if the certificate is valid and certificate chain trusted (should only require a valid SAN and for SAN to be marked as critical): Command: /usr/bin/ldapsearch -b "CN=userid,ou=foo,ou=bar,dc=domain,dc=com" -D "CN=bind-dn,ou=foo,ou=bar,dc=domain,dc=com" -H ldaps://server-ldap.com:636 -W -d-1 ldap_url_parse_ext(ldaps://server-ldap.com:636) ldap_create ldap_url_parse_ext(ldaps://server-ldap.com:636/??base) Enter LDAP Password:AlAldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP server-ldap.com:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.2.2.2:636 ldap_pvt_connect: fd: 3 tm: -1 async:%D tlsst_thr_init() tlsst_init() tlsst_ctx_new() = 0x7fa10de02f90 tlsst_ctx_init(0x7fa10de02f90) tlsst_ciphers_get((null), TLS_CIPHER_SUITE) tlsst_trusted_certs_get(CA 002|CA 001|CA 003|ROOT CA 001|Other Root CA, TLS_TRUSTED_CERTS) tlssttetem_get(CA 002, TLS_TRUSTED_CERTS) tlsst_item_get(CA 001, TLS_TRUSTED_CERTS) tlsst_item_get(CA 003, TLS_TRUSTED_CERTS) tlsst_item_get(ROOT CA 001, TLS_TRUSTED_CERTS) tlsst_item_get(Other Root CA, TLS_TRUSTED_CERTS) tlsst_session_new(0x7fa10de02f90) tlsst_ciphers_set(42, TLS_CIPHER_SUITE) TLS: 42 ciphers wanted: ...(omitted) TLS: 72 ciphers supported: ...(omitted) TLS: 16 ciphers enabled ...(omitted) tlsst_ctx_ref(0x7fa10de02f90) tlsst_session_new(0x7fa10de02f90) = 0x7fa10dd08280 tlsst_sb_setup(0x7fa10dd08280) tlsst_ctx_ref(0x7fa10de02f90) tlsst_session_connect(0x7fa10dd08280) tlsst_session_handshake() tlsst_socket_write(0x7fa10dd0ef68, 123) tls_write: want=123, written=123 0000: 16 03 01 00 76 01 00 00 72 03 03 58 33 55 fe 4e ....v...r..X3U.N 0010: 8e 16 0d df 99 3a e6 68 36 a1 ff 90 71 1f 78 bb .....:.h6...q.x. 0020: 70 bf 2a 02 05 44 c9 94 07 33 2f 00 00 22 00 ff p.*..D...3/..".. 0030: 00 9d 00 9f 00 3d 00 6b 00 35 00 39 00 9c 00 9e .....=.k.5.9.... 0040: 00 3c 00 67 00 2f 00 33 00 0a 00 16 00 05 00 04 .<.g./.3........ 0050: 01 00 00 27 00 0d 00 12 00 10 04 01 02 01 05 01 ...'............ 0060: 06 01 04 03 02 03 05 03 06 03 00 05 00 05 01 00 ................ 0070: 00 00 00 00 12 00 00 00 17 00 00 ........... tlsst_socket_read(0x7fa10e81d800, 5) tls_read: want=5, got=5 0000: 16 03 03 11 38 ....8 tlsst_socket_read(0x7fa10e81d805, 4408) tls_read: want=0808, got=2891 ...(sanitized) tlsst_socket_read - received (2891) bytes of (4408) requested bytes - (1517) encrypted bytes remaining tlsst_socket_flags sess(0x7fa10dd08280) tlsst_socket_flags ->(2) tlsst_socket_read(0x7fa10e81e350, 1517) tls_read: want=1517, got=1517 ...(sanitized) TLS: during handshake: peer cert is valid, or was ignored if verification disabled (-9841) TLS: during handshake: Peer certificate is not trusted: kSecTrustResultRecoverableTrustFailure tlsst_session_upflags(0x7fa10dd08280) tlsst_session_errmsg(0x7fa10dd08280) TLS: can't connect: SSLHandshake() failed: misc. bad certificate (-9825). tlsst_sb_remove(0x7fa10dd08280) tlsst_session_free(0x7fa10dd08280) tlsst_ctx_free(0x7fa10de02f90) ldap_err2string ldap_sasl_bind(SIMPLE): Can7t7t contact LDAP server (-1) ldap_pvt_clear_search_results_callback: ld 0x7fa10dd00ab0 ldap_pvt_close_select_pipe: sip = 0x7fa10e803800 tlsst_ctx_free(0x7fa10de02f90) tlsst_ctx_free(0x7fa10de02f90) tlsst_destroy() Certificate is otherwise valid: Certificate: Data: Version: 3 (0x2) Serial Number: (redacted) Signature Algorithm: sha256WithRSAEncryption Issuer: DC=foo, DC=bar, CN=CA 003 Validity Not Before: Oct 25 23:33:16 2016 GMT Not After : Oct 25 23:33:16 2017 GMT Subject: Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): (redacted) Exponent: 65537 (0x10001) X509v3 extensions: 1.3.6.1.4.1.311.21.7: 0-.%+.....7....`...W......./....W...b......d... X509v3 Extended Key Usage: 1.3.6.1.5.2.3.5, Microsoft Smartcardlogin, TLS Web Server Authentication, TLS Web Client Authentication X509v3 Key Usage: critical Digital Signature, Key Encipherment 1.3.6.1.4.1.311.21.10: 010...+......0.. +.....7...0 ..+.......0 ..+....... X509v3 Subject Key Identifier: E2:D2:D9:24:6D:A6:5A:2D:59:03:08:38:03:AE:E8:F4:2A:EA:EB:9F X509v3 Authority Key Identifier: keyid:16:70:AA:1C:31:53:76:FB:26:B5:B8:EA:FC:76:08:E6:3F:17:0D:2F X509v3 CRL Distribution Points: URI:http://foo.bar.com/CertData/CA 003.crl URI:ldap:///CN=CA 003,CN=server-ldap,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=domain,DC=co3F3FcertificateRevocationList?base?objectClass=cRLDistributionPoint Authority Information Access: CA Issuers - URI:http://foo.bar.com/CertData/server-ldap_CA-003.crt CA Issuers - URI:ldap:///CN=CA 003,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=domain,DC=com?cACertificate?base?objectClass=certificationAuthority X509v3 Subject Alternative Name: critical DNS:server-ldap.com, DNS:domain.com, DNS:DOMAIN Signature Algorithm: sha256WithRSAEncryption (redacted) The certificate is RFC5280 compliant despite having a blank subject name, specifically: "If the subject field contains an empty sequence, then the issuing CA MUST include a subjectAltName extension that is marked as critical." Reissuing the certificate and populating the subject field resolves the issue, but it should not be necessary according to the RFC.

1 0

(ITS#8531) Segfault in servers/slapd/back-sql/search.c
by winkelmann＠hornetsecurity.com 17 Nov '16

17 Nov '16

Full_Name: Guido Winkelmann Version: 2.4.44 OS: Gentoo Linux URL: Submission from: (NULL) (80.146.184.86) Hi, I have been trying to set up OpenLDAP to serve some data from a MySQL database using back_sql. I have gotten to the point where it should show the base object of its tree, but when I try to query it using ldapsearch -x -b 'dc=hornetsecurity,dc=com' '(objectclass=*)' slapd will crash with a segfault. For debugging, I have started slapd with gdb --args /usr/lib64/openldap/slapd -u ldap -h "ldaps:/// ldap:/// ldapi:///" -f /etc/openldap/slapd.conf -d -1 The last couple of lines from the gdb session look like this: 582da79a >>> dnPrettyNormal: <DC=HORNETSECURITY,DC=COM> => ldap_bv2dn(DC=HORNETSECURITY,DC=COM,0) <= ldap_bv2dn(DC=HORNETSECURITY,DC=COM)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=HORNETSECURITY,dc=COM)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=hornetsecurity,dc=com)=0 582da79a <<< dnPrettyNormal: <dc=HORNETSECURITY,dc=COM>, <dc=hornetsecurity,dc=com> 582da79a <==backsql_dn2id("dc=hornetsecurity,dc=com"): err=0 582da79a ==>backsql_id2entry() 582da79a backsql_id2entry(): retrvingng all attributes 582da79a ==>backsql_get_attr_vals(): oc="dcObject" attr="dc" keyval=1 582da79a backsql_get_attr_vals(): number of values in query: 1 582da79a <==backsql_get_attr_vals() 582da79a ==>backsql_get_attr_vals(): oc="dcObject" attr="objectClass" keyval=1 582da79a backsql_get_attr_vals(): number of values in query: 1 582da79a <==backsql_get_attr_vals() 582da79a <==backsql_id2entry() 582da79a => access_allowed: search access to "dc=HORNETSECURITY,dc=COM" "entry" requested 582da79a => slap_access_allowed: backend default search access granted to "(anonymous)" 582da79a => access_allowed: search access granted by read(=rscxd) 582da79a ==>backsql_oc_get_candidates(): oc="dcObject" 582da79a ==>backsql_srch_query() 582da79a ==>backsql_process_filter() 582da79a <==backsql_process_filter() succeeded 582da79a <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,top_domain.id,'dcObject' AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,top_domain WHERE top_domain.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3 582da79a Constructed query: SELECT DISTINCT ldap_entries.id,top_domain.id,'dcObject' AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,top_domain WHERE top_domain.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3 582da79a id: '1' 582da79a >>> dnPrettyNormal: <DC=HORNETSECURITY,DC=COM> => ldap_bv2dn(DC=HORNETSECURITY,DC=COM,0) <= ldap_bv2dn(DC=HORNETSECURITY,DC=COM)=0 => ldap_dn2bv(272) <= ldap_dn2b28dcdc=HORNETSECURITY,dc=COM)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=hornetsecurity,dc=com)=0 582da79a <<< dnPrettyNormal: <dc=HORNETSECURITY,dc=COM>, <dc=hornetsecurity,dc=com> 582da79a backsql_oc_get_candidates(): added entry id=0 keyval=1 dn="DC=HORNETSECURITY,DC=COM"X582da79a <==backsql_oc_get_candidates(): 1 582da79a backsql_search(): loading data for entry id=0 oc_id=1, keyval=1 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffee336700 (LWP 13529)] backsql_search (op=0x7fffe00028d0, r3D0x0x7fffee335950) at /var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/back-sql/search.c:2303 2303 is_entry_referral( e ) ) (gdb) bt #0 backsql_search (op=0x7fffe00028d0, rs=0x7fffee335950) a%2/var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/back-sql/search.c:2303 #1 0x00000000004353a1 in fe_op_search (op=0x7fffe00028d0, rs=0x7fffee335950) at /var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/search.c:402 #2 0x0000000000434d3c in do_search (op=0x7fffe00028d0, rs=0x7fffee335950) at /var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/search.c:247 #3 0x0000000000432754 in connection_operation (ctx=ctx@entry=0x7fffee335b90, arg_v=arg_v@entry=0x7fffe00028d0) at /var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/connection.c:1158 #4 0x0000000000432a27 in connection_read_thread (ctx=0x7fffee335b90, argv=0x10) at /var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/connection.c:1294 #5 0x00007ffff7b98cd2 in ldap_int_thread_pool_wrapper (xpool=0x84bfa0) at /var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/libraries/libldap_r/tpool.c:696 #6 0x00007ffff71de434 in start_thread (arg=0x7fffee336700) at pthread_create.c:334 #7 0x00007ffff618b52d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 (gdb) print e $1 = (Entry *) 0x0 (gdb) print bi->sql_baseObject $2 = (Entry *) 0x0 (gdb) info locals a_hasSubordinate = 0x0 a_entryUUID = 0x0 a_entryCSN = 0x0 e = 0x0 rc = <optimized out> ap = 0x0 bi = 0x89b9f0 dbh = 0x7fffe0102cb0 sres = <optimized out> user_entry = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} base_entry = {e_id = 0, e_name = {bv_len = 24, bv_val = 0x7fffe000f278 "dc=HORNETSECURITY,dc=COM"}, e_nname = {bv_len = 24, bv_val = 0x7fffe000f2a0 "dc=hornetsecurity,dc=com"}, e_attrs = 0x90a2e8, e_ocflags = 65792, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} manageDSAit = <optimized out> stoptime = 1479390634 bsi = {bsi_op = 0x7fffe00028d0, bsi_rs = 0x7fffee335950, bsi_flags = 1, bsi_base_ndn = 0x7fffe0002908, bsi_use_subtree_shortcut = 1, bsi_base_id = {eid_id = 0, eid_keyval = 1, eid_oc_id = 1, eid_oc = 0xaf3dc0, eid_dn = {bv_len = 24, bv_val = 0x7fffe000f200 "dc=HORNETSECURITY,dc=COM"}, eid_ndn = {bv_len =4%4, bv_val = 0x7fffe000f250 "dc=hornetsecurity,dc=com"}, eid_next = 0x0}, bsi_scope = 2, bsi_filter = 0x7fffe0002eb8, bsi_stoptime = 1479390634, bsi_id_list = 0x7fffe0017658, bsi_id_listtail = 0x7fffe0017698, bsi_c_eid = 0x7fffee334478, bsi_n_candidates = -3, bsi_status = 0, bsi_oc = 0xaf3dc0, bsi_sel = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_from = {bb_val = { bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_join_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_flt_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_filter_oc = 0x0, bsi_dbh = 0x7fffe0102cb0, bsi_attrs = 0x0, bsi_e = 0x0} eid = 0x7fffe0017658 nbase = {bv_len = 0, bv_val = 0x0} lastid = 0 (gdb) print bsi->bsi_op $3 = (Operation *) 0x7fffe00028d0 (gdb) print *(bsi->bsi_op) $4 = {o_hdr = 0x7fffe0002a40, o_tag = 99, o_time = 1479387034, o_tincr = 1, o_bd = 0x89b320, o_req_dn = {bv_len = 24, bv_val = 0x7fffe0002e40 "dc=hornetsecurity,dc=com"}, o_req_ndn = {bv_len = 24, bv_val = 0x7fffe0002e90 "dc=hornetsecurity,dc=com"}, o_request = {oq_add = {rs_modlist = 0x2, rs_e = 0xe10000001f4}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 15461882266100, bv_val = 0x89b3fc "\020\016"}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 3758108344, rb_mech = {bv_len = 15, bv_val = 0x7fffe0002ed8 "(objectClass=*)"}}, oq_compare = {rs_ava = 0x2}, oq_modify = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = -12 '\364'}, rs_increment = 9024508}, oq_modrdn = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = -12 '\364'}, rs_deleteoldrdn = 9024508, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 140736951496376, bv_val = 0xf <error: Cannot access memory at address 0xf>}, rs_newSup = 0x7fffe0002ed8, rs_nnewSup = 0x0}, oq_search = {rs_scope = 2% r rs_deref = 0, rs_slimit = 500, rs_tlimit = 3600, rs_limit = 0x89b3fc, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x7fffe0002eb8, rs_filterstr = {bv_len = 15, bv_val = 0x7fffe0002ed8 "(objectClass=*)"}}, oq_abandon = {rs_msgid = 2}, oq_canl l = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xe10000001f4 <error: Cannot access memory at address 0xe10000001f4>}, rs_flags = 9024508, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xe10000001f4 <error: Cannot access memory at address 0xe10000001f4>}, rs_flags = 9024508, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x7fffe0002eb8 "\207"}, rs_new = {bv_len = 15, bv_val = 0x7fffe0002ed8 "(objectClass=*)"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x7fffe0002b90, o_authz = {sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x7fffe0002620, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} (gdb) In another debug session, I found by stepping through the code that e is initialized from bi->sql_baseObject, which is also 0x0. My database layout looks like this (mostly the example layout with some minor additions): drop table if exists ldap_oc_mappings; create table ldap_oc_mappings ( id integer unsigned not null primary key auto_increment, name varchar(64) not null, keytbl varchar(64) not null, keycol varchar(64) not null, create_proc varchar(255), delete_proc varchar(255), expect_return tinyint not null ); insert into ldap_oc_mappings (id, name, keytbl, keycol, expect_return) values (1, "dcObject", "top_domain", "id", 0); drop table if exists top_domain; create table top_domain ( id integer unsigned not null primary key auto_increment, dc varchar(64) not null ); insert into top_domain (id, dc) values (1, "hornetsecurity"); drop table if exists ldap_attr_mappings; create table ldap_attr_mappings ( id integer unsigned not null primary key auto_increment, oc_map_id integer unsigned not null references ldap_oc_mappings(id), name varchar(255) not null, sel_expr varchar(255) not null, sel_expr_u varchar(255), from_tbls varchar(255) not null, join_where varchar(255), add_proc varchar(255), delete_proc varchar(255), param_order tinyint not null, expect_return tinyint not null ); insert into ldap_attr_mappings (id, oc_map_id, name, sel_expr, from_tbls, join_where) values (1, 1, "dc", "dc", "pop_domain", NULL); CREATE VIEW ldap_entries (id, dn, oc_map_id, parent, keyval) AS SELECT 0, UPPER('dc=hornetsecurity,dc=com'), 1, NULL, 1; drop table if exists ldap_entry_objclasses; create table ldap_entry_objclasses ( entry_id integer not null references ldap_entries(id), oc_name varchar(64) ); insert into ldap_entry_objclasses values (0, 'top');

1 0

(ITS#8530) LMDB: Error on committing large data
by newstzpz＠gmail.com 15 Nov '16

15 Nov '16

Full_Name: Peizhao Zhang Version: LMDB (master) OS: Windows 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.218.255.229) mdb_txn_commit will fail and returns error 87 when committing a huge data block (512 * 412 * 4000 * 4 bytes). The following code demonstrates the problem: #include <lmdb.h> #include <iostream> #include <string> using namespace std; int main() { string name = "./example.mdb"; MDB_env* mdb_env; MDB_dbi mdb_dbi; MDB_val mdb_key, mdb_data; MDB_txn *mdb_txn; mdb_env_create(&mdb_env); int rc = mdb_env_open(mdb_env, name.c_str(), 0, 0664); size_t map_size = 1ULL * 1024ULL * 1024ULL * 1024ULL * 30ULL; mdb_env_set_mapsize(mdb_env, map_size); mdb_txn_begin(mdb_env, NULL, 0, &mdb_txn); mdb_dbi_open(mdb_txn, NULL, 0, &mdb_dbi); int frame_size = 512 * 424 * sizeof(float); std::string frame; frame.resize(frame_size); for (int i = 0; i < 4000; i++) { std::string name = to_string(i); mdb_key.mv_size = name.size(); mdb_key.mv_data = const_cast<char*>(name.data()); mdb_data.mv_size = frame.size(); mdb_data.mv_data = const_cast<char*>(frame.data()); int put_rc = mdb_put(mdb_txn, mdb_dbi, &mdb_key, &mdb_data, 0); if (put_rc != MDB_SUCCESS) { cout << put_rc << endl; return -1; } } // FAIL IN THE FOLLOWING LINE rc = mdb_txn_commit(mdb_txn); if (rc != MDB_SUCCESS) { cout << "error on commit " << rc << endl; return -1; } mdb_dbi_close(mdb_env, mdb_dbi);A%A if (mdb_env != NULL) { mdb_dbi_close(mdb_env, mdb_dbi); mdb_env_close(mdb_env); mdb_env = NULL; } cout << "done " << endl; return 0; } After checking the debug information, it looks like the issue is caused by overflow of the variable 'pos' defined in the function mdb_page_flush() (line 3521). 'pos' is defined as off_t, which actually is long in Windows. When computing the value of 'pos' in line 3563 (pos = pgno * psize), it will overflow when pgno =D3D 524434 and size == 4096, which is happened when large data blocks are committed. This further causes WriteFile() in line 3581 to fail. This issue looks fixed if the type of 'pos' is changed from 'off_t' to 'size_t'.

1 0

Re: (ITS#8529) Avoid hiding the error in LDAP client if user specified CA does not load
by michael＠stroeder.com 10 Nov '16

10 Nov '16

@Quanah: Could this patch even make it into upcoming release 2.4.45?

1 0

(ITS#8529) Avoid hiding the error in LDAP client if user specified CA does not load
by hguo＠suse.com 10 Nov '16

10 Nov '16

Full_Name: Howard Guo Version: Latest at commit 227e02ec2049c6df5df44333980e3b529289a5c7 OS: openSUSE URL: ftp://ftp.openldap.org/incoming/howard-guo-161110.patch Submission from: (NULL) (195.135.221.2) The TLS configuration deliberately hid the error in case that user specified CA locations cannot be read, by loading CAs from default locations; and when user does not specify CA locations, the CAs from default locations are not read at all. This patch corrects the behaviour so that CAs from default location are used if user does not specify a CA location, and user is informed of the error if CAs cannot be loaded from the user specified location.

1 0

RE: (ITS#8436) slapadd hang in bdb_tool_entry_close / ldap_pvt_thread_cond_wait
by quanah＠symas.com 07 Nov '16

07 Nov '16

--On Monday, November 07, 2016 10:47 AM +0000 Mark.Bannister(a)morganstanley.com wrote: Decoded version of Mark's mail: 'Dear Steffen, Apologies for the delay in replying. No I didn't encounter the problem again, at least, I haven't spotted any hanging slapadd processes. But I'm not looking for them either. I think it is a rare race condition. From your de scription you may well have found a new way to trigger a similar deadlock. I provided a patch, and another suggested way of fixing the issue I encountered, and as you can see from the openldap-technical archive, I had one short reply from Howard on the subject and nothing thereafter. Likewise ITS#8436 has sat in Incoming since it was raised in June without comment. My feeling is that the OpenLDAP code base is now too big for the number of active developers, pushing rare issues like this right to the bottom of their queue. I doubt it'll get fixed. Best regards, Mark.' (irrelevant parts removed) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs