openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#7274) delta-syncrepl MMR infinite loop
by quanah＠zimbra.com 18 May '12

18 May '12

--On Wednesday, May 16, 2012 10:27 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.31 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.108.184.39) We can see that the script turning it into a master ran here: Thu May 17 16:05:46 2012 *** Running as zimbra user: /opt/zimbra/libexec/zmldapenable-mmr -s 2 -m ldap://zre-ldap002.eng.vmware.com:389/ so 16:05:46 In the accesslog, we see: dn: cn=accesslog objectClass: auditContainer cn: accesslog structuralObjectClass: auditContainer contextCSN: 20120517225152.913667Z#000000#000#000000 contextCSN: 20120517230823.615364Z#000000#001#000000 contextCSN: 20120517230546.409118Z#000000#002#000000 dn: reqStart=20120517230546.000019Z,cn=accesslog objectClass: auditAdd structuralObjectClass: auditAdd reqStart: 20120517230546.000019Z reqEnd: 20120517230546.000020Z reqType: add reqSession: 100 reqAuthzID: cn=config reqDN: cn=zimbra reqResult: 0 reqMod: objectClass:+ organizationalRole reqMod: description:+ Zimbra Systems Application Data reqMod: cn:+ zimbra reqMod: structuralObjectClass:+ organizationalRole reqMod: entryUUID:+ 40f78bea-34be-1031-8a5d-e1466f667e19 reqMod: creatorsName:+ cn=config reqMod: createTimestamp:+ 20120517224907Z reqMod: entryCSN:+ 20120517224907.221672Z#000000#000#000000 reqMod: modifiersName:+ cn=config reqMod: modifyTimestamp:+ 20120517224907Z reqEntryUUID: 40f78bea-34be-1031-8a5d-e1466f667e19 entryUUID: 948929e2-34c0-1031-9a14-c93bd10ff0f2 creatorsName: cn=config createTimestamp: 20120517224907Z entryCSN: 20120517224907.221672Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20120517224907Z so it is tracking "000" as a third master? This seems to be why the original server (which was 000 before being promoted to 001) replicates these entries back to itself. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7133) slapd dies with SIGSEGV on SIGHUP
by openldap＠stormcloud9.net 17 May '12

17 May '12

I too am experiencing this issue. I attempted to apply the patch from commit 7ff18967d7d2e49baa9d80f1b9408b276f3982e0, but it wont apply cleanly to 2.4.31. I was going to apply it by hand, but it appears the last 2 chunks have had a lot of changes in that area of the code. Is there any chance of getting the patch re-based for 2.4.31? Thanks

1 0

