(ITS#8591) segmentation fault when loading SampleLDAP.pl
by hark＠puscii.nl
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)
5 years, 5 months
(ITS#8590) LMDB: Suppress SIGPIPE in mdb_env_copythr on OS X
by lmb＠cloudflare.com
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.
5 years, 5 months
(ITS#8589) cn=config replication plus DB replication can break replication
by quanah＠openldap.org
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.
5 years, 5 months
Re: (ITS#8588) microsecods in pwdFailureTime and .net Framework
by quanah＠symas.com
--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>
5 years, 5 months
(ITS#8588) microsecods in pwdFailureTime and .net Framework
by iovchelupoff＠live.com
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
5 years, 5 months
Re: (ITS#8335) MDB_MULTIPLE issues
by h.b.furuseth＠usit.uio.no
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.
5 years, 5 months
Re: (ITS#8335) MDB_MULTIPLE issues
by h.b.furuseth＠usit.uio.no
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.
5 years, 5 months
Re: (ITS#8586) load cert+chain from TLSCertificateFile
by ryan＠nardis.ca
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.
5 years, 5 months
Re: (ITS#8335) MDB_MULTIPLE issues
by hyc＠symas.com
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/
5 years, 5 months
Re: (ITS#8335) MDB_MULTIPLE issues
by h.b.furuseth＠usit.uio.no
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.
5 years, 5 months
