openldap-bugs December 2013

openldap-bugs@openldap.org

19 participants
55 discussions

Re: (ITS#7758) slapcat exports entire databases when given a non-existent base
by hyc＠symas.com 04 Dec '13

04 Dec '13

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.35 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.58.125) > > > If the root of the primary database is "", and you try and export a base that > doesn't exist via slapcat, the entire database is exported (i.e., it acts like > you specified "" as the base): Works as designed. -b selects the backend that matches the DN you provided. A backend with suffix "" matches anything that nothing more specific matched. If you wanted to filter down to a specific branch, you should have used -s. Closing this ITS. > > [root@zcs724 ldap]# /opt/zimbra/openldap/sbin/slapcat -b cn=ThisDoesntExist -F > /opt/zimbra/data/ldap/config -l /tmp/q.test > > dn: cn=zimbra > objectClass: organizationalRole > description: Zimbra Systems Application Data > cn: zimbra > structuralObjectClass: organizationalRole > entryUUID: 1f75edee-6b87-1032-961f-b17f0b52f5bc > creatorsName: cn=config > createTimestamp: 20130617104800Z > entryCSN: 20130617104800.311168Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20130617104800Z > > dn: cn=admins,cn=zimbra > objectClass: organizationalRole > description: admin accounts > cn: admins > structuralObjectClass: organizationalRole > entryUUID: 1f7d451c-6b87-1032-9620-b17f0b52f5bc > creatorsName: cn=config > createTimestamp: 20130617104800Z > entryCSN: 20130617104800.359221Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20130617104800Z > > dn: uid=zimbra,cn=admins,cn=zimbra > uid: zimbra > objectClass: zimbraAccount > objectClass: organizationalPerson > cn: zimbra > sn: zimbra > zimbraAccountStatus: active > zimbraIsAdminAccount: TRUE > zimbraIsSystemResource: TRUE > zimbraId: e0fafd89-1360-11d9-8661-000a95d98ef2 > description: The master zimbra admin account > userPassword:: text= > structuralObjectClass: organizationalPerson > entryUUID: 1f7e29e6-6b87-1032-9621-b17f0b52f5bc > creatorsName: cn=config > createTimestamp: 20130617104800Z > zimbraLastLogonTimestamp: 20131202121011Z > entryCSN: 20131202121011.054477Z#000000#000#000000 > modifiersName: uid=zimbra,cn=admins,cn=zimbra > modifyTimestamp: 20131202121011Z > > > (etc) > > -- -- 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#7758) slapcat exports entire databases when given a non-existent base
by quanah＠OpenLDAP.org 04 Dec '13

04 Dec '13

Full_Name: Quanah Gibson-Mount Version: 2.4.35 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.58.125) If the root of the primary database is "", and you try and export a base that doesn't exist via slapcat, the entire database is exported (i.e., it acts like you specified "" as the base): [root@zcs724 ldap]# /opt/zimbra/openldap/sbin/slapcat -b cn=ThisDoesntExist -F /opt/zimbra/data/ldap/config -l /tmp/q.test dn: cn=zimbra objectClass: organizationalRole description: Zimbra Systems Application Data cn: zimbra structuralObjectClass: organizationalRole entryUUID: 1f75edee-6b87-1032-961f-b17f0b52f5bc creatorsName: cn=config createTimestamp: 20130617104800Z entryCSN: 20130617104800.311168Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130617104800Z dn: cn=admins,cn=zimbra objectClass: organizationalRole description: admin accounts cn: admins structuralObjectClass: organizationalRole entryUUID: 1f7d451c-6b87-1032-9620-b17f0b52f5bc creatorsName: cn=config createTimestamp: 20130617104800Z entryCSN: 20130617104800.359221Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130617104800Z dn: uid=zimbra,cn=admins,cn=zimbra uid: zimbra objectClass: zimbraAccount objectClass: organizationalPerson cn: zimbra sn: zimbra zimbraAccountStatus: active zimbraIsAdminAccount: TRUE zimbraIsSystemResource: TRUE zimbraId: e0fafd89-1360-11d9-8661-000a95d98ef2 description: The master zimbra admin account userPassword:: text= structuralObjectClass: organizationalPerson entryUUID: 1f7e29e6-6b87-1032-9621-b17f0b52f5bc creatorsName: cn=config createTimestamp: 20130617104800Z zimbraLastLogonTimestamp: 20131202121011Z entryCSN: 20131202121011.054477Z#000000#000#000000 modifiersName: uid=zimbra,cn=admins,cn=zimbra modifyTimestamp: 20131202121011Z (etc)

