openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#8718) Connection delete callback registreed with LDAP_OPT_CONNECT_CB is not called on TLS failure
by ipuleston＠sonicwall.com 25 Aug '17

25 Aug '17

Full_Name: Ian Puleston Version: 2.4.40 OS: VxWorks URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.118.31.9) If connect and delete callbacks are registered via LDAP_OPT_CONNECT_CB, then the lc_add callback is called when the TCP connects, but if TLS then fails to connect the lc_del does not get called. If these callbacks are doing something like allocating/freeing resources this can lead to a resource leak. When I am seeing this, the sequence of calls leading to the lc_add callback is as follows: ldap_new_connection -> ldap_int_open_connection -> ldap_connect_to_host -> ldap_int_connect_cbs() Then if ldap_connect_to_host returned 0 for synchronous success this call happens: ldap_new_connection -> ldap_int_open_connection -> ldap_int_tls_start And if that fails and returns something other than LDAP_SUCCESS then ldap_int_open_connection exits. So we got a call to lc_add but no corresponding call to lc_del. And note that there is not call to ldap_free_connection, presumably because ldap-new-connection did not succeed, hence the lc_del callback does not get called from there. In my case when I see this it is on a referral with the above calls made from ldap_chase_v3referrals, hence it is happening synchronously. Whether the same would happen with an asynchronous connect I don't know. I do have a working fix which is to make the lc_del callbacks directly from ldap_int_open_connection if ldap_int_tls_start fails. I will supply a patch for that shortly.

1 0

Re: (ITS#8714) RFE: Sendout EXTENDED operation message in back-sock
by hyc＠symas.com 25 Aug '17

25 Aug '17

michael(a)stroeder.com wrote: > + /* write out the request to the extended process */ > + fprintf( fp, "EXTENDED\n" ); > + fprintf( fp, "msgid: %ld\n", (long) op->o_msgid ); > + sock_print_conn( fp, op->o_conn, si ); > + sock_print_suffixes( fp, op->o_bd ); > + fprintf( fp, "oid: %s\n", op->ore_reqoid.bv_val ); > + if (op->ore_reqdata) { > + fprintf( fp, "valuelen: %lu\n", op->ore_reqdata->bv_len ); > + fprintf( fp, "value: %s\n", op->ore_reqdata->bv_val ); > + } > + fprintf( fp, "\n" ); This isn't safe. The reqdata is binary, not a nul-terminated C string. I suppose you could hex or base64-encode it instead. -- -- 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#8637) OpenLDAP crashing when defining multiple olcDbURI for chaining
by okuznik＠symas.com 25 Aug '17

25 Aug '17

This configuration should have been rejected by back-config just like it is rejected by slapd.conf. Patch to have this happen is at: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170825-ITS8637.patch This doesn't reject online modifications just touching olcDBURI, but I think back ldap has no idea when it's configured as a slave to the chain overlay, so it can't do much. --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by okuznik＠symas.com 25 Aug '17

25 Aug '17

On Thu, Aug 24, 2017 at 03:55:32PM +0100, Ond=C5=99ej Kuzn=C3=ADk wrote: > I think it looks like this: syncproc_checkpoint modifies the suffix > entry, that calls slap_graduate_commit_csn and the csn is removed from > be_pending_csn_list. accesslog_response then can't find the CSN there > and has nothing to insert into its own pending csn list. Strange that > changing the overlay order (accesslog vs. syncprov) doesn't change this > behaviour, something I'd expect if the above is the reason this happens= . In any case, having the checkpoint modification get its own CSN entry lets the main operation CSN entry persist, which fixes this issue and all operations that need a CSN seem to get it. Patch is available at: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170825-ITS8444.patch --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#8717) Connection delete callback registreed with LDAP_OPT_CONNECT_CB is not called on TLS failure
by ipuleston＠sonicwall.com 24 Aug '17

24 Aug '17

1 0

Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by okuznik＠symas.com 24 Aug '17

24 Aug '17

On Wed, Aug 23, 2017 at 02:42:29PM +0100, Ond=C5=99ej Kuzn=C3=ADk wrote: > It is caused by the cookie not containing CSN and a race between the > syncCookie check in do_syncrep2 and syncrepl_message_to_op. >=20 > This race is probably fine with plain syncrepl which is idempotent, but > deltasync changes get their own dn in each accesslog instance and some > can be applied twice unless we know how to find out we've already seen > them - they need to mention the CSN. >=20 > The CSN itself gets lost on at least one occasion - when there's a > checkpoint triggered. Not 100 % sure why the cookie gets eaten because > of it, the op pointer is different between the syncprov_op_response tha= t > calls syncprov_checkpoint and the one that decides CSN hasn't changed. Yes, whenever a checkpoint happens, the syncCookie in cn=3Daccesslog only contains rid=3DXXX,sid=3DYYY. I thought that was because the checkpoint results in a new accesslog entry and that would be transmitted first, but that's not the case, there is no accesslog entry nor anything sent to the client (as observed by ldapsearch -E sync=3Drp). I think it looks like this: syncproc_checkpoint modifies the suffix entry, that calls slap_graduate_commit_csn and the csn is removed from be_pending_csn_list. accesslog_response then can't find the CSN there and has nothing to insert into its own pending csn list. Strange that changing the overlay order (accesslog vs. syncprov) doesn't change this behaviour, something I'd expect if the above is the reason this happens. --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by okuznik＠symas.com 23 Aug '17

23 Aug '17

It is caused by the cookie not containing CSN and a race between the syncCookie check in do_syncrep2 and syncrepl_message_to_op. This race is probably fine with plain syncrepl which is idempotent, but deltasync changes get their own dn in each accesslog instance and some can be applied twice unless we know how to find out we've already seen them - they need to mention the CSN. The CSN itself gets lost on at least one occasion - when there's a checkpoint triggered. Not 100 % sure why the cookie gets eaten because of it, the op pointer is different between the syncprov_op_response that calls syncprov_checkpoint and the one that decides CSN hasn't changed. --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8716) Install error
by quanah＠symas.com 21 Aug '17

21 Aug '17

--On Monday, August 21, 2017 4:45 PM +0000 germinouz(a)gmail.com wrote: Hello, The ITS system is for reporting bugs in the software, not for asking question on how to do things such as build software. Please redirect your question to openldap-technical(a)openldap.org if you need help with how to set up a proper environment for building software. I would note the error is rather obvious from the config.log you supplied: > configure:5786: cc -I /usr/local/BerkeleyDB/6.2.32/include > -L/usr/local/lib -L/usr/local/BerkeleyDB/6.2.32/lib > -R/data/BerkeleyDB/6.2.32/lib conftest.c >> &5 > cc: error: unrecognized command line option '-R' Hope that helps! 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>

1 0

(ITS#8716) Install error
by germinouz＠gmail.com 21 Aug '17

21 Aug '17

Full_Name: Frank Vincent Version: 2.4.45 OS: RedHat7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.27.65) When I install on RH7, I get an error. [root@localhost openldap-2.4.45]# ./configure --prefix=/data/openldap Configuring OpenLDAP 2.4.45-Release ... checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking configure arguments... done checking for cc... cc checking for ar... ar checking for style of include used by make... GNU checking whether the C compiler works... no configure: error: in `/root/data/openldap-2.4.45': configure: error: C compiler cannot create executables See `config.log' for more details. [root@localhost openldap-2.4.45]# cat config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.65. Invocation command line was $ ./configure --prefix=/data/openldap ## --------- ## ## Platform. ## ## --------- ## hostname = localhost.localdomain uname -m = x86_64 uname -r = 3.10.0-514.el7.x86_64 uname -s = Linux uname -v = #1 SMP Wed Oct 19 11:24:13 EDT 2016 /usr/bin/uname -p = x86_64 /bin/uname -X = unknown /bin/arch = x86_64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /usr/sbin PATH: /usr/bin PATH: /root/bin PATH: /usr/java/jdk1.8.0_131/bin PATH: /opt/apache-tomcat-8.0.36/bin ## ----------- ## ## Core tests. ## ## ----------- ## configure:2890: checking build system type configure:2904: result: x86_64-unknown-linux-gnu configure:2924: checking host system type configure:2937: result: x86_64-unknown-linux-gnu configure:2957: checking target system type configure:2970: result: x86_64-unknown-linux-gnu configure:3012: checking for a BSD-compatible install configure:3080: result: /usr/bin/install -c configure:3091: checking whether build environment is sane configure:3128: result: yes configure:3190: checking for gawk configure:3206: found /usr/bin/gawk configure:3217: result: gawk configure:3228: checking whether make sets $(MAKE) configure:3250: result: yes configure:3467: checking configure arguments configure:5060: result: done configure:5232: checking for cc configure:5248: found /usr/bin/cc configure:5259: result: cc configure:5282: checking for ar configure:5298: found /usr/bin/ar configure:5309: result: ar configure:5367: checking for style of include used by make configure:5395: result: GNU configure:5724: checking for C compiler version configure:5733: cc --version >&5 cc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:5744: $? = 0 configure:5733: cc -v >&5 Using built-in specs. COLLECT_GCC=cc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) configure:5744: $? = 0 configure:5733: cc -V >&5 cc: error: unrecognized command line option '-V' cc: fatal error: no input files compilation terminated. configure:5744: $? = 4 configure:5733: cc -qversion >&5 cc: error: unrecognized command line option '-qversion' cc: fatal error: no input files compilation terminated. configure:5744: $? = 4 configure:5764: checking whether the C compiler works configure:5786: cc -I /usr/local/BerkeleyDB/6.2.32/include -L/usr/local/lib -L/usr/local/BerkeleyDB/6.2.32/lib -R/data/BerkeleyDB/6.2.32/lib conftest.c >&5 cc: error: unrecognized command line option '-R' configure:5790: $? = 1 configure:5828: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "" | #define OPENLDAP_PACKAGE "OpenLDAP" | #define OPENLDAP_VERSION "2.4.45" | #define LDAP_VENDOR_VERSION 20445 | #define LDAP_VENDOR_VERSION_MAJOR 2 | #define LDAP_VENDOR_VERSION_MINOR 4 | #define LDAP_VENDOR_VERSION_PATCH 45 | #define HAVE_MKVERSION 1 | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:5833: error: in `/root/data/openldap-2.4.45': configure:5837: error: C compiler cannot create executables See `config.log' for more details. ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=x86_64-unknown-linux-gnu ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set=set ac_cv_env_CPPFLAGS_value='-I /usr/local/BerkeleyDB/6.2.32/include' ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_LDFLAGS_set=set ac_cv_env_LDFLAGS_value='-L/usr/local/lib -L/usr/local/BerkeleyDB/6.2.32/lib -R/data/BerkeleyDB/6.2.32/lib' ac_cv_env_LIBS_set= ac_cv_env_LIBS_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_host=x86_64-unknown-linux-gnu ac_cv_path_install='/usr/bin/install -c' ac_cv_prog_AR=ar ac_cv_prog_AWK=gawk ac_cv_prog_CC=cc ac_cv_prog_make_make_set=yes ac_cv_shtool=build/shtool ac_cv_target=x86_64-unknown-linux-gnu ## ----------------- ## ## Output variables. ## ## ----------------- ## ACLOCAL='${SHELL} /root/data/openldap-2.4.45/build/missing --run aclocal-1.9' AMDEPBACKSLASH='\' AMDEP_FALSE='#' AMDEP_TRUE='' AMTAR='${SHELL} /root/data/openldap-2.4.45/build/missing --run tar' AR='ar' AS='' AUTH_LIBS='' AUTOCONF='${SHELL} /root/data/openldap-2.4.45/build/missing --run autoconf' AUTOHEADER='${SHELL} /root/data/openldap-2.4.45/build/missing --run autoheader' AUTOMAKE='${SHELL} /root/data/openldap-2.4.45/build/missing --run automake-1.9' AWK='gawk' BDB_LIBS='' BUILD_ACCESSLOG='no' BUILD_AUDITLOG='no' BUILD_BDB='no' BUILD_COLLECT='' BUILD_CONSTRAINT='no' BUILD_DDS='no' BUILD_DENYOP='no' BUILD_DEREF='no' BUILD_DNSSRV='no' BUILD_DYNGROUP='no' BUILD_DYNLIST='no' BUILD_HDB='no' BUILD_LASTMOD='no' BUILD_LDAP='no' BUILD_LIBS_DYNAMIC='' BUILD_MDB='no' BUILD_MEMBEROF='no' BUILD_META='no' BUILD_MONITOR='no' BUILD_NDB='no' BUILD_NULL='no' BUILD_PASSWD='no' BUILD_PERL='no' BUILD_PPOLICY='no' BUILD_PROXYCACHE='no' BUILD_REFINT='no' BUILD_RELAY='no' BUILD_RETCODE='no' BUILD_RWM='no' BUILD_SEQMOD='no' BUILD_SHELL='no' BUILD_SLAPD='no' BUILD_SLAPI='no' BUILD_SOCK='no' BUILD_SQL='no' BUILD_SSSVLV='no' BUILD_SYNCPROV='no' BUILD_THREAD='no' BUILD_TRANSLUCENT='no' BUILD_UNIQUE='no' BUILD_VALSORT='no' CC='cc' CCDEPMODE='' CFLAGS='' CPP='' CPPFLAGS='-I /usr/local/BerkeleyDB/6.2.32/include' CYGPATH_W='echo' DEFS='' DEPDIR='.deps' DLLTOOL='' ECHO='echo' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='' EXEEXT='' GREP='' ICU_LIBS='' INSTALL_DATA='${INSTALL} -m 644' INSTALL_PROGRAM='${INSTALL}' INSTALL_SCRIPT='${INSTALL}' INSTALL_STRIP_PROGRAM='${SHELL} $(install_sh) -c -s' KRB4_LIBS='' KRB5_LIBS='' LDAP_LIBS='' LDFLAGS='-L/usr/local/lib -L/usr/local/BerkeleyDB/6.2.32/lib -R/data/BerkeleyDB/6.2.32/lib' LIBOBJS='' LIBS='' LIBSLAPI='' LIBSRCS='' LIBTOOL='' LN_S='' LTHREAD_LIBS='' LTLIBOBJS='' LTSTATIC='' LUTIL_LIBS='' MAKEINFO='${SHELL} /root/data/openldap-2.4.45/build/missing --run makeinfo' MODULES_LIBS='' MOD_PERL_LDFLAGS='' MYSQL='' OBJDUMP='' OBJEXT='' OL_MKDEP='' OL_MKDEP_FLAGS='' OPENLDAP_LIBRELEASE='2.4' OPENLDAP_LIBVERSION='12:8:10' OPENLDAP_RELEASE_DATE='2017/06/01' PACKAGE='OpenLDAP' PACKAGE_BUGREPORT='' PACKAGE_NAME='' PACKAGE_STRING='' PACKAGE_TARNAME='' PACKAGE_URL='' PACKAGE_VERSION='' PATH_SEPARATOR=':' PERLBIN='' PERL_CPPFLAGS='' PLAT='' RANLIB='' SASL_LIBS='' SET_MAKE='' SHELL='/bin/sh' SLAPD_DYNAMIC_BACKENDS='' SLAPD_DYNAMIC_OVERLAYS='' SLAPD_GMP_LIBS='' SLAPD_LIBS='' SLAPD_MODULES_CPPFLAGS='' SLAPD_MODULES_LDFLAGS='' SLAPD_NDB_INCS='' SLAPD_NDB_LIBS='' SLAPD_NO_STATIC='' SLAPD_PERL_LDFLAGS='' SLAPD_SLAPI_DEPEND='' SLAPD_SLP_LIBS='' SLAPD_SQL_INCLUDES='' SLAPD_SQL_LDFLAGS='' SLAPD_SQL_LIBS='' SLAPD_STATIC_BACKENDS='back-ldif' SLAPD_STATIC_OVERLAYS='' SLAPI_LIBS='' STRIP='' TLS_LIBS='' VERSION='2.4.45' WITH_ACI_ENABLED='' WITH_MODULES_ENABLED='' WITH_SASL='' WITH_TLS='' WRAP_LIBS='' ac_ct_CC='' am__fastdepCC_FALSE='' am__fastdepCC_TRUE='' am__include='include' am__leading_dot='.' am__quote='' am__tar='${AMTAR} chof - "$$tardir"' am__untar='${AMTAR} xf -' bindir='${exec_prefix}/bin' build='x86_64-unknown-linux-gnu' build_alias='' build_cpu='x86_64' build_os='linux-gnu' build_vendor='unknown' datadir='${datarootdir}' datarootdir='${prefix}/share' docdir='${datarootdir}/doc/${PACKAGE}' dvidir='${docdir}' exec_prefix='NONE' host='x86_64-unknown-linux-gnu' host_alias='' host_cpu='x86_64' host_os='linux-gnu' host_vendor='unknown' htmldir='${docdir}' includedir='${prefix}/include' infodir='${datarootdir}/info' install_sh='/root/data/openldap-2.4.45/build/install-sh' ldap_subdir='/openldap' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' localedir='${datarootdir}/locale' localstatedir='${prefix}/var' mandir='${datarootdir}/man' mkdir_p='mkdir -p --' oldincludedir='/usr/include' pdfdir='${docdir}' prefix='/data/openldap' program_transform_name='s,x,x,' psdir='${docdir}' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target='x86_64-unknown-linux-gnu' target_alias='' target_cpu='x86_64' target_os='linux-gnu' target_vendor='unknown' top_builddir='/root/data/openldap-2.4.45' ## ----------- ## ## confdefs.h. ## ## ----------- ## /* confdefs.h */ #define PACKAGE_NAME "" #define PACKAGE_TARNAME "" #define PACKAGE_VERSION "" #define PACKAGE_STRING "" #define PACKAGE_BUGREPORT "" #define PACKAGE_URL "" #define OPENLDAP_PACKAGE "OpenLDAP" #define OPENLDAP_VERSION "2.4.45" #define LDAP_VENDOR_VERSION 20445 #define LDAP_VENDOR_VERSION_MAJOR 2 #define LDAP_VENDOR_VERSION_MINOR 4 #define LDAP_VENDOR_VERSION_PATCH 45 #define HAVE_MKVERSION 1 configure: exit 77

1 0

(ITS#8715) Typo in man page description of olcTLSCipherSuite?
by james＠turnersoft.co.uk 19 Aug '17

19 Aug '17

Full_Name: James Turner Version: 2.4 OS: Ubuntu 16.04 LTS URL: Submission from: (NULL) (81.86.27.193) File: /doc/man/man5/slapd-config.5 The following example is given at line 832 (correct for Git master branch at time of writing): TLSCiphersuite SECURE256:!AES-128-CBC Shouldn't this read: olcTLSCiphersuite: SECURE256:!AES-128-CBC

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