Re: (ITS#9073) md_cmp() called with zero size key
by juerg.bircher＠gmail.com
After having investigated more time on this issue and having changed =
some parts of my code which could cause data corruption everything seems =
to work fine. So most likely this issue can be closed.=
4 years
(ITS#9073) md_cmp() called with zero size key
by juerg.bircher＠gmail.com
Full_Name: Juerg Bircher
Version: LMDB master
OS: macOS / linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (84.75.150.99)
I had the situation that my custom compare function was called with a MDB_val
with zero size.
I assume this should never happen as a key with zero length should not be
valid?
Unfortunately I do not have a simple case to reproduce it as it happens in large
transaction with a lot of mdb_cursor_put() interleaved with mdb_cursor_get()
calls.
However it is reproducible.
In mdb_cursor_set() at line mdb.c:6943 nodekey.mv_size is zero.
rc = mc->mc_dbx->md_cmp(key, &nodekey);
So the custom compare function is called with a value of zero length.
A possible fix could be to surrond the code from line 6943 to 7007 with a check
if (nodekey.mv_size > 0) {
rc = mc->mc_dbx->md_cmp(key, &nodekey);
if (rc == 0) {
line 6943 to 7007
}
I thank you in advance to inform me:
a. if this fix is correct
b. my assumption is wrong
c. it needs another fix somewhere else
4 years
Re: (ITS#9072) openLdap client problem
by quanah＠symas.com
--On Friday, August 30, 2019 7:14 AM +0000 feng.wang(a)iquantex.com wrote:
> Thank you very much for getting support!
> ???? In the production of openldap is the HA environment, other uses are
> normal, only in the modification of the user to multiple groups (some
> client new user information is updated, and some other host clients are
> not updated).
Please update to a current release of OpenLDAP, i.e, at least version
2.4.48 as numerous replication fixes have been made to the product since
that time. You were already told to upgrade in ITS#9053 as well. Please
stop filing ITSes until such a time as you have upgraded to a current
release.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years
(ITS#87) openLdap client problem
by feng.wang＠iquantex.com
Full_Name: wangfeng
Version: 2.4.44
OS: linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (1.180.156.107)
Thank you very much for getting support!
In the production of openldap is the HA environment, other uses are normal,
only in the modification of the user to multiple groups (some client new user
information is updated, and some other host clients are not updated).
4 years
Re: (ITS#9070) Failing to include openssl1.1.1c with openLDAP
by quanah＠symas.com
--On Thursday, August 29, 2019 3:13 PM +0000 vishal.bafna307(a)gmail.com
wrote:
> I am trying to build openLDAP using openssl1.1.1c.
> It is failing to locate the SSL/TLS package.
> I have given the openssl lib and include paths in LDFLAGS and CPPFLAGS
> respectively in the Makefile of LDAP. The Make file also has
> --with-tls=openssl \ mentioned as config option
The ITS system is for bug reports, not help requests on how to build the
software. If you need help with building the software, please use the
openldap-technical(a)openldap.org email list.
<https://www.openldap.org/lists/mm/listinfo/openldap-technical>
This ITS will be closed.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years
(ITS#9071) Invalid olcDbStartTLS values generated on back-ldap conversion
by quanah＠openldap.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.48
OS: N/A
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.128.44)
When converting this basic slapd.conf for back-ldap:
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/openldap.schema
include /usr/local/etc/openldap/schema/ppolicy.schema
include /usr/local/etc/openldap/schema/misc.schema
loglevel 256
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
modulepath /usr/local/libexec/openldap
moduleload rwm
moduleload back_ldap
database ldap
readonly yes
protocol-version 3
rebind-as-user yes
uri "ldaps://universe.example.com"
suffix "dc=universe,dc=example,dc=com"
overlay rwm
rwm-map attribute uid sAMAccountName
rwm-map attribute mail proxyAddresses
chase-referrals yes
idassert-bind bindmethod=simple binddn="cn=ldap_phone,ou=LDAP
Access,dc=example,dc=com" credentials='Password1234'
tls_cacert=/usr/local/etc/openldap/example_com_Universe_Root_CA.cer
The resulting back-ldap configuration has an invalid olcDbStartTLS attribute:
olcDbStartTLS: none starttls=no
Per the man page, "none" is not valid at all, and also per the man page, since
the URI is using ldaps, the value should be:
olcDbStartTLS: ldaps
Config is based off of a real life configuration from an end user, where things
worked with slapd.conf but were broken post-conversion to cn=config. Fixing the
olcDbStartTLS value to be valid resolved the issue.
4 years
(ITS#9070) Failing to include openssl1.1.1c with openLDAP
by vishal.bafna307＠gmail.com
Full_Name: Vishal Bafna
Version: 2.4.42
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (134.204.193.36)
I am trying to build openLDAP using openssl1.1.1c.
It is failing to locate the SSL/TLS package.
I have given the openssl lib and include paths in LDFLAGS and CPPFLAGS
respectively in the Makefile of LDAP. The Make file also has --with-tls=openssl
\ mentioned as config option
snapshot of config option in the ldap Makefile
CONFIG_OPTS=
--host=$(TARGET)
--prefix=${LINUX_ROOT}
--exec_prefix=${LINUX_ROOT}
--disable-static
--enable-shared
--with-yielding_select=no
--disable-slapd
--enable-syslog
--disable-bdb
--disable-hdb
--enable-debug
--with-tls=openssl
--target=$(TARGET)
LDFLAGS="-L${LINUX_ROOT}/lib -L$(LINUX_ROOT)/ssl/lib"
CPPFLAGS="-I${LINUX_ROOT}/include -I$(LINUX_ROOT)/ssl/include" \
checking for SSL_library_init in -lssl... no
checking for ssl3_accept in -lssl... no
configure: error: Could not locate TLS/SSL package
Makefile:27: recipe for target 'configure_arm-none-linux-gnueabi-2.4.42' failed
Could someone please help with the issue
4 years
Re: (ITS#9069) Stop setting custom GnuTLS mutex functions
by hyc＠symas.com
Ryan Tandy wrote:
> On Wed, Aug 28, 2019 at 01:34:31PM +0100, Howard Chu wrote:
>> This is not a safe assumption on Windows, unfortunately. While libldap uses native
>> Windows mutexes on Windows, a lot of code built using gcc/g++ uses a posixthreads
>> emulation library for thread and mutex support, and the user-visible structures are
>> not compatible with native mutexes. (I've found this to be a significant problem
>> for g++ std::mutex, std::thread, etc.)
>
> Thanks for mentioning that. GnuTLS also uses native Windows threads when building for Windows (including mingw-ish environments), so it should still be OK; but
> I'd better go and figure out a smoke test on Windows too.
>
> How does this work on the OpenSSL side? For 1.1.0+ it sounds like the same situation, with OpenSSL using the Windows native API as well.
>
> Does "incompatible" just mean that a single mutex object can't be shared between the two APIs? (I don't think that would be an issue for our case.) Or is it
> something stronger like a pthreads mutex not being able to synchronize native threads, or outright not being able to use both interfaces in a single process?
>
Passing a native structure to the posixthreads interface (and vice versa) will crash the program (or
worse - silently corrupt memory without crashing the program....)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4 years
Re: (ITS#9069) Stop setting custom GnuTLS mutex functions
by ryan＠nardis.ca
On Wed, Aug 28, 2019 at 01:34:31PM +0100, Howard Chu wrote:
>This is not a safe assumption on Windows, unfortunately. While libldap uses native
>Windows mutexes on Windows, a lot of code built using gcc/g++ uses a posixthreads
>emulation library for thread and mutex support, and the user-visible structures are
>not compatible with native mutexes. (I've found this to be a significant problem
>for g++ std::mutex, std::thread, etc.)
Thanks for mentioning that. GnuTLS also uses native Windows threads when
building for Windows (including mingw-ish environments), so it should
still be OK; but I'd better go and figure out a smoke test on Windows
too.
How does this work on the OpenSSL side? For 1.1.0+ it sounds like the
same situation, with OpenSSL using the Windows native API as well.
Does "incompatible" just mean that a single mutex object can't be shared
between the two APIs? (I don't think that would be an issue for our
case.) Or is it something stronger like a pthreads mutex not being able
to synchronize native threads, or outright not being able to use both
interfaces in a single process?
4 years
Re: (ITS#9069) Stop setting custom GnuTLS mutex functions
by hyc＠symas.com
ryan(a)openldap.org wrote:
> Full_Name: Ryan Tandy
> Version: master
> OS: Debian
> URL: https://github.com/rtandy/openldap/compare/openldap:master...rtandy:remov...
> Submission from: (NULL) (70.66.128.207)
> Submitted by: ryan
>
>
> The GnuTLS documentation
> <https://gnutls.org/manual/html_node/Core-TLS-API.html#gnutls_005fglobal_0...>
> states:
>
>> Do not call this function from a library, or preferably from any application
> unless really needed to.
> Additionally, the custom mutex functions are never reset, so if libldap is
> unloaded (for example via dlclose()) after calling this, its code may be
> unmapped and the application could crash when GnuTLS calls the mutex functions.
>
> On typical systems, GnuTLS system mutexes are probably the same as what libldap
> uses anyway.
This is not a safe assumption on Windows, unfortunately. While libldap uses native
Windows mutexes on Windows, a lot of code built using gcc/g++ uses a posixthreads
emulation library for thread and mutex support, and the user-visible structures are
not compatible with native mutexes. (I've found this to be a significant problem
for g++ std::mutex, std::thread, etc.)
>
> IPR:
>
> The attached patch file is derived from OpenLDAP Software. All of the
> modifications to OpenLDAP Software represented in the following patch were
> developed by Ryan Tandy <ryan(a)nardis.ca>. I have not assigned rights and/or
> interest in this work to any party.
>
> I, Ryan Tandy, 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.
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4 years