(ITS#7274) delta-syncrepl MMR infinite loop
by quanah＠OpenLDAP.org 17 May '12

17 May '12

Full_Name: Quanah Gibson-Mount Version: 2.4.31 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) The following problem did not occur for me in previous OpenLDAP releases. However, I can reproduce it 100% of the time with OpenLDAP 2.4.31. Basic configuration scenario is as follows: Set up a stand alone OpenLDAP server -- Just cn=config and primary DB. Basic database for the server is created (note all entries now have SID value 0) Update the server to be delta-sync MMR -- Set sid=1, Mirror Mode, and add accesslog DB. Add syncrepl stanza for a second server Install second server as a delta-sycnrepl MMR pair -- cn=config, accesslog DB, primary DB, SID=2 Servers now go into infinite loops due to the SID=0 entries. Server SID=1 logs: May 16 14:33:24 zre-ldap002 slapd[17422]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20120516212017.543213Z#000000#000#000000 May 16 14:33:24 zre-ldap002 slapd[17422]: slap_queue_csn: queing 0x58d2ced 20120516212017.543213Z#000000#000#000000 May 16 14:33:24 zre-ldap002 slapd[17422]: slap_graduate_commit_csn: removing 0x4699f50 20120516212017.543213Z#000000#000#000000 May 16 14:33:24 zre-ldap002 slapd[17422]: syncrepl_message_to_op: rid=100 be_add cn=zimbra (68) May 16 14:33:24 zre-ldap002 slapd[17422]: do_syncrep2: rid=100 delta-sync lost sync on (reqStart=20120516213237.000019Z,cn=accesslog), switching to REFRESH May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_message_to_entry: rid=100 DN: cn=zimbra, UUID: add167b2-33e8-1031-8f62-f1c6fd57f8b3 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 inserted UUID add167b2-33e8-1031-8f62-f1c6fd57f8b3 May 16 14:33:25 zre-ldap002 slapd[17422]: dn_callback : entries have identical CSN cn=zimbra 20120516212017.543213Z#000000#000#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 be_search (0) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 cn=zimbra May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 entry unchanged, ignored (cn=zimbra) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_message_to_entry: rid=100 DN: cn=admins,cn=zimbra, UUID: add18ab2-33e8-1031-8f63-f1c6fd57f8b3 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 inserted UUID add18ab2-33e8-1031-8f63-f1c6fd57f8b3 May 16 14:33:25 zre-ldap002 slapd[17422]: dn_callback : entries have identical CSN cn=admins,cn=zimbra 20120516212017.544170Z#000000#000#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 be_search (0) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 cn=admins,cn=zimbra May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 entry unchanged, ignored (cn=admins,cn=zimbra) (etc, going through all 000 SID entries). Once it finishes, it starts over: May 16 14:33:25 zre-ldap002 slapd[17422]: dn_callback : entries have identical CSN cn=com_zimbra_click2call_mitel,cn=zimlets,cn=zimbra 20120516212615.543144Z#000000#000#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 be_search (0) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 cn=com_zimbra_click2call_mitel,cn=zimlets,cn=zimbra May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 entry unchanged, ignored (cn=com_zimbra_click2call_mitel,cn=zimlets,cn=zimbra) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_message_to_entry: rid=100 DN: cn=zre-ldap003.eng.vmware.com,cn=servers,cn=zimbra, UUID: 5a64830a-33ea-1031-8fbb-f1c6fd57f8b3 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 inserted UUID 5a64830a-33ea-1031-8fbb-f1c6fd57f8b3 May 16 14:33:25 zre-ldap002 slapd[17422]: dn_callback : entries have identical CSN cn=zre-ldap003.eng.vmware.com,cn=servers,cn=zimbra 20120516213323.905859Z#000000#001#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 be_search (0) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 cn=zre-ldap003.eng.vmware.com,cn=servers,cn=zimbra May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 entry unchanged, ignored (cn=zre-ldap003.eng.vmware.com,cn=servers,cn=zimbra) May 16 14:33:25 zre-ldap002 slapd[17422]: do_syncrep2: rid=100 LDAP_RES_SEARCH_RESULT May 16 14:33:25 zre-ldap002 slapd[17422]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20120516213323.905859Z#000000#001#000000;20120516213237.680889Z#000000#002#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: slap_queue_csn: queing 0x5805da0 20120516213237.680889Z#000000#002#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: slap_graduate_commit_csn: removing 0x5805620 20120516213237.680889Z#000000#002#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: do_syncrep2: rid=100 cookie=rid=000,sid=002,csn=20120516212017.543213Z#000000#000#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: slap_queue_csn: queing 0x58d2ced 20120516212017.543213Z#000000#000#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: slap_graduate_commit_csn: removing 0x5805bc0 20120516212017.543213Z#000000#000#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_message_to_op: rid=100 be_add cn=zimbra (68) May 16 14:33:25 zre-ldap002 slapd[17422]: do_syncrep2: rid=100 delta-sync lost sync on (reqStart=20120516213237.000019Z,cn=accesslog), switching to REFRESH May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_message_to_entry: rid=100 DN: cn=zimbra, UUID: add167b2-33e8-1031-8f62-f1c6fd57f8b3 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 inserted UUID add167b2-33e8-1031-8f62-f1c6fd57f8b3 May 16 14:33:25 zre-ldap002 slapd[17422]: dn_callback : entries have identical CSN cn=zimbra 20120516212017.543213Z#000000#000#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 be_search (0) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 cn=zimbra May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 entry unchanged, ignored (cn=zimbra) On the second MMR master server, it logs: May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138856 SRCH attr=* + May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138856 SEARCH RESULT tag=101 err=0 nentries=0 text= May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138857 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138857 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN May 16 14:36:15 zre-ldap003 slapd[26137]: syncprov_search_response: cookie=rid=100,sid=002,csn=20120516212644.426510Z#000000#000#000000;20120516213448.200519Z#000000#001#000000;20120516213237.680085Z#000000#002#000000 May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138858 ABANDON msg=138858 May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138859 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138859 SRCH attr=* + May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138859 SEARCH RESULT tag=101 err=0 nentries=0 text= May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138860 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138860 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138861 ABANDON msg=138861 May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138862 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138862 SRCH attr=* + May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138862 SEARCH RESULT tag=101 err=0 nentries=0 text= May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138863 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138863 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138864 ABANDON msg=138864 May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138865 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138865 SRCH attr=* + May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138865 SEARCH RESULT tag=101 err=0 nentries=0 text= May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138866 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138866 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN May 16 14:36:15 zre-ldap003 slapd[26137]: syncprov_search_response: cookie=rid=100,sid=002,csn=20120516212644.426510Z#000000#000#000000;20120516213448.200519Z#000000#001#000000;20120516213237.680085Z#000000#002#000000 May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138867 ABANDON msg=138867 However, I can get a working delta-sync MMR pair if I do the following: Set up a stand alone OpenLDAP server -- Just cn=config and primary DB. Basic database for the server is created (note all entries now have SID value 0) Update the server to be delta-sync master: add accesslog DB. Install second server as a replica. Update first server to be delta-sync MMR: Set sid=1, mirrormode=true on primary DB, add syncrepl stanza for second server Update second server to be delta-sync MMR: Set sid=2, mirrormode=true on primary DB, add accesslog DB, add syncprel stanza for first server In this scenario everything works as expected. The issue seems to be caused in the first scenario by server 2 replicating the DB with SID=0 bits from the primary server, and that looping back to the first server endlessly, instead of being permanently ignored. --Quanah

