openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Start a nNew thread

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 25 Apr '16

25 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 23 Apr '16

23 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 23 Apr '16

23 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

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