openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: (ITS#8081) syncprov crash in syncprov_op_mod
by quanah＠zimbra.com 03 Apr '15

03 Apr '15

--On Saturday, April 04, 2015 1:03 AM +0300 Leonid Yuriev <leo(a)yuriev.ru> wrote: > I had saw a queer in the CHANGES of 2.4 branch, and also comment of > aecec6a75. > > Exactly: Fixed slapo-syncprov deadlock when autogroup is in use > (ITS#8063,ITS#8081) > > But really, this (ITS#8081) is NOT related to autogroup (ITS#8063). > This bug was introduced by 7561998f7 (ITS#6335, Quanah Gibson-Mount > <quanah(a)openldap.org>, 2009-10-30). ITS#6335 was introduced in OpenLDAP 2.4.20. So wouldn't this then affect all releases since 2.4.20? Just so I can note that. ;) Also 6335 was not introduced by me. I simply sync'd it from master to RE24. ;) commit 739f8d075394ee3e85c3f2de7aa4031b36f54c8f Author: Rein Tollevik <rein(a)openldap.org> Date: Fri Oct 16 17:27:18 2009 +0000 ITS#6335 Don't reuse a modtarget someone is about to remove --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8081) syncprov crash in syncprov_op_mod
by leo＠yuriev.ru 03 Apr '15

03 Apr '15

I had saw a queer in the CHANGES of 2.4 branch, and also comment of aecec6a75. Exactly: Fixed slapo-syncprov deadlock when autogroup is in use (ITS#8063,ITS#8081) But really, this (ITS#8081) is NOT related to autogroup (ITS#8063). This bug was introduced by 7561998f7 (ITS#6335, Quanah Gibson-Mount <quanah(a)openldap.org>, 2009-10-30). Yes, after ITS#8063 this bug could be seen as SIGSEGV. But before ITS#8063 the syncprov could `re-order` notifications of changes that are visible by a remote syncrepl. Under a highload (our use case) this makes possible to 'lost' a some changes by replication, and then spread this error to all nodes of ldap-cluster (I spent a lot of time to dig this). So, this is a INDEPENDENT (critical) bug in syncprov (not in autogroup), which is also present in 2.4.40 release and so on.

1 0

Re: (ITS#8090) libldap bugfix: Spurious initial LDAP_CONNECT_ERROR with LDAP_OPT_CONNECT_ASYNC enabled
by hyc＠symas.com 01 Apr '15

01 Apr '15

olli.salli(a)vincit.fi wrote: > Full_Name: Olli Salli > Version: git master > OS: Windows 8.1, Linux 3.18.10 > URL: ftp://ftp.openldap.org/incoming/olli-salli-150325.patch > Submission from: (NULL) (83.102.45.242) Thanks for the report, fixed now in master. > > We are working on an application which needs to perform some simple LDAP search > queries every once in a while. The application is running as a daemon in an > embedded server environment and has no user interface, and is instead remotely > controlled and configured via a control TCP connection. This includes the > configuration specifying the LDAP server address and port, and whether the LDAP > queries should be attempted at all (if there is no server available). We are > currently developing on Windows 8.1 with Visual Studio 2013 but will also run in > Linux environments. > > To ensure the control TCP connection stays alive at all times (and the daemon > otherwise functional), and to avoid using threads, whahave used the openldap > asynchronous APIs, including the asynchronous connect option - if the configured > LDAP server is unreachable, the initial search query can block for a very long > time otherwise. It is here that we have hit a small issue. > > When using LDAP_OPT_CONNECT_ASYNC, if the LDAP server is unreachable, the > initial request (e.g. using ldap_search_ext) does not block, which is correct. > However, this first call returns LDAP_CONNECT_ERROR. If we disregard this, and > continue reissuing the ldap_search_ext request periodically, following calls > correctly return LDAP_X_CONNECTING. Then when the NETWORK_TIMEOUT has elapsed, > LDAP_CONNECT_ERROR is returned again, which is correct. > > LDAP_CONNECT_ERROR might result in the first ldap_search_ext call from > legitimate error conditions in connect() even in asynchronous mode, for example > out-of-resource conditions (EADDRNOTAVAIL), or all local network interfaces > being down (ENETUNREACH), etc. These should be handled as fatal errors, but > would be impossible to distinguish from the false initial LDAP_CONNECT_ERROR > resulting from using LDAP_OPT_CONNECT_ASYNC. > > The issue seems to be in ldap_send_initial_request > (http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/…). > > When async connect is enabled what happens during the first request is: > 1) sd is initialized to AC_SOCKET_INVALID > 2) ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) is called to determine whether > there is already a connection, and to fetch its socket descriptor to sd > 3) as there is no connection, it returns -1 and sd stays AC_SOCKET_INVALID > 4) a new connection is formed using ldap_open_defconn() > 5) ldap_int_check_async_open( ld, sd ) is called, but sd is still > AC_SOCKET_INVALID, and thus the poll fails > 6) LDAP_CONNECT_ERROR is returned > > On successive calls, what happens is > 1) ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) returns success and a valid > socket descriptor > 2) opening a new connection is skipped > 3) ldap_int_check_async_open( ld, sd ) is called this time with a valid socket > descriptor > 4) the poll works as intended > > A simple fix is to simply reissue ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) > after opening the connection. This fixes the first poll to return > LDAP_X_CONNECTING as intended. This is implemented in the patch at the URL. A > perhaps more semantically correct alternative could be to return the created > socket descriptor from ldap_open_defconn(). > > -- -- 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#8093) Error string for LDAP_X_CONNECTING is missing
by hyc＠symas.com 01 Apr '15

01 Apr '15

mikko.auvinen(a)vincit.fi wrote: > Full_Name: Mikko Auvinen > Version: git master > OS: Windows 8.1 > URL: ftp://ftp.openldap.org/incoming/mikko-auvinen-150326.patch > Submission from: (NULL) (83.102.45.242) > > > ldap_search_ext() returns LDAP_X_CONNECTING when async connect attempt is > ongoing. > > ldap_err2string() is missing an error string for LDAP_X_CONNECTING so it's > returning "Unknown API error". > > Here's a patch that fixes this. > > Thanks, committed to 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

Re: (ITS#8092) slapd crash with sasl auxprop and empty suffix
by hyc＠symas.com 01 Apr '15

01 Apr '15

ryan(a)nardis.ca wrote: > Full_Name: Ryan Tandy > Version: master, 2.4 > OS: Debian > URL: > Submission from: (NULL) (24.68.37.4) > > > Based on a Debian bug report: https://bugs.debian.org/781162 > > ./configure --enable-spasswd > > cat > slapd.conf << EOF > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > database mdb > directory . > suffix "" > EOF > > slapadd -f slapd.conf << EOF > dn: dc=com > objectClass: domain > > dn: dc=example,dc=com > objectClass: domain > > dn: uid=test,dc=example,dc=com > objectClass: account > objectClass: simpleSecurityObject > userPassword: {SASL}test(a)EXAMPLE.COM > > EOF > > ldapwhoami -x -D uid=test,dc=example,dc=com > Enter LDAP Password: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffeebab700 (LWP 28815)] > __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210 > 210 ../sysdeps/x86_64/multiarch/../strcmp.S: No such file or directory. > (gdb) bt > #0 __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210 > #1 0x0000000000441689 in select_backend (dn=0x7fffeebaa1a8, noSubs=1) at > backend.c:704 > #2 0x000000000049c7c2 in slap_auxprop_lookup (glob_context=0x0, > sparams=0x7fffe0001cd0, flags=0, > user=0x7fffe0001861 "test(a)EXAMPLE.COM", ulen=16) at sasl.c:370 > #3 0x00007ffff7bc463b in _sasl_auxprop_lookup (sparams=0x7fffe0001cd0, > flags=flags@entry=0, > user=0x7fffe0001861 "test(a)EXAMPLE.COM", ulen=16) at ../../lib/auxprop.c:959 > #4 0x00007ffff7bc5467 in _sasl_auxprop_lookup_user_props > (oparams=0x7fffe0001330, flags=3, conn=0x7fffe0000ac0) > at ../../lib/canonusr.c:220 > #5 _sasl_canon_user_lookup (conn=conn@entry=0x7fffe0000ac0, > user=user@entry=0x7fffe0001460 "test(a)EXAMPLE.COM", > ulen=ulen@entry=0, flags=flags@entry=3, > oparams=oparams@entry=0x7fffe0001330) at ../../lib/canonusr.c:281 > #6 0x00007ffff7bc5d39 in auxprop_verify_password (conn=0x7fffe0000ac0, > userstr=0x7fffe0001460 "test(a)EXAMPLE.COM", > passwd=0x7fffe0002696 "asdf", service=<optimized out>, user_realm=<optimized > out>) at ../../lib/checkpw.c:159 > #7 0x00007ffff7bcee78 in _sasl_checkpass (conn=conn@entry=0x7fffe0000ac0, > user=0x7fffe0001460 "test(a)EXAMPLE.COM", > userlen=userlen@entry=16, pass=pass@entry=0x7fffe0002696 "asdf", > passlen=passlen@entry=4) > at ../../lib/server.c:1922 > #8 0x00007ffff7bd1e50 in sasl_checkpass (conn=0x7fffe0000ac0, user=<optimized > out>, userlen=16, > pas3D0x0x7fffe0002696 "asdf", passlen=4) at ../../lib/server.c:1989 > #9 0x000000000049e4db in chk_sasl (sc=0x8cac98, passwd=0x7fffeebaa8a0, > cred=0x7fffe0002700, text=0x7fffeebaaae0) > at sasl.c:990 > #10 0x0000000000535278 in lutil_passwd (passwd=0x7fffe0003188, > cred=0x7fffe0002700, schemes=0x0, text=0x7fffeebaaae0) > at passwd.c:327 > #11 0x0000000000474aa6 in slap_passwd_check (op=0x7fffe00026b0, > e=0x7fffe0002f28, a=0x7fffe0002fa8, > cred=0x7fffe0002700, text=0x7fffeebaaae0) at passwd.c:529 > #12 0x00000000005088e7 in mdb_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at > bind.c:120 > #13 0x00000000004584f6 in fe_op_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at > bind.c:383 > #14 0x0000000000457bb4 in do_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at > bind.c:205 > #15 0x000000000042f68a in connection_operation (ctx=0x7fffeebaabf0, > arg_v=0x7fffe00026b0) at connection.c:1134 > #16 0x000000000042fc3a in connection_read_thread (ctx=0x7fffeebaabf0, argv=0xc) > at connection.c:1280 > #17 0x00000000005401bf in ldap_int_thread_pool_wrapper (xpool=0x8b83c0) at > tpool.c:958 > #18 0x00007ffff74750a4 in start_thread (arg=0x7fffeebab700) at > pthread_create.c:309 > #19 0x00007ffff71aa04d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 > > I don't know how auxprop is intended to be configured; I'm going to follow up on > that when I have time. This is just about a segv that happens when > pwcheck_method is auxprop (the default) and the suffix is the empty string. Fundamentally this is a configuration error; you should not use SPASSWD with slapd's auxprop. I.e., slapd's auxprop is only intended for use when slapd handles all SASL authentication itself. Using SPASSWD means you're forwarding all SASL authentication to whatever external SASL mechanisms you have configured. In this particular case, slapd has forwarded the authentication request out to libsasl as you requested, and libsasl is forwarding it back into slapd's auxprop but without providing the context that slapd expects. Fixed now in 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

Re: (ITS#8096) man not up to date
by quanah＠zimbra.com 01 Apr '15

01 Apr '15

--On Wednesday, April 01, 2015 6:13 PM +0000 tim.menage(a)gmail.com wrote: > Full_Name: Timothee > Version: @(#) $OpenLDAP: slapd (Ubuntu) (Mar 17 2014 21:20:08) > OS: Linux ldap 3.16.0-31-generic #41~14.04.1-Ubuntu SMP Wed Feb 11 > 19:30:13 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux URL: > ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.225.242.54) > > > Hey, > > If i've understand, slapd is reading config file from /etc/ldap/slapd.d/ > so I just don\t understand why when i do man slapd.conf (as you tell to do > everywhere), why the first lines are: > The file /etc/ldap/slapd.conf contains configuration information for the > slapd(8) daemon. Because both slapd-config(5) and slapd.conf(5) are supported. If you want the man page for slapd-config(5), read that one. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8096) man not up to date
by tim.menage＠gmail.com 01 Apr '15

01 Apr '15

Full_Name: Timothee Version: @(#) $OpenLDAP: slapd (Ubuntu) (Mar 17 2014 21:20:08) OS: Linux ldap 3.16.0-31-generic #41~14.04.1-Ubuntu SMP Wed Feb 11 19:30:13 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.225.242.54) Hey, If i've understand, slapd is reading config file from /etc/ldap/slapd.d/ so I just don\t understand why when i do man slapd.conf (as you tell to do everywhere), why the first lines are: The file /etc/ldap/slapd.conf contains configuration information for the slapd(8) daemon. Thanks

1 0

(ITS#8095) Patch
by rouzier＠gmail.com 31 Mar '15

31 Mar '15

Full_Name: James Rouzier Version: OS: URL: ftp://ftp.openldap.org/incoming/james-rouzier-150331.patch Submission from: (NULL) (192.222.129.11) I am working on a proof of concept of a simple key value store service using lmdb as the back end. I am using sendfile to avoid an extra copy. I accomplished this by creating function to extract get the mmap ptr from the env so I can calculate the offset of data. I figured that function might be useful to the bigger community. If it does not fit in the bigger vision of lmdb it is fine not to include it. I, James Rouzier, 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

Re: (ITS#8094) OpenLdap2.4 rpm for RHEL5.11
by quanah＠zimbra.com 30 Mar '15

30 Mar '15

--On Monday, March 30, 2015 12:49 PM +0000 shashikanthbussa(a)gmail.com wrote: > Full_Name: shashikanth.bussa > Version: 2.4 > OS: RHEL5.11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (115.160.252.10) > > > Hi, > > Please letme know the rpm repo file for Openldap2.4 on RHEL5.11 as i > have not found the openldap2.4 version for RHEl 5.11. The OpenLDAP foundation only releases source. If you want pre-compiled builds, you can look at the builds provided by Symas or the LTB project. As the ITS system is only for reporting bugs, this ITS will be closed. In the future, questions such as this should be directed to the openldap-technical list. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8094) OpenLdap2.4 rpm for RHEL5.11
by shashikanthbussa＠gmail.com 30 Mar '15

30 Mar '15

Full_Name: shashikanth.bussa Version: 2.4 OS: RHEL5.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.160.252.10) Hi, Please letme know the rpm repo file for Openldap2.4 on RHEL5.11 as i have not found the openldap2.4 version for RHEl 5.11. and When i tried to install from source tar ball. i am facing issue with the Barkley DB. hecking for Berkeley DB major version in db.h... 4 checking for Berkeley DB minor version in db.h... 3 checking if Berkeley DB version supported by BDB/HDB backends... no configure: error: BerkeleyDB version incompatible with BDB/HDB backends ... Please help on the above

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