1 0

(ITS#7273) Sig abort crash in slapd using GSSAPI auth in slap_listener at daemon.c:1891
by stefan.wold＠su.se 16 May '12

16 May '12

Full_Name: Stefan Wold Version: 2.4.31 OS: Ubuntu and Lunar Linux URL: Submission from: (NULL) (77.238.32.111) I can reproduce a sig abort crash in both Ubuntu and Lunar Linux using OpenLDAP 2.4.31. This crash only seem occur when I run ~20 concurrent ldap searches using -YGSSAPI for authentication, using simple bind (-x) I can't reproduce the crash. Usually slapd crash within a couple of hours using GSSAPI. My test case is quite simple, I start 20 threads that loop the following command: ldapsearch -h server -YGSSAPI uid=user In Ubuntu openldap is linked against cyrus-sasl which links to MIT kerberos. In Lunar Linux cyrus-sasl is linked against heimdal. In this case it doesn't seem to matter which kerberos implementation is used. Here's a brief gdb backtrace: Core was generated by `/usr/lib/slapd -d 0 -h ldap:/// ldaps:/// -f /etc/openldap/slapd.conf'. Program terminated with signal 6, Aborted. #0 0x00007f70313293c5 in raise () from /lib/libc.so.6 (gdb) bt #0 0x00007f70313293c5 in raise () from /lib/libc.so.6 #1 0x00007f703132a83b in abort () from /lib/libc.so.6 #2 0x00007f703132226e in __assert_fail_base () from /lib/libc.so.6 #3 0x00007f7031322312 in __assert_fail () from /lib/libc.so.6 #4 0x00000000004310e7 in slap_listener (sl=0x15c30d0) at daemon.c:1891 #5 0x0000000000431109 in slap_listener_thread (ctx=<optimized out>, ptr=<optimized out>) at daemon.c:2093 #6 0x00007f7032e7dcda in ldap_int_thread_pool_wrapper (xpool=0x15ff920) at tpool.c:688 #7 0x00007f703165cce0 in start_thread () from /lib/libpthread.so.0 #8 0x00007f70313c7abd in clone () from /lib/libc.so.6 For a full backtrace: https://gist.github.com/a82d5b3dfdac7abc8e27 -- Sincerely Stefan Wold IT services, Stockholm University Sweden

1 0

Re: (ITS#7272) Implement hasSubordinates in back-ldif
by h.b.furuseth＠usit.uio.no 14 May '12

14 May '12

michael(a)stroeder.com wrote: > It would be handy to have operational attribute 'hasSubordinates' > returned for entries under cn=config. If so, that can hopefully be done in back-config. It'd be a bit costly in back-ldif - one stat() per read_entry, plus an attempted rmdir(parent dir) in delete/modifyDN so that read_entry can assume there are subordinates if the dir exists. Hallvard

1 0

(ITS#7272) Implement hasSubordinates in back-ldif
by michael＠stroeder.com 13 May '12

13 May '12

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (79.227.175.236) It would be handy to have operational attribute 'hasSubordinates' returned for entries under cn=config.

1 0

Re: (ITS#7271) Don't clobber SASL_NOCANON in clients/tools/common.c
by wking＠tremily.us 13 May '12

13 May '12

--DKU6Jbt7q3WqK7+M Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I forgot to add the notice to the patch I just submitted. Here's the notice: The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by W. Trevor King wking(a)tremily.us. I have not assigned rights and/or interest in this work to any party. I, W. Trevor King, 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. I've attached the patch again, since that matches the language in the notice. Cheers, Trevor --=20 This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tool-nocanon.patch" Content-Transfer-Encoding: quoted-printable ITS#7271 fix SASL_NOCANON clobbering in tools/common.c. diff --git a/clients/tools/common.c b/clients/tools/common.c index 9c98b62..9868658 100644 --- a/clients/tools/common.c +++ b/clients/tools/common.c @@ -1214,6 +1214,7 @@ LDAP * tool_conn_setup( int dont, void (*private_setup)( LDAP * ) ) { LDAP *ld =3D NULL; + int i; =20 if ( debug ) { if( ber_set_option( NULL, LBER_OPT_DEBUG_LEVEL, &debug ) @@ -1410,13 +1411,22 @@ dnssrv_free:; =20 #ifdef HAVE_CYRUS_SASL /* canon */ - if( ldap_set_option( ld, LDAP_OPT_X_SASL_NOCANON, - nocanon ? LDAP_OPT_ON : LDAP_OPT_OFF ) !=3D LDAP_OPT_SUCCESS ) + if( ldap_get_option( ld, LDAP_OPT_X_SASL_NOCANON, &i ) + !=3D LDAP_OPT_SUCCESS ) { - fprintf( stderr, "Could not set LDAP_OPT_X_SASL_NOCANON %s\n", - nocanon ? "on" : "off" ); + fprintf( stderr, "Could not get LDAP_OPT_X_SASL_NOCANON\n" ); tool_exit( ld, EXIT_FAILURE ); } + if (!i) { + fprintf( stderr, "Set NOCANON to %s\n", nocanon ? "on" : "off" ); + if( ldap_set_option( ld, LDAP_OPT_X_SASL_NOCANON, + nocanon ? LDAP_OPT_ON : LDAP_OPT_OFF ) !=3D LDAP_OPT_SUCCESS ) + { + fprintf( stderr, "Could not set LDAP_OPT_X_SASL_NOCANON %s\n", + nocanon ? "on" : "off" ); + tool_exit( ld, EXIT_FAILURE ); + } + } /* otherwise SASL_NOCANON already set to true (e.g. via ~/.ldaprc) */ #endif if( ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &protocol ) !=3D LDAP_OPT_SUCCESS ) --Nq2Wo0NMKNjxTN9z-- --DKU6Jbt7q3WqK7+M Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQEcBAEBAgAGBQJPrw4RAAoJEPe7CdOcrcTZAiUH/RJN9EcOW0HdIr60/vrHQ01r et05+CMhoSM9OQST7KxVz0IOA0tzgIu6y7KHFSirUFOmb8KNyS+u0uI2b4OMINoF 0qVHo3Ed4gYYQtc9TsTPOTNw0/HfRwiLxYHh6Xrmeq0Z9o+rL1wsFoEwVBQTXc4W 3xsYtjoyRFK5KbmMw+iA1zsIWOTD9cs+PqQ0EWDXl2ptMHjhrBOs8/Demi495UA7 iCmrPbD8uv8T5NMCiqIB3yOkyrX2+0wLsLVO/B21qTb8swFOrSFjlACZ4SjvVYmy ZJ6njl7vu0h7vPF12Z+NQW5xMFCYz6wbesrhCNbj0k7eJ5gbD+Zd2tP8VQOS3C4= =9g7U -----END PGP SIGNATURE----- --DKU6Jbt7q3WqK7+M--

1 0

(ITS#7271) Don't clobber SASL_NOCANON in clients/tools/common.c
by wking＠tremily.us 13 May '12

13 May '12

Full_Name: W. Trevor King Version: git commit 22bf5188 OS: Gentoo URL: http://blog.tremily.us/posts/LDAP/tool-nocanon.patch Submission from: (NULL) (72.68.88.202) The ldap.conf SASL_NOCANON configuration option (or LDAPSASL_NOCANON environment variable) should set the default behaviour for OpenLDAP tools such as ldapwhoami. This configuration option should allow users to use the tools without having to use the matching command line option (-N). Unfortunately, the current code sets the option to true/false after only querying the command line option. I'm linking to a patch that looks at the current value of the option first, and if it's true, skips processing the command line option (which would either be a redundant -N keeping the option true, or an absence of -N which implies the user wants to use the configured value (true)). Another approach would be to set the initial value of nocanon to UNINITIALIZED (-1?). Command line arguments could set nocanon to 1 (true, -N) or false (0, --canon?). Then we would only call ldap_set_option if nocanon was not UNINITIALIZED. I can work up a patch using this second approach if people prefer. If so, let me know if you want me to define UNINITIALIZED, or to just use -1. I didn't check, but I would not be surprised if this same clobbering occurred for other command line options.

1 0

ITS#6997
by michael＠stroeder.com 12 May '12

12 May '12

I think it's worth to note that such a setup with this stacking order works with OpenLDAP 2.4.23 (in a more complex variant done by Manuel). So the big question is what was changed in 2.4.24+ which leads to the crash? Ciao, Michael.

1 0

(ITS#7270) Double free in ldap_int_initialize
by fdeweerdt＠cloudmark.com 11 May '12

11 May '12

Full_Name: Frederik Deweerdt Version: current HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/Frederik-Deweerdt-120511.patch Submission from: (NULL) (72.5.239.5) [PATCH] Protect accesses to ldap_int_hostname with a mutex Not protecting the accesses to ldap_int_hostname would lead to a double free with the following trace: #7 0x0000003aca031d10 in abort () from /lib64/libc.so.6 No symbol table info available. #8 0x0000003aca06a99b in __libc_message () from /lib64/libc.so.6 No symbol table info available. #9 0x0000003aca0729d6 in free () from /lib64/libc.so.6 No symbol table info available. #10 0x000000328902333e in ldap_int_initialize () from /usr/lib64/libldap-2.3.so.0 No symbol table info available. #11 0x000000328900c426 in ldap_create () from /usr/lib64/libldap-2.3.so.0 No symbol table info available. #12 0x000000328900ca0d in ldap_init () from /usr/lib64/libldap-2.3.so.0 No symbol table info available. The race in init.c:ldap_int_initialize is as follows: 646 char *name = ldap_int_hostname; 647 648 ldap_int_hostname = ldap_pvt_get_fqdn( name ); 649 650 if ( name != NULL && name != ldap_int_hostname ) { 651 LDAP_FREE( name ); 652 } - T1 and T2 enter ldap_int_initialize, both assign to name the current address of ldap_int_hostname, say 0x1234. - T1 and T2 call ldap_pvt_get_fqdn(), updating ldap_int_hostname to 0x1235 and 0x1236 respectively. - T1 and T2 reach the name != ldap_int_hostname check. In both threads it's false, because 0x1235 != 0x1234 and 0x1236 != 0x1234, respectively. - T1 and T2 both try to free 0x1234 => Crash. --- libraries/libldap/init.c | 2 ++ libraries/libldap/ldap-int.h | 1 + libraries/libldap/util-int.c | 3 +++ 3 files changed, 6 insertions(+), 0 deletions(-)

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