openldap-bugs February 2017

openldap-bugs@openldap.org

22 participants
59 discussions

(ITS#8591) segmentation fault when loading SampleLDAP.pl
by hark＠puscii.nl 15 Feb '17

15 Feb '17

Full_Name: hark Version: commit 9773f43b11aa8fac51407694bbdcd17830f206d5 OS: debian 9.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.169.146.71) openldap is build with: CFLAGS='-g' ./configure --enable-debug --enable-perl --enable-modules --enable-passwd LTCFLAGS='-g' export LTCFLAGS make depend make mkdir /root/openldapdebug/ make install STRIP='' DESTDIR='/root/openldapdebug' started with: gdb --args /root/openldapdebug/usr/local/libexec/slapd -d1 -h "ldap:/// ldapi:///var/run/slapd/ldapi" -F /etc/ldap/slapd.d then when trying to do: ldapadd -x -w $PW -D cn=admin,cn=config -H ldap:"F2F -f /root/src/ldapcrash/slapd-add-perl.ldif cat slapd-add-perl.ldif dn: olcDatabase=perl,cn=config objectClass: olcDatabaseConfig objectClass: olcDbPerlConfig olcDatabase: perl olcSuffix: dc=perl-example,dc=com olcPerlModulePath: /root/src/perlldap/ olcPerlModule: SampleLDAP olcPerlFilterSearchResults: FALSE #olcPerlModuleConfig: something dn: dc=perl-example,dc=com objectClass: top objectClass: dcObject objectClass: organizationalUnit dc: perl-example ou: perl-example-ou it crashes: 58a4ca92 >>> dnNormalize: <olcDatabase={2}perl> 58a4ca92 <<< dnNormalize: <olcDatabase={2}perl> 58a4ca92 >>> dnPrettyNormal: <dc=perl-example,dc=com> 58a4ca92 <<< dnPrettyNormal: <dc=perl-example,dc=com>, <dc=perl-example,dc=com> 58a4ca92 perl backend db init Thread 3 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to LWP 7204] 0x00006a7b721f64f3 in ?? () (gdb) bt #0 0x00006a7b721f64f3 in ?? () #1 0x00006a7b721a23af in ?? () #2 0x000003ad6f16fd18 in ?? () #3 0x000003ad6f16fd48 in ?? () #4 0x000003ad00000018 in ?? () #5 0x00006a7b2d663930 in ?? () #6 0x00006a7b2d6638c0 in ?? () #7 0xb0ac74c0fb38d600 in ?? () #8 0x000003ad6f16fd48 in ?? () #9 0x000003ad6f16fd48 in ?? () #10 0x0000000000000000 in ?? () When trying that multiple times, the backtraces are different: Thread 3 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to LWP 7258] 0x00007cd6f62984f3 in ?? () (gdb) bt #0 0x00007cd6f62984f3 in ?? () #1 0x00007cd6f62443af in ?? () #2 0x00000229299536c8 in ?? () #3 0x00000229299536f8 in ?? () #4 0x0000022900000018 in ?? () #5 0x00007cd6b16e4930 in ?? () #6 0x00007cd6b16e48c0 in ?? () #7 0x5c084850684a2100 in ?? () #8 0x00000229299536f8 in ?? () #9 0x00000229299536fin % ?? () #10 0x0000000000000000 in ?? () [Switching to LWP 7270] 0x00006adbabc534f3 in ?? () (gdb) bt #0 0x00006adbabc534f3 in ?? () #1 0x00006adbabbff3af in ?? () #2 0x00000442aef9d2c8 in ?? () #3 0x00000442aef9d2f8 in ?? () #4 0x0000044200000018 in ?? () #5 0x00006adb670f3930 in ?? () #6 0x00006adb670f38c0 in ?? () #7 0x918aaeeca7964a00 in ?? () #8 0x00000442aef9d2f8 in ?? () #9 0x00000442aef9d2f8 in ?? () #10 0x0000000000000000 in ?? () perl --version This is perl 5, version 24, subversion 1 (v5.24.1) built for x86_64-linux-gnu-thread-multi (with 63 registered patches, see perl -V for more detail)

1 0

(ITS#8590) LMDB: Suppress SIGPIPE in mdb_env_copythr on OS X
by lmb＠cloudflare.com 15 Feb '17

15 Feb '17

Full_Name: Lorenz Bauer Version: mdb.master OS: OS X URL: https://gist.github.com/lmb/a35e7b9566fa79e7bf971ac21bbb9efb Submission from: (NULL) (2a06:98c0:1000:8200:b860:273:d664:7f97) It seems like OS X is not standards compliant wrt SIGPIPE, which breaks mdb_env_copyfd1. On mdb.master, I can see the following behaviour on OS X 10.11: (gdb) r Starting program: /Users/lorenz/dev/openldap/libraries/liblmdb/mtest8 returning Broken pipe[Inferior 1 (process 6180) exited with code 040] (gdb) r Starting program: /Users/lorenz/dev/openldap/libraries/liblmdb/mtest8 returning Broken pipe[Inferior 1 (process 6182) exited with code 040] (gdb) r Starting program: /Users/lorenz/dev/openldap/libraries/liblmdb/mtest8 [New Thread 0x1513 of process 6184] Thread 1 received signal SIGPIPE, Broken pipe. 0x00007fff91eb7db6 in __psynch_cvwait () from /usr/lib/system/libsystem_kernel.dylib (gdb) info th Id Target Id Frame * 1 Thread 0x1323 of process 6184 0x00007fff91eb7db6 in __psynch_cvwait () from /usr/lib/system/libsystem_kernel.dylib 2 Thread 0x1513 of process 6184 0x00007fff91eb83c2 in __sigwait () from /usr/lib/system/libsystem_kernel.dylib mtest8 creates a pipe, closes one end and then calls mdb_env_copyfd2 with CP_COMPACT. Apparently OS X delivers the signal to the entire process. It seems like the sigwait in the current code sometimes races the notification, and therefore prevents SIGPIPE. I found an OS X specific fcntl which fixes this issue. I've attached a patch. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Cloudflare, Inc. Cloudflare, Inc. has not assigned rights and/or interest in this work to any party. I, Lorenz Bauer am authorized by Cloudflare, Inc., my employer, to release this work under the following terms. Cloudflare, Inc. 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.

1 0

(ITS#8589) cn=config replication plus DB replication can break replication
by quanah＠openldap.org 14 Feb '17

14 Feb '17

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) Test059 can expose an interesting bug in OpenLDAP when replication is configured for both cn=config and an underlying data DB. I wouldn't call it a critical issue for this scenario, but it's possible it could be critical in other scenarios I'm not aware of. The basic problem breaks down like this: a) A modification to the schema is made in cn=config b) An entry is added or modified to the data DB that makes use of the new schema changes The majority of the time, this is not an issue, as the change to the schema gets replicated /before/ the change to the entry is honored. However, if the modification to the entry is done *before* the schema changes get replicated, the following happens: a) The replica pauses cn=config replication b) The replica attempts to replicate the changed entry c) The replica fails to replicate the change due to the fact the schema is not yet updated d) The replica goes into an endless REFRESH loop Because cn=config replication is never "unpaused", the REFRESH operation can never succeed. It essentially takes manual intervention to fix the replica.

1 0

Re: (ITS#8588) microsecods in pwdFailureTime and .net Framework
by quanah＠symas.com 14 Feb '17

14 Feb '17

--On Tuesday, February 14, 2017 7:37 PM +0000 iovchelupoff(a)live.com wrote: > Full_Name: Ilya Ovchelupov > Version: 2.4.42 > OS: Windows Server 2008R2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (143.112.32.4) > > > Hi, > We are testing 2.4.42 in our environment and found an issue with > pwdFailureTime attribute. > > It seems to me that it started after the new enhancement in 2.4.40 > (Fixed slapo-ppolicy timestamp resolution to use microseconds (ITS#7161)) > .net DirectorySearcher class doesn't support microseconds in the new > format and we're not able to receive the attribute value. > > I'm thinking about different options how to resolve it. > > Do you know any idea how to resolve it? Hello Ilya, The ITS system is for reporting bugs in OpenLDAP. Help requests are better directed to the openldap-technical(a)openldap.org list. I would note that microsecond timestamps are per the RFC, so I would suggest filing a bug with .NET to support the RFC. 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#8588) microsecods in pwdFailureTime and .net Framework
by iovchelupoff＠live.com 14 Feb '17

14 Feb '17

Full_Name: Ilya Ovchelupov Version: 2.4.42 OS: Windows Server 2008R2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (143.112.32.4) Hi, We are testing 2.4.42 in our environment and found an issue with pwdFailureTime attribute. It seems to me that it started after the new enhancement in 2.4.40 (Fixed slapo-ppolicy timestamp resolution to use microseconds (ITS#7161)) .net DirectorySearcher class doesn't support microseconds in the new format and we're not able to receive the attribute value. I'm thinking about different options how to resolve it. Do you know any idea how to resolve it? Thank you, Ilya

1 0

Re: (ITS#8335) MDB_MULTIPLE issues
by h.b.furuseth＠usit.uio.no 14 Feb '17

14 Feb '17

I wrote: > datacount*datasize (passed to page_spill) can overflow on 32-bit, I > thought that's what you meant. That is, I thought you meant checking data[1].mv_size <= UINT_MAX will stop the multiply from overflowon on 64-bit, but that doesn't help on 32-bit.

1 0

Re: (ITS#8335) MDB_MULTIPLE issues
by h.b.furuseth＠usit.uio.no 14 Feb '17

14 Feb '17

On 14/02/17 03:09, hyc(a)symas.com wrote: > Hallvard Breien Furuseth wrote: >> On 13/02/17 13:16, hyc(a)symas.com wrote: >>> We should probably check if mv_size is greater than UINT_MAX and return >>> EINVAL. (Or ERANGE.) >> >> If you mean check for overflow, that doesn't work on 32-bit hosts. > > It's not possible to pass in a datacount > UINT_MAX on 32bit so there's no > need for such a check. It's only needed on 64bit where uint is smaller than > size_t. I don't get it. You want to add this check for the sake of avoiding to change dcount,mcount from unsigned to double? Why? datacount*datasize (passed to page_spill) can overflow on 32-bit, I thought that's what you meant. But come to think of it, page_spill() itself more than doubles mv_size which can also overflow on 32-bit or with 64-bit MDB_MULTIPLE, it needs some tweaks.

1 0

Re: (ITS#8586) load cert+chain from TLSCertificateFile
by ryan＠nardis.ca 13 Feb '17

13 Feb '17

FWIW, tls_g already has the behaviour that (I think) this ticket asks for: if you set TLSCertificateFile to a file containing concatenated server and intermediate certs, it sends the chain of both. I found that useful in a setup very similar to what Andreas and Michael describe: slapd with a server certificate issued by an external/public CA, but trusting only a specific internal CA to authenticate clients. The comparison to mod_ssl is apt. Note that in recent versions httpd also supports loading the entire chain from SSLCertificateFile.

1 0

Re: (ITS#8335) MDB_MULTIPLE issues
by hyc＠symas.com 13 Feb '17

13 Feb '17

Hallvard Breien Furuseth wrote: > On 13/02/17 13:16, hyc(a)symas.com wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> (...) >>> datacount > UINT_MAX is truncated to unsigned int: >>> data[1].mv_size = 0x100000002 puts 2 items. >> >>> datacount * datasize can exceed UINT_MAX, which mdb_page_spill() >>> truncates to unsigned int. Such a massive put() will likely >>> fail anyway, but it should at least try to spill properly first. >> >> We should probably check if mv_size is greater than UINT_MAX and return >> EINVAL. (Or ERANGE.) > > If you mean check for overflow, that doesn't work on 32-bit hosts. It's not possible to pass in a datacount > UINT_MAX on 32bit so there's no need for such a check. It's only needed on 64bit where uint is smaller than size_t. -- -- 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#8335) MDB_MULTIPLE issues
by h.b.furuseth＠usit.uio.no 13 Feb '17

13 Feb '17

On 13/02/17 13:16, hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> (...) >> datacount > UINT_MAX is truncated to unsigned int: >> data[1].mv_size = 0x100000002 puts 2 items. > >> datacount * datasize can exceed UINT_MAX, which mdb_page_spill() >> truncates to unsigned int. Such a massive put() will likely >> fail anyway, but it should at least try to spill properly first. > > We should probably check if mv_size is greater than UINT_MAX and return > EINVAL. (Or ERANGE.) If you mean check for overflow, that doesn't work on 32-bit hosts. We can do a general overflow check (assuming dcount i size_t here) xdata.mv_size = data[0].mv_size * dcount; if (xdata.mv_size / dcount != data[0].mv_size) return <error>; or if you want a compile-time max safe dcount on 32-bit, that's EVEN((size_t)-1 / (MAX_PAGESIZE/MDB_MINKEYS)) So - MDB_BAD_VALSIZE or a new MDB_* code: Not EINVAL, that should be reserved for obvious error conditions. And not ERANGE, we should not add new errno.h codes.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2017