- openldap-bugs - openldap.org

Re: (ITS#8303) An Asynchronous meta back-end for OpenLDAP
by nivanova＠symas.com 03 May '16

03 May '16

This is a patch that removes some unused attributes from olcAsyncMetaConfig. These attributes were removed when some configuration options were removed for asyncmeta, being no longer applicable, but removing them from the class definition was missed. ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160503.patch

1 0

(ITS#8417) mdb_load could use an option to specify the mapsize.
by eriixblaike+git＠gmail.com 03 May '16

03 May '16

Full_Name: Eric R. Monson Version: git 3fe9678baa1be8067e7e0bbb94007a096952e62c OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.193.242.31) The lack of a mapsize option available in mdb_load can make it inconvenient to load datasets. This is particularly true when you are using the plaintext format specified by '-T', since it has no header you could add an appropriate mapsize to. My patch resolves this by adding a mapsize option ('-m') which can be used to manually specify a mapsize of your choosing, overriding both the default and any value specified in the header of the database you're loading. The patch also modifies the man page for mdb_load to reflect the new functionality. I don't know if the code is good enough for inclusion, but I figured providing my solution was better than nothing. I, Eric Monson, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. https://eriix.org/download_file/eric-monson-16-05-03.patch

1 0

(ITS#8416) Cross compiling failed
by vystrcil.martin＠gmail.com 03 May '16

03 May '16

Full_Name: Martin Vystrcil Version: 2.4.4 OS: Linux Mint URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.32.219.136) While cross compiling it is not able to strip final binaries. My config command: ./configure --host=arm-linux-gnueabihf CC=/home/martin/Development/SMON3/testing/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf-gcc STRIP=/home/martin/Development/SMON3/testing/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf-strip --with-yielding_select=yes --prefix=/home/martin/Development/SMON3/testing/ldap What it prints (fail with) make[2]: Entering director%6`/home/martin/Development/SMON3/testing/openldap-2.4.44/clients/tools' ../../build/shtool mkdir -p /home/martin/Development/SMON3/testing/ldap/bin ../../build/shtool install -c -m 755 -s ldapsearch /home/martin/Development/SMON3/testing/ldap/bin/ldapsearch strip: Unable to recognise the format of the input file `/home/martin/Development/SMON3/testing/ldap/bin/#INST@30215#' Why this happen ? In file build/shtool is following construction. if [ ".$opt_s" = .yes ]; then if [ ".$opt_t" = .yes ]; then echo "strip $dsttmp" 1>&2 fi strip $dsttmp || shtool_exit $? fi In my opinion there should be strip based on config. In config there it is set correctly. Please lememe know, h t to fix this correctly, I'm not such an expert for automake.

1 0

Re: (ITS#8415) Documentation has hard coded date
by quanah＠zimbra.com 02 May '16

02 May '16

--On Monday, May 02, 2016 8:57 PM +0200 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no> wrote: > openldap-etc.git:misc/crupdate.sh needs a fix so it also > recognizes these two dates, and/or the .sdf copyright notices > can be modified so crupdate catches them. Right, that's the goal here. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8415) Documentation has hard coded date
by h.b.furuseth＠usit.uio.no 02 May '16

02 May '16

On 02/05/16 16:37, quanah(a)openldap.org wrote: > The admin guide has a hard coded year in plain.sdf and preamble.sdf. > > We need to look at using an include file or similar that can have its dates > updated when we do copyright updates. "Doing copyright updates" _is_ updating hard-coded years in the source. I'm pretty sure they ought to stay hard-coded. openldap-etc.git:misc/crupdate.sh needs a fix so it also recognizes these two dates, and/or the .sdf copyright notices can be modified so crupdate catches them.

1 0

(ITS#8415) Documentation has hard coded date
by quanah＠openldap.org 02 May '16

02 May '16

Full_Name: Quanah Gibson-Mount Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) The admin guide has a hard coded year in plain.sdf and preamble.sdf. We need to look at using an include file or similar that can have its dates updated when we do copyright updates.

1 0

(ITS#8414) test008 is non portable due to use of "time" command
by quanah＠openldap.org 30 Apr '16

30 Apr '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) test008 uses the "time" command as part of the test script. However, that is not portable as the default /bin/sh shell on Debian and Ubuntu does not have "time" as a built-in. "time" is only present there for debugging, and is not required for the test itself. Time to remove time.

1 0

Re: (ITS#8404) Fix for an assertion failure when olcDbRewrite is modified on a meta or asyncmeta database
by hyc＠symas.com 28 Apr '16

28 Apr '16

nivanova(a)symas.com wrote: > Full_Name: Nadezhda Ivanova > Version: 2.5 > OS: Ubuntu 14.04 > URL: ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160414.patch > Submission from: (NULL) (78.83.54.234) > > > The problem was reproduced when attempting to modify the dynamic configuration > of meta and asyncmeta rewrite engine. On a meta database that has rewrite > enabled and some rewrite rules configured, execute ldapmodify with the following > LDIF: > dn: olcMetaSub={0}uri,olcDatabase={1}meta,cn=config > replace: olcDbRewrite > olcDbRewrite: rewriteEngine "off" Hm, multiple problems with this patch: > diff --git a/servers/slapd/back-asyncmeta/config.c b/servers/slapd/back-asyncmeta/config.c > index 1801a55..a4fbb91 100644 > --- a/servers/slapd/back-asyncmeta/config.c > +++ b/servers/slapd/back-asyncmeta/config.c > @@ -1797,14 +1797,66 @@ asyncmeta_back_cf_gen( ConfigArgs *c ) > > case LDAP_BACK_CFG_SUFFIXM: /* unused */ > case LDAP_BACK_CFG_REWRITE: > - if ( mt->mt_rwmap.rwm_bva_rewrite ) { > - ber_bvarray_free( mt->mt_rwmap.rwm_bva_rewrite ); > - mt->mt_rwmap.rwm_bva_rewrite = NULL; > - } > - if ( mt->mt_rwmap.rwm_rw ) > + { > + char *argv0; > + if ( c->valx >= 0 ) { > + int i; > + > + for ( i = 0; !BER_BVISNULL( &mt->mt_rwmap.rwm_bva_rewrite[ i ] ); i++ ) Need a semicolon for the empty for-loop. Or, if it's intended that the following if-block is part of the loop, it needs to be properly enclosed in braces and indented. > + > + if ( c->valx >= i ) { > + rc = 1; > + break; > + } > + ber_memfree( mt->mt_rwmap.rwm_bva_rewrite[ c->valx ].bv_val ); > + for ( i = c->valx; !BER_BVISNULL( &mt->mt_rwmap.rwm_bva_rewrite[ i + 1 ] ); i++ ) > + { > + mt->mt_rwmap.rwm_bva_rewrite[ i ] = mt->mt_rwmap.rwm_bva_rewrite[ i + 1 ]; > + } > + BER_BVZERO( &mt->mt_rwmap.rwm_bva_rewrite[ i ] ); > + > rewrite_info_delete( &mt->mt_rwmap.rwm_rw ); > - break; > + assert( mt->mt_rwmap.rwm_rw == NULL ); > + > + rc = asyncmeta_rwi_init( &mt->mt_rwmap.rwm_rw ); > + > + for ( i = 0; !BER_BVISNULL( &mt->mt_rwmap.rwm_bva_rewrite[ i ] ); i++ ) > + { > + ConfigArgs ca = { 0 }; > + > + ca.line = mt->mt_rwmap.rwm_bva_rewrite[ i ].bv_val; > + ca.argc = 0; Unnecessary initialization, you already set all of ca = {0}. > + init_config_argv( &ca ); > + config_parse_ldif( &ca ); > + > + argv0 = ca.argv[ 0 ]; What is argv0 being saved for? > + if ( !strcasecmp( ca.argv[0], "suffixmassage" )) { > + rc = asyncmeta_suffixm_config( &ca, ca.argc, ca.argv, mt ); > + } else { > + rc = rewrite_parse( mt->mt_rwmap.rwm_rw, > + c->fname, c->lineno, ca.argc, ca.argv ); > + } > + > + ca.argv[ 0 ] = argv0; Why is argv0 being restored? All you're doing after this is freeing ca.argv anyway. > + > + ch_free( ca.tline ); > + ch_free( ca.argv ); > > + assert( rc == 0 ); > + } > + > + } else if ( mt->mt_rwmap.rwm_rw != NULL ) { > + if ( mt->mt_rwmap.rwm_bva_rewrite ) { > + ber_bvarray_free( mt->mt_rwmap.rwm_bva_rewrite ); > + mt->mt_rwmap.rwm_bva_rewrite = NULL; > + } > + if ( mt->mt_rwmap.rwm_rw ) > + rewrite_info_delete( &mt->mt_rwmap.rwm_rw ); > + > + asyncmeta_rwi_init( &mt->mt_rwmap.rwm_rw ); > + } > + } > + break; > case LDAP_BACK_CFG_MAP: > if ( mt->mt_rwmap.rwm_bva_map ) { > ber_bvarray_free( mt->mt_rwmap.rwm_bva_map ); -- -- 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#8413) Assertion in back-mdb/search.c during replication
by quanah＠openldap.org 27 Apr '16

27 Apr '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) During replication from the accesslog DB, in a 4-way MMR setup, various masters periodically crash with slapd: search.c:1246: oc_filter: Assertion `f != ((void *)0)' failed. This is back-mdb/search.c, not slapd-search.c This is triggered when a NULL filter is passed through. However, it should be impossible for the filter generated by str2filter to ever fail.

1 0

ITS#8410 published: SECURITY: LDAP connection issue with
by openldap-its＠OpenLDAP.org 26 Apr '16

26 Apr '16

Private ITS#8410 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=8410

1 0

ITS#8405 published: SECURITY: LDAP connection issue
by openldap-its＠OpenLDAP.org 26 Apr '16

26 Apr '16

Private ITS#8405 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=8405

1 0

Re: (ITS#8412) mdb_cursor_del followed by MDB_NEXT_DUP leads to unexpected behaviour
by hyc＠symas.com 26 Apr '16

26 Apr '16

lukaswhl(a)gmail.com wrote: > Full_Name: Lukas W > Version: mdb.master 37081325f7356587c5e6ce4c1f36c3b303fa718c > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2407:7000:9a07:8600::2) > > > The current behaviour of MDB_NEXT_DUP after a mdb_cursor_del call is > inconsistent with those of other OPs. For instance, MDB_NEXT does not change the > cursor's position, as this was already done by mdb_cursor_del. As far as I > understand, mdb_cursor_get can be expected to behave just like usual, whether > mdb_cursor_get was preceded by a mdb_cursor_del call or not. This saves extra > checks when e.g. removing particular items in a loop based on some criterion (as > described and discussed in > http://www.openldap.org/lists/openldap-devel/201502/msg00027.html and > follow-ups). > > However, this does not apply to MDB_NEXT_DUP. Consider a DB containing the > following three items: > > #1: "a" --> 1 > #2: "b" --> 1 > #3: 2b2b" --> 2 > > Let's say we have a cursor that points to #1. After calling mdb_cursor_del, #1 > is removed and the cursor points to #2 (though this is not documented anywhere). > We then call mdb_cursor_get with MDB_NEXT_DUP. We'd expect this call to return > MDB_NOTFOUND, as #1 was the last item with "a" as its key. This is also what it > would return if mdb_cursor_del was not called. But in fact, MDB_SUCCESS is > returned, making anyone who's unaware of this behaviour believe that there's > another item with the key "a". In my particular case, this leads to #2 being > deleted as well, even though I only expected to touch items with the key "a", > which is why I'm using MDB_NEXT_DUP instead of MDB_NEXT in the first place. > In a nutshell, MDB_NEXT_DUP does the same as MDB_NEXT after a mdb_cursor_del > call, even though one would expect it not to jump across "key boundaries". > > On a side note, prior to 37081325f7356587c5e6ce4c1f36c3b303fa718c / ITS#8406 > this would have resulted in an assertion failure. > > You could classify this as a bug and adjust the behaviour to match MDB_NEXT's, > or you could document the behaviour of mdb_cursor_del regarding the cursor's > state. Either would be appreciated. Fixed in mdb.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#8412) mdb_cursor_del followed by MDB_NEXT_DUP leads to unexpected behaviour
by lukaswhl＠gmail.com 26 Apr '16

26 Apr '16

Full_Name: Lukas W Version: mdb.master 37081325f7356587c5e6ce4c1f36c3b303fa718c OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2407:7000:9a07:8600::2) The current behaviour of MDB_NEXT_DUP after a mdb_cursor_del call is inconsistent with those of other OPs. For instance, MDB_NEXT does not change the cursor's position, as this was already done by mdb_cursor_del. As far as I understand, mdb_cursor_get can be expected to behave just like usual, whether mdb_cursor_get was preceded by a mdb_cursor_del call or not. This saves extra checks when e.g. removing particular items in a loop based on some criterion (as described and discussed in http://www.openldap.org/lists/openldap-devel/201502/msg00027.html and follow-ups). However, this does not apply to MDB_NEXT_DUP. Consider a DB containing the following three items: #1: "a" --> 1 #2: "b" --> 1 #3: 2b2b" --> 2 Let's say we have a cursor that points to #1. After calling mdb_cursor_del, #1 is removed and the cursor points to #2 (though this is not documented anywhere). We then call mdb_cursor_get with MDB_NEXT_DUP. We'd expect this call to return MDB_NOTFOUND, as #1 was the last item with "a" as its key. This is also what it would return if mdb_cursor_del was not called. But in fact, MDB_SUCCESS is returned, making anyone who's unaware of this behaviour believe that there's another item with the key "a". In my particular case, this leads to #2 being deleted as well, even though I only expected to touch items with the key "a", which is why I'm using MDB_NEXT_DUP instead of MDB_NEXT in the first place. In a nutshell, MDB_NEXT_DUP does the same as MDB_NEXT after a mdb_cursor_del call, even though one would expect it not to jump across "key boundaries". On a side note, prior to 37081325f7356587c5e6ce4c1f36c3b303fa718c / ITS#8406 this would have resulted in an assertion failure. You could classify this as a bug and adjust the behaviour to match MDB_NEXT's, or you could document the behaviour of mdb_cursor_del regarding the cursor's state. Either would be appreciated.

1 0

Re: (ITS#8411) segfault on slapd 2.4.44
by mwtzzz＠gmail.com 24 Apr '16

24 Apr '16

Thank you. Yes. I recompiled sha2 module for 2.4.44, and it works. On Sun, Apr 24, 2016 at 8:00 AM, Howard Chu <hyc(a)symas.com> wrote: > This is ITS#8294, which was fixed in 2.4.43. You have an out-of-date sha2 > password module in your installation. Closing this ITS. > > > Michael Martinez wrote: >> >> OS: Linux rpi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l >> GNU/Linux >> >> (gdb) info shared >>> >>> From To Syms Read Shared Object Library >> >> 0xb6f344b8 0xb6f35a10 Yes (*) >> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so >> 0xb6f16c04 0xb6f1b0bc Yes (*) >> /usr/lib/arm-linux-gnueabihf/libltdl.so.7 >> 0xb6f0a928 0xb6f0b640 Yes (*) /lib/arm-linux-gnueabihf/libdl.so.2 >> 0xb6de0dd0 0xb6ee4b74 Yes (*) >> /usr/lib/arm-linux-gnueabihf/libdb-5.1.so >> 0xb6da6558 0xb6db7504 Yes (*) >> /usr/lib/arm-linux-gnueabihf/libsasl2.so.2 >> 0xb6d5f610 0xb6d90bac Yes (*) >> /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0 >> 0xb6c35e80 0xb6d071c0 Yes (*) >> /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 >> 0xb6bb8718 0xb6bbd1e8 Yes (*) /lib/arm-linux-gnueabihf/libcrypt.so.1 >> 0xb6ba6444 0xb6bb273c Yes (*) >> /lib/arm-linux-gnueabihf/libresolv.so.2 >> 0xb6b88eb0 0xb6b9691c Yes (*) >> /lib/arm-linux-gnueabihf/libpthread.so.0 >> 0xb6a6a4a0 0xb6b583b0 Yes (*) /lib/arm-linux-gnueabihf/libc.so.6 >> 0xb6f3e7c0 0xb6f57408 Yes (*) /lib/ld-linux-armhf.so.3 >> 0xb6a38b38 0xb6a46f7c Yes (*) /lib/arm-linux-gnueabihf/libz.so.1 >> 0xb6a1e450 0xb6a2e24c Yes (*) /lib/arm-linux-gnueabihf/libgcc_s.so.1 >> 0xb6f25268 0xb6f298e0 Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/libntlm.so >> 0xb69ced8c 0xb69d0ae0 Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/libplain.so >> 0xb69c107c 0xb69c3bbc Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/libsasldb.so >> 0xb69ad400 0xb69b59e4 Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/libdigestmd5.so >> 0xb699fe04 0xb69a2004 Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/libcrammd5.so >> 0xb6993d5c 0xb69957f0 Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/libanonymous.so >> 0xb6987d50 0xb6989974 Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/liblogin.so >> 0xb6979e60 0xb697d8c0 Yes /usr/lib/ldap/slapd-sha2.so >> (*): Shared library is missing debugging information. >> >> (gdb) bt >> #0 0xb6f350a0 in memcpy () from >> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so >> #1 0xb6c3f344 in SHA256_Update () >> from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 >> #2 0xb697a69c in chk_ssha256 (scheme=0x19e27d4, passwd=0xa11caa20, >> cred=0x1a53468, >> text=0xa11cab98) at slapd-sha2.c:256 >> #3 0x00121f58 in lutil_passwd () >> #4 0x0006ec98 in slap_passwd_check () >> #5 0x000e4db8 in bdb_bind () >> #6 0x0005bbdc in fe_op_bind () >> #7 0x0005b568 in do_bind () >> #8 0x000403b8 in ?? () >> Cannot access memory at address 0x0 >> #9 0x000403b8 in ?? () >> Cannot access memory at address 0x0 >> Backtrace stopped: previous frame identical to this frame (corrupt stack?) >> >> On Sat, Apr 23, 2016 at 6:51 PM, Howard Chu <hyc(a)symas.com> wrote: >>> >>> mwtzzz(a)gmail.com wrote: >>>> >>>> >>>> Full_Name: Michael Martinez >>>> Version: 2.4.44 >>>> OS: ubuntu wheezy >>> >>> >>> >>> There is no such OS. >>> >>>> URL: >>>> Submission from: (NULL) (99.113.34.53) >>>> >>>> >>>> After upgrading from openldap-2.4.31 to 2.4.44 I'm getting segfaults >>>> anytime I >>>> run 'passwd', attempt to ssh into the box, etc. >>>> >>>> this is on raspberry pi (debian wheezy). >>>> >>>> Previously running the latest package 2.4.31. Then installed >>>> openldap-2.4.44 >>>> from source, did slapcat from the old version and slapadd to import it >>>> to >>>> the >>>> new version. Loads fine and can run simple commands like "id" for ldap >>>> users. >>>> But get core dump with password changes, ssh from other boxes, etc. >>>> A%A[Thread debugging using libthread_db enabled] >>>> Using host libthread_db library >>>> "/lib/arm-linux-gnueabihf/libthread_db.so.1". >>>> Core was generated by `/usr/local/openldap/libexec/slapd -f >>>> /etc/ldap/slapd.conf >>>> -F /ec/ldap/slapd.d'. >>>> Program terminated with signal 11, Segmentation fault. >>>> #0 0xb6f350a0 in memcpy () from >>>> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so >>>> (gdb) >>> >>> >>> >>> Please provide the full stack trace. >>> >>> Also output from "info shared". >>> >>> -- >>> -- Howard Chu >>> CTO, Symas Corp. http://www.symas.com >>> Director, Highland Sun http://highlandsun.com/hyc/ >>> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> >> >> >> > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- --- Michael Martinez http://www.michael--martinez.com

1 0

Re: (ITS#8411) segfault on slapd 2.4.44
by hyc＠symas.com 24 Apr '16

24 Apr '16

This is ITS#8294, which was fixed in 2.4.43. You have an out-of-date sha2 password module in your installation. Closing this ITS. Michael Martinez wrote: > OS: Linux rpi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux > > (gdb) info shared >>From To Syms Read Shared Object Library > 0xb6f344b8 0xb6f35a10 Yes (*) /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so > 0xb6f16c04 0xb6f1b0bc Yes (*) /usr/lib/arm-linux-gnueabihf/libltdl.so.7 > 0xb6f0a928 0xb6f0b640 Yes (*) /lib/arm-linux-gnueabihf/libdl.so.2 > 0xb6de0dd0 0xb6ee4b74 Yes (*) /usr/lib/arm-linux-gnueabihf/libdb-5.1.so > 0xb6da6558 0xb6db7504 Yes (*) /usr/lib/arm-linux-gnueabihf/libsasl2.so.2 > 0xb6d5f610 0xb6d90bac Yes (*) /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0 > 0xb6c35e80 0xb6d071c0 Yes (*) > /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 > 0xb6bb8718 0xb6bbd1e8 Yes (*) /lib/arm-linux-gnueabihf/libcrypt.so.1 > 0xb6ba6444 0xb6bb273c Yes (*) /lib/arm-linux-gnueabihf/libresolv.so.2 > 0xb6b88eb0 0xb6b9691c Yes (*) /lib/arm-linux-gnueabihf/libpthread.so.0 > 0xb6a6a4a0 0xb6b583b0 Yes (*) /lib/arm-linux-gnueabihf/libc.so.6 > 0xb6f3e7c0 0xb6f57408 Yes (*) /lib/ld-linux-armhf.so.3 > 0xb6a38b38 0xb6a46f7c Yes (*) /lib/arm-linux-gnueabihf/libz.so.1 > 0xb6a1e450 0xb6a2e24c Yes (*) /lib/arm-linux-gnueabihf/libgcc_s.so.1 > 0xb6f25268 0xb6f298e0 Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/libntlm.so > 0xb69ced8c 0xb69d0ae0 Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/libplain.so > 0xb69c107c 0xb69c3bbc Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/libsasldb.so > 0xb69ad400 0xb69b59e4 Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/libdigestmd5.so > 0xb699fe04 0xb69a2004 Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/libcrammd5.so > 0xb6993d5c 0xb69957f0 Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/libanonymous.so > 0xb6987d50 0xb6989974 Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/liblogin.so > 0xb6979e60 0xb697d8c0 Yes /usr/lib/ldap/slapd-sha2.so > (*): Shared library is missing debugging information. > > (gdb) bt > #0 0xb6f350a0 in memcpy () from /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so > #1 0xb6c3f344 in SHA256_Update () > from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 > #2 0xb697a69c in chk_ssha256 (scheme=0x19e27d4, passwd=0xa11caa20, > cred=0x1a53468, > text=0xa11cab98) at slapd-sha2.c:256 > #3 0x00121f58 in lutil_passwd () > #4 0x0006ec98 in slap_passwd_check () > #5 0x000e4db8 in bdb_bind () > #6 0x0005bbdc in fe_op_bind () > #7 0x0005b568 in do_bind () > #8 0x000403b8 in ?? () > Cannot access memory at address 0x0 > #9 0x000403b8 in ?? () > Cannot access memory at address 0x0 > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > On Sat, Apr 23, 2016 at 6:51 PM, Howard Chu <hyc(a)symas.com> wrote: >> mwtzzz(a)gmail.com wrote: >>> >>> Full_Name: Michael Martinez >>> Version: 2.4.44 >>> OS: ubuntu wheezy >> >> >> There is no such OS. >> >>> URL: >>> Submission from: (NULL) (99.113.34.53) >>> >>> >>> After upgrading from openldap-2.4.31 to 2.4.44 I'm getting segfaults >>> anytime I >>> run 'passwd', attempt to ssh into the box, etc. >>> >>> this is on raspberry pi (debian wheezy). >>> >>> Previously running the latest package 2.4.31. Then installed >>> openldap-2.4.44 >>> from source, did slapcat from the old version and slapadd to import it to >>> the >>> new version. Loads fine and can run simple commands like "id" for ldap >>> users. >>> But get core dump with password changes, ssh from other boxes, etc. >>> A%A[Thread debugging using libthread_db enabled] >>> Using host libthread_db library >>> "/lib/arm-linux-gnueabihf/libthread_db.so.1". >>> Core was generated by `/usr/local/openldap/libexec/slapd -f >>> /etc/ldap/slapd.conf >>> -F /ec/ldap/slapd.d'. >>> Program terminated with signal 11, Segmentation fault. >>> #0 0xb6f350a0 in memcpy () from >>> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so >>> (gdb) >> >> >> Please provide the full stack trace. >> >> Also output from "info shared". >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > -- -- 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#8411) segfault on slapd 2.4.44
by mwtzzz＠gmail.com 24 Apr '16

24 Apr '16

OS: Linux rpi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux (gdb) info shared >From To Syms Read Shared Object Library 0xb6f344b8 0xb6f35a10 Yes (*) /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so 0xb6f16c04 0xb6f1b0bc Yes (*) /usr/lib/arm-linux-gnueabihf/libltdl.so.7 0xb6f0a928 0xb6f0b640 Yes (*) /lib/arm-linux-gnueabihf/libdl.so.2 0xb6de0dd0 0xb6ee4b74 Yes (*) /usr/lib/arm-linux-gnueabihf/libdb-5.1.so 0xb6da6558 0xb6db7504 Yes (*) /usr/lib/arm-linux-gnueabihf/libsasl2.so.2 0xb6d5f610 0xb6d90bac Yes (*) /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0 0xb6c35e80 0xb6d071c0 Yes (*) /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 0xb6bb8718 0xb6bbd1e8 Yes (*) /lib/arm-linux-gnueabihf/libcrypt.so.1 0xb6ba6444 0xb6bb273c Yes (*) /lib/arm-linux-gnueabihf/libresolv.so.2 0xb6b88eb0 0xb6b9691c Yes (*) /lib/arm-linux-gnueabihf/libpthread.so.0 0xb6a6a4a0 0xb6b583b0 Yes (*) /lib/arm-linux-gnueabihf/libc.so.6 0xb6f3e7c0 0xb6f57408 Yes (*) /lib/ld-linux-armhf.so.3 0xb6a38b38 0xb6a46f7c Yes (*) /lib/arm-linux-gnueabihf/libz.so.1 0xb6a1e450 0xb6a2e24c Yes (*) /lib/arm-linux-gnueabihf/libgcc_s.so.1 0xb6f25268 0xb6f298e0 Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/libntlm.so 0xb69ced8c 0xb69d0ae0 Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/libplain.so 0xb69c107c 0xb69c3bbc Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/libsasldb.so 0xb69ad400 0xb69b59e4 Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/libdigestmd5.so 0xb699fe04 0xb69a2004 Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/libcrammd5.so 0xb6993d5c 0xb69957f0 Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/libanonymous.so 0xb6987d50 0xb6989974 Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/liblogin.so 0xb6979e60 0xb697d8c0 Yes /usr/lib/ldap/slapd-sha2.so (*): Shared library is missing debugging information. (gdb) bt #0 0xb6f350a0 in memcpy () from /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so #1 0xb6c3f344 in SHA256_Update () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 #2 0xb697a69c in chk_ssha256 (scheme=0x19e27d4, passwd=0xa11caa20, cred=0x1a53468, text=0xa11cab98) at slapd-sha2.c:256 #3 0x00121f58 in lutil_passwd () #4 0x0006ec98 in slap_passwd_check () #5 0x000e4db8 in bdb_bind () #6 0x0005bbdc in fe_op_bind () #7 0x0005b568 in do_bind () #8 0x000403b8 in ?? () Cannot access memory at address 0x0 #9 0x000403b8 in ?? () Cannot access memory at address 0x0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) On Sat, Apr 23, 2016 at 6:51 PM, Howard Chu <hyc(a)symas.com> wrote: > mwtzzz(a)gmail.com wrote: >> >> Full_Name: Michael Martinez >> Version: 2.4.44 >> OS: ubuntu wheezy > > > There is no such OS. > >> URL: >> Submission from: (NULL) (99.113.34.53) >> >> >> After upgrading from openldap-2.4.31 to 2.4.44 I'm getting segfaults >> anytime I >> run 'passwd', attempt to ssh into the box, etc. >> >> this is on raspberry pi (debian wheezy). >> >> Previously running the latest package 2.4.31. Then installed >> openldap-2.4.44 >> from source, did slapcat from the old version and slapadd to import it to >> the >> new version. Loads fine and can run simple commands like "id" for ldap >> users. >> But get core dump with password changes, ssh from other boxes, etc. >> A%A[Thread debugging using libthread_db enabled] >> Using host libthread_db library >> "/lib/arm-linux-gnueabihf/libthread_db.so.1". >> Core was generated by `/usr/local/openldap/libexec/slapd -f >> /etc/ldap/slapd.conf >> -F /ec/ldap/slapd.d'. >> Program terminated with signal 11, Segmentation fault. >> #0 0xb6f350a0 in memcpy () from >> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so >> (gdb) > > > Please provide the full stack trace. > > Also output from "info shared". > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- --- Michael Martinez http://www.michael--martinez.com

1 0

Re: (ITS#8411) segfault on slapd 2.4.44
by hyc＠symas.com 24 Apr '16

24 Apr '16

mwtzzz(a)gmail.com wrote: > Full_Name: Michael Martinez > Version: 2.4.44 > OS: ubuntu wheezy There is no such OS. > URL: > Submission from: (NULL) (99.113.34.53) > > > After upgrading from openldap-2.4.31 to 2.4.44 I'm getting segfaults anytime I > run 'passwd', attempt to ssh into the box, etc. > > this is on raspberry pi (debian wheezy). > > Previously running the latest package 2.4.31. Then installed openldap-2.4.44 > from source, did slapcat from the old version and slapadd to import it to the > new version. Loads fine and can run simple commands like "id" for ldap users. > But get core dump with password changes, ssh from other boxes, etc. > A%A[Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". > Core was generated by `/usr/local/openldap/libexec/slapd -f /etc/ldap/slapd.conf > -F /ec/ldap/slapd.d'. > Program terminated with signal 11, Segmentation fault. > #0 0xb6f350a0 in memcpy () from /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so > (gdb) Please provide the full stack trace. Also output from "info shared". -- -- 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#8411) segfault on slapd 2.4.44
by mwtzzz＠gmail.com 24 Apr '16

24 Apr '16

Full_Name: Michael Martinez Version: 2.4.44 OS: ubuntu wheezy URL: Submission from: (NULL) (99.113.34.53) After upgrading from openldap-2.4.31 to 2.4.44 I'm getting segfaults anytime I run 'passwd', attempt to ssh into the box, etc. this is on raspberry pi (debian wheezy). Previously running the latest package 2.4.31. Then installed openldap-2.4.44 from source, did slapcat from the old version and slapadd to import it to the new version. Loads fine and can run simple commands like "id" for ldap users. But get core dump with password changes, ssh from other boxes, etc. A%A[Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". Core was generated by `/usr/local/openldap/libexec/slapd -f /etc/ldap/slapd.conf -F /ec/ldap/slapd.d'. Program terminated with signal 11, Segmentation fault. #0 0xb6f350a0 in memcpy () from /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (gdb)

1 0

Re: (ITS#8409) OpenLDAP Fortress Page Outdated
by smckinney＠symas.com 21 Apr '16

21 Apr '16

> On Apr 21, 2016, at 2:15 AM, Michael Str=C3=B6der = <michael(a)stroeder.com> wrote: >=20 > I'd recommend a redirect to let search engines pick up the new = canonical project > URL. That will work. How do I proceed to make the change? Or, who should be = notified with this request? Here=E2=80=99s the current project page:=20 https://directory.apache.org/fortress/=

1 0

Re: (ITS#8409) OpenLDAP Fortress Page Outdated
by michael＠stroeder.com 21 Apr '16

21 Apr '16

I'd recommend a redirect to let search engines pick up the new canonical project URL.

1 0

(ITS#8409) OpenLDAP Fortress Page Outdated
by smckinney＠symas.com 21 Apr '16

21 Apr '16

Full_Name: Shawn McKinney Version: n/a OS: n/a URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.205.236.100) The page referenced by this link: http://www.openldap.org/fortress/ Is out of date, has broken links, and otherwise should either be taken down or changed. Since fortress started out in this project, it seems appropriate to leave the page up but add a few comments about the move, and reference its new project page: https://directory.apache.org/fortress/ Thanks, Shawn

1 0

(ITS#8408) LMDB build warnings on Darwin/Clang for (s)printf
by joj＠mac.com 20 Apr '16

20 Apr '16

Full_Name: Joakim Hassila Version: OS: Mac OS X 10.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (90.141.153.214) Minor code style issue with latest https://github.com/LMDB/lmdb. There are three (harmless) warnings that clang caught. Essentially it is the same pattern for all three, usage of ternary operator yielding format strings with different number of arguments, whereby the last one is ignored for one of the format variants. To reproduce, just do "make" on a Mac with Xcode 7.3 installed (thus using clang as the compiler). +++++++++++++++ solid:liblmdb jocke$ make gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb.c mdb.c:10706:46: warning: data argument not used by format string [-Wformat-extra-args] (int)mr[i].mr_pid, (size_t)mr[i].mr_tid, txnid); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ /usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf' __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__) ^~~~~~~~~~~ 1 warning generated. gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c midl.c ar rs liblmdb.a mdb.o midl.o ar: creating archive liblmdb.a gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -fPIC -c mdb.c -o mdb.lo mdb.c:10706:46: warning: data argument not used by format string [-Wformat-extra-args] (int)mr[i].mr_pid, (size_t)mr[i].mr_tid, txnid); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ /usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf' __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__) ^~~~~~~~~~~ 1 warning generated. gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -fPIC -c midl.c -o midl.lo gcc -pthread -shared -o liblmdb.so mdb.lo midl.lo clang: warning: argument unused during compilation: '-pthre%2' gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb_stat.c mdb_stat.c:206:12: warning: data argument not used by format string [-Wformat-extra-args] pg, span); ^ 1 warning generated. +++++++++++++++

1 0

Re: (ITS#8407) LMDB build warnings on Darwin/Clang for (s)printf
by hyc＠symas.com 20 Apr '16

20 Apr '16

joj(a)mac.com wrote: > Full_Name: Joakim Hassila > Version: > OS: Mac OS X 10.11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (90.141.153.214) > > > Minor code style issue with latest https://github.com/LMDB/lmdb. > There are three (harmless) warnings that clang caught. The code is correct. Closing this ITS. It is not the compiler's job to scold programmers about style. -- -- 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#8407) LMDB build warnings on Darwin/Clang for (s)printf
by joj＠mac.com 20 Apr '16

20 Apr '16

Full_Name: Joakim Hassila Version: OS: Mac OS X 10.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (90.141.153.214) Minor code style issue with latest https://github.com/LMDB/lmdb. There are three (harmless) warnings that clang caught. Essentially it is the same pattern for all three, usage of ternary operator yielding format strings with different number of arguments, whereby the last one is ignored for one of the format variants. To reproduce, just do "make" on a Mac with Xcode 7.3 installed (thus using clang as the compiler). +++++++++++++++ solid:liblmdb jocke$ make gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb.c mdb.c:10706:46: warning: data argument not used by format string [-Wformat-extra-args] (int)mr[i].mr_pid, (size_t)mr[i].mr_tid, txnid); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ /usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf' __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__) ^~~~~~~~~~~ 1 warning generated. gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c midl.c ar rs liblmdb.a mdb.o midl.o ar: creating archive liblmdb.a gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -fPIC -c mdb.c -o mdb.lo mdb.c:10706:46: warning: data argument not used by format string [-Wformat-extra-args] (int)mr[i].mr_pid, (size_t)mr[i].mr_tid, txnid); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ /usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf' __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__) ^~~~~~~~~~~ 1 warning generated. gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -fPIC -c midl.c -o midl.lo gcc -pthread -shared -o liblmdb.so mdb.lo midl.lo clang: warning: argument unused during compilation: '-pthre%2' gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb_stat.c mdb_stat.c:206:12: warning: data argument not used by format string [-Wformat-extra-args] pg, span); ^ 1 warning generated. +++++++++++++++

1 0

Re: (ITS#8406) LMDB: Assertion 'mc->mc_flags & C_INITIALIZED' with MDB_NEXT after mdb_cursor_del
by hyc＠symas.com 18 Apr '16

18 Apr '16

hyc(a)symas.com wrote: > akyrtzi(a)gmail.com wrote: >> Full_Name: Argyrios Kyrtzidis >> Version: LMDB master >> OS: OSX >> URL: >> Submission from: (NULL) (2601:646:8900:3c89:b9af:5cb2:7292:8835) >> >> >> With latest lmdb source (github mirror: >> 8fff90db7ed1e650395f39f9e8b22673aa74aa2b), there is an assertion hit when >> deleting the cursor and then doing mdb_cursor_get(MDB_NEXT) and 'entering' >> DUPSORT items. >> To demonstrate see below diff which modifies mtest3.c. When run you see this: > > For reference, this bug was exposed by ITS#8321 > b5ce8108e8bb92df00b2d27ef0e37bfe756d3752 > > (But that is not the root cause.) > Fixed now in git mdb.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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs