openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs