openldap-bugs January 2017

openldap-bugs@openldap.org

22 participants
55 discussions

Re: (ITS#8566) OpenLDAP client API SASL auth memory leak
by hyc＠symas.com 12 Jan '17

12 Jan '17

william.b.clay(a)acm.org wrote: > Full_Name: Bill Clay > Version: 2.4.44 > OS: Debian/GNU Linux 7.8 (Wheezy) > URL: > Submission from: (NULL) (79.12.44.250) > ==4149== 4,896 bytes in 9 blocks are definitely lost in loss record 122 of 124 > ==4149== at 0x4C28CCE: realloc (vg_replace_malloc.c:632) > ==4149== by 0x7712426: _plug_buf_alloc (in > /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25) > ==4149== by 0x770C232: add_to_challenge (in > /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25) > ==4149== by 0x770E689: make_client_response (in > /r%r/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25) > ==4149== by 0x770EC97: digestmd5_client_mech_step (in > /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25) This is very clearly a leak in the digestmd5.so module. It seems you should be reporting this to Cyrus SASL, not us. > ==4149== by 0x5CD03AD: sasl_client_step (in > /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25) > ==4149== by 0x5CD08DA: sasl_client_start (in > /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25) > ==4149== by 0x405386E: ldap_int_sasl_bind (cyrus.c:510) > ==4149== by 0x4056E5F: ldap_sasl_interactive_bind (sasl.c:487) > ==4149== by 0x405702B: ldap_sasl_interactive_bind_s (sasl.c:521) > ==4149== by 0x4027663: mldap_bind (mldap.c:647) > ==4149== by 0x408C31: luaD_precall (in /usr/bin/lua5.2) > ==4149== > ==4149== LEAK SUMMARY: > ==4149== definitely lost: 4,896 bytes in 9 blocks > ==4149== indirectly lost: 0 bytes in 0 blocks > ==4149== possibly lost: 0 bytes in 0 blocks > ==4149== still reachable: 40,718 bytes in 325 blocks > ==4149== suppressed: 0 bytes in 0 blocks > ==4149== Reachable blocks (those to which a pointer was found) are not shown.D%D > ==4149== To see them, rerun with: --leak-check=full --show-reachable=yes > ==4149== > ==4149== For counts of detected and suppressed errors, rerun with: -v > ==4149== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 31 from 7) > bill@fuji:/usr/local/src/liquid_feedback_frontend-v3.2.1/lib/mldap$ > > -- -- 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#8566) correction: "symptom details"
by william.b.clay＠acm.org 11 Jan '17

11 Jan '17

The 4th and 5th bullet points under "symptom details" of my original ticket text are not supported by the evidence. Corrected replacements: * Valgrind does NOT show lost memory after a ONE SASL authentication by a process. * Valgrind shows N-1 lost memory blocks after N multiple SASL authentications by a process. Given the same credentials and mech, each such block is the same size, ca. 500-600 bytes. On reflection, it is probably the LAST authentication that frees the memory block in question, although my testing seems to indicate it is NOT unbind() that does so; perhaps some sort of process termination callback in OpenLDAP, SASL, or MD5 library code? Sorry about the initial inaccuracy.

1 0

(ITS#8566) OpenLDAP client API SASL auth memory leak
by william.b.clay＠acm.org 11 Jan '17

11 Jan '17

Full_Name: Bill Clay Version: 2.4.44 OS: Debian/GNU Linux 7.8 (Wheezy) URL: Submission from: (NULL) (79.12.44.250) Valgrind runs of a testbed script driving an OpenLDAP API client module I am developing appear to show a consistent, reproducible memory leak ("lost memory") when using the SASL default authentication mech (DIGEST-MD5 for my system) over any underlying transport: ldapi://, ldap://, ldaps://. The first two transports show identical symptoms with or without startTLS prior to authentication. Additional test and symptom details: * Using the same testbed and client module and either SASL mech EXTERNAL or LDAP simple bind, valgrind indicates no lost memory. * Symptoms are constant with or without proxy authz (i.e., a SASL interactive callback SASL_CB_USER response). * I have not configured or tested other SASL mechs in this environment. * The FIRST SASL authentication of a process does NOT show a memory leak. * Each SASL authentication of a process AFTER the first shows a one additional realloc leak of the same size (500-600 bytes depending on bind details). * The iterative test is: [ldap_initialize()], [ldap_start_tls_s()], ldap_sasl_interactive_bind_s(), [ldap_search_ext_s()], [ldap_whoami_s()], [ldap_unbind_ext_s()], where [] indicates calls whose omission yields no change in symptoms (except initialize is always called for the first iteration of a sequence and after an unbind; unbind is always called after the last iteration). Environment: Debian 7 Wheezy OpenLDAP v. 2.4.44 original (not Debian) source custom build: ./configure --sysconfdir=/etc --localstedirir=/ \ --disable-backends --enable-mdb --enable-monitor \ --enable-crypt --enable-cleartext \ --with-cyrus-sasl --enable-spasswd --enable-syslog --enable-local \ --disable-overlays --enable-memberof --enable-refint --enable-unique \ --disable-modules --with-tls --with-threads --with-gnu-ld Sample valgrind output (the call stack is always the same, except for exact addresses): bill@fuji:/usr/local/src/liquid_feedback_frontend-v3.2.1/lib/mldap$ LD_PRELOAD=/usr/local/src/liquid_feedback_frontend-v3.2.1/lib/mldap/mldap.so valgrind --leak-check=full /usr/local/src/altit-sso/lf-ldap/mldap_full_test.lua ==4149== Memcheck, a memory error detector ==4149== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==4149== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==4149== Command: /usr/local/src/altit-sso/lf-ldap/mldap_full_test.lua ==4149== create cctx regkey 556aeaf3c864af2e_mldap_connection, cctx=0699c028, stack 0 1 1 SASL bind uid %2p%p/w enter mldap_bind(), regkey=556aeaf3c864af2e_mldap_connection, cctx=0x699c028 mldap_bind call ldap_initialize("ldap://fuji.pvt.suresys.com") mldap_bind after ldap_bind(0x699cac0), cctx=0x699c028 DIGEST-MD5,CRAM-MD5,NTLM dn:uid=jdoe,ou=persone,dc=altraitalia,dc=test < snip - 8 iterations removed > 10 1 SASL bind uid + p/w enter mldap_bind(), regkey=556aeaf3c864af2e_mldap_connection, cctx=0x699c028 mldap_bind after ldap_bind(0x699cac0), cctx=0x699c028 DIGEST-MD5,CRAM-MD5,LMLM dn:uid=jdoe,ou=persone,dc=altraitalia,dc=test unbind cctx->ldp=0x699cac0 exit unbind normal termination, 10 iterations enter mldap_gc(); cctx->ldp=0 exit mldap_gc() ==4149== ==4149== HEAP SUMMARY: ==4149== in use at exit: 45,614 bytes in 334 blocks ==4149== total heap usage: 3,543 allocs, 3,209 frees, 169,733,045 bytes allocated ==4149== ==4149== 4,896 bytes in 9 blocks are definitely lost in loss record 122 of 124 ==4149== at 0x4C28CCE: realloc (vg_replace_malloc.c:632) ==4149== by 0x7712426: _plug_buf_alloc (in /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25) ==4149== by 0x770C232: add_to_challenge (in /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25) ==4149== by 0x770E689: make_client_response (in /r%r/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25) ==4149== by 0x770EC97: digestmd5_client_mech_step (in /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25) ==4149== by 0x5CD03AD: sasl_client_step (in /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25) ==4149== by 0x5CD08DA: sasl_client_start (in /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25) ==4149== by 0x405386E: ldap_int_sasl_bind (cyrus.c:510) ==4149== by 0x4056E5F: ldap_sasl_interactive_bind (sasl.c:487) ==4149== by 0x405702B: ldap_sasl_interactive_bind_s (sasl.c:521) ==4149== by 0x4027663: mldap_bind (mldap.c:647) ==4149== by 0x408C31: luaD_precall (in /usr/bin/lua5.2) ==4149== ==4149== LEAK SUMMARY: ==4149== definitely lost: 4,896 bytes in 9 blocks ==4149== indirectly lost: 0 bytes in 0 blocks ==4149== possibly lost: 0 bytes in 0 blocks ==4149== still reachable: 40,718 bytes in 325 blocks ==4149== suppressed: 0 bytes in 0 blocks ==4149== Reachable blocks (those to which a pointer was found) are not shown.D%D ==4149== To see them, rerun with: --leak-check=full --show-reachable=yes ==4149== ==4149== For counts of detected and suppressed errors, rerun with: -v ==4149== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 31 from 7) bill@fuji:/usr/local/src/liquid_feedback_frontend-v3.2.1/lib/mldap$

1 0

(ITS#8565) Clarification of the slapo-ppolicy manpage
by matthieu.cerda＠nbs-system.com 11 Jan '17

11 Jan '17

Full_Name: Matthieu Cerda Version: 2.4.40 OS: Debian jessie URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.213.124.6) Hello ! As per http://www.openldap.org/lists/openldap-technical/201701/msg00017.html I would like to submit a small improvement to the slapo-ppolicy manpage to clarify rootdn presence / absence implications in a ppolicy enabled setup. Here is the patch (I thing it's short enough not to justify a separate upload): ---8<--- >From c6c03415e73fe762ee8f77d3e3cad97834913d00 Mon Sep 17 00:00:00 2001 From: Matthieu Cerda <matthieu.cerda(a)nbs-system.com> Date: Tue, 3 Jan 2017 14:45:37 +0100 Subject: [PATCH] Clarify slapo-ppolicy manpage about rootdn absence possible consequences --- doc/man/man5/slapo-ppolicy.5 | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/doc/man/man5/slapo-ppolicy.5 b/doc/man/man5/slapo-ppolicy.5 index 8306f9761..6d3edb9c4 100644 --- a/doc/man/man5/slapo-ppolicy.5 +++ b/doc/man/man5/slapo-ppolicy.5 @@ -28,7 +28,12 @@ Note that some of the policies do not take effect when the operation is performed with the .B rootdn identity; all the operations, when performed with any other identity, -may be subjected to constraints, like access control. +may be subjected to constraints, like access control. It means that +not defining a +.B rootdn +in your configuration is likely to lead to undesirable behavior (like +account locking using pwdLockout not working properly) unless you have +appropriate access control entries. .P Note that the IETF Password Policy proposal for LDAP makes sense when considering a single-valued password attribute, while -- 2.11.0 ---8<--- Thanks in advance, Have a nice day, -- Matthieu Cerda

1 0

Re: (ITS#8557) mdb_put may cause a cursor malfunction
by hyc＠symas.com 11 Jan '17

11 Jan '17

lazarev.michael(a)gmail.com wrote: > Full_Name: Michael Lazarev > Version: > OS: Linux, FreeBSD > URL: ftp://ftp.openldap.org/incoming/mdb_put_test.c > Submission from: (NULL) (128.70.151.136) > > > After a number of mdb_put calls, mdb_cursor_get with MDB_LAST operation > positions the cursor incorrectly. Test code is submitted here: > ftp://ftp.openldap.org/incoming/mdb_put_test.c > > Thanks for the report. Fixed now in git. -- -- 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#6077) Spurious uniqueness errors with filters in unique overlays
by yann-externe.soubeyrand＠edf.fr 10 Jan '17

10 Jan '17

Hi, It seems to be the same bug as bug #6825. If so, this bug is still present in 2.4.44. Regards Yann Soubeyrand

1 0

Re: (ITS#6825) unique_uri filter reaching beyond its intended target
by yann-externe.soubeyrand＠edf.fr 10 Jan '17

10 Jan '17

Hi, This bug is still present in 2.4.44. Also, it seems to be the same bug as bug #6077. Regards Yann Soubeyrand

1 0

Re: (ITS#8564) ppolicy overlay and MMR delta-sync lost sync on switching to REFRESH
by quanah＠symas.com 09 Jan '17

09 Jan '17

--On Monday, January 09, 2017 3:58 PM +0000 bhalsema(a)purdue.edu wrote: > > I apologize...I am not sure how I caused this to be reposted. I apologize > for the duplicate ticket. Thanks Beth, I'll close this one out as a duplicate. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8564) ppolicy overlay and MMR delta-sync lost sync on switching to REFRESH
by bhalsema＠purdue.edu 09 Jan '17

09 Jan '17

I apologize...I am not sure how I caused this to be reposted. I apologize for the duplicate ticket. Beth On Mon, 9 Jan 2017, openldap-its(a)openldap.org wrote: > Date: Mon, 9 Jan 2017 10:55:37 > To: bhalsema(a)purdue.edu > From: openldap-its(a)openldap.org > Subject: Re: (ITS#8564) ppolicy overlay and MMR delta-sync lost sync on > switching to REFRESH > > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#8564. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#8564) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#8564) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=8564 > > Please remember to retain your issue tracking number (ITS#8564) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

(ITS#8564) ppolicy overlay and MMR delta-sync lost sync on switching to REFRESH
by bhalsema＠purdue.edu 09 Jan '17

09 Jan '17

Full_Name: Beth Halsema Version: 2.4.44 OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.210.177.153) The ppolicy overlay attempts to perform an LDAP_MOD_DELETE on attributes that have already been removed via a SLAP_MOD_SOFTDEL. This results in an error like the following: bdb_modify_internal: 16 modify/delete: pwdGraceUseTime: no such attribute bdb_modify: modify failed (16) send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=16 matched="" text="modify/delete: pwdGraceUseTime: no such attribute" null_callback : error code 0x10 slap_graduate_commit_csn: removing 0x7f38bc11c4c0 20170106184533.027966Z#000000#001#000000 syncrepl_message_to_op: rid=001 be_modify uid=nd,ou=People,dc=example,dc=com (16) ... do_syncrep2: rid=001 delta-sync lost sync on (reqStart=20170106184533.000001Z,cn=log), switching to REFRESH I will be uploading a tarfile th c contains a test script, ldif files (used by the test script), and a suggested patch. We have performed limited testing which demonstrated desirable behavior. NOTE: The test script looks for the LDIFs in the DATADIR. I tested the script using the openldap-2.4.44/tests/run script.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2017