1 0

Re: (ITS#7757) Memory leak
by huaraz＠moeller.plus.com 03 Dec '13

03 Dec '13

That was quick ! And my leak is gone. Thank you Markus -----Original Message----- From: Howard Chu Sent: Tuesday, December 03, 2013 10:17 PM To: huaraz(a)moeller.plus.com ; openldap-its(a)openldap.org Subject: Re: (ITS#7757) Memory leak huaraz(a)moeller.plus.com wrote: > Full_Name: > Version: 2.4.33 > OS: OpenSuSe 12.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a01:348:1f9::11) > > > I identified a memory leak when using sasl > > ==14039== 34 (32 direct, 2 indirect) bytes in 2 blocks are definitely lost > in > loss record 561 of 666 > ==14039== at 0x4C2C27B: malloc (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==14039== by 0x558E764: ber_memalloc_x (memory.c:228) > ==14039== by 0x558A8B7: ber_get_stringal (decode.c:582) > ==14039== by 0x558AFF5: ber_scanf (decode.c:806) > ==14039== by 0x535535D: ldap_parse_sasl_bind_result (sasl.c:327) > ==14039== by 0x5351FE1: ldap_int_sasl_bind (cyrus.c:551) > ==14039== by 0x5355810: ldap_sasl_interactive_bind (sasl.c:474) > ==14039== by 0x5355A0C: ldap_sasl_interactive_bind_s (sasl.c:511) > ==14039== by 0x44DDC9: tool_sasl_bind (ldap.c:2338) A fix for this is now in git master (rev f8efeb42783f958dd0dc997f8084e6b3b4502830 ) Please test and report your results, thanks. -- -- 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#7757) Memory leak
by hyc＠symas.com 03 Dec '13

03 Dec '13

huaraz(a)moeller.plus.com wrote: > Full_Name: > Version: 2.4.33 > OS: OpenSuSe 12.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a01:348:1f9::11) > > > I identified a memory leak when using sasl > > ==14039== 34 (32 direct, 2 indirect) bytes in 2 blocks are definitely lost in > loss record 561 of 666 > ==14039== at 0x4C2C27B: malloc (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==14039== by 0x558E764: ber_memalloc_x (memory.c:228) > ==14039== by 0x558A8B7: ber_get_stringal (decode.c:582) > ==14039== by 0x558AFF5: ber_scanf (decode.c:806) > ==14039== by 0x535535D: ldap_parse_sasl_bind_result (sasl.c:327) > ==14039== by 0x5351FE1: ldap_int_sasl_bind (cyrus.c:551) > ==14039== by 0x5355810: ldap_sasl_interactive_bind (sasl.c:474) > ==14039== by 0x5355A0C: ldap_sasl_interactive_bind_s (sasl.c:511) > ==14039== by 0x44DDC9: tool_sasl_bind (ldap.c:2338) A fix for this is now in git master (rev f8efeb42783f958dd0dc997f8084e6b3b4502830 ) Please test and report your results, thanks. -- -- 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#7757) Memory leak
by huaraz＠moeller.plus.com 03 Dec '13

03 Dec '13

Full_Name: Version: 2.4.33 OS: OpenSuSe 12.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a01:348:1f9::11) I identified a memory leak when using sasl ==14039== 34 (32 direct, 2 indirect) bytes in 2 blocks are definitely lost in loss record 561 of 666 ==14039== at 0x4C2C27B: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==14039== by 0x558E764: ber_memalloc_x (memory.c:228) ==14039== by 0x558A8B7: ber_get_stringal (decode.c:582) ==14039== by 0x558AFF5: ber_scanf (decode.c:806) ==14039== by 0x535535D: ldap_parse_sasl_bind_result (sasl.c:327) ==14039== by 0x5351FE1: ldap_int_sasl_bind (cyrus.c:551) ==14039== by 0x5355810: ldap_sasl_interactive_bind (sasl.c:474) ==14039== by 0x5355A0C: ldap_sasl_interactive_bind_s (sasl.c:511) ==14039== by 0x44DDC9: tool_sasl_bind (ldap.c:2338)

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2013