openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#7587) slapd crashes when using pcache overlay applied to a translucent proxy
by amoneger＠cisco.com 09 May '13

09 May '13

Full_Name: Alex Version: 2.4.35 OS: Centos 6.3 (2.6.32-279.el6.x86_64 #1 SMP) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.103.25.102) When using the pcache overlay over a translucent proxy, the slapd daemon crashes after the second LDAP request which misses the cache. For example, the following requests will trigger the issue. The important part is to miss the cache. Assuming nothing is cached for the aaaa and bbbb uid, the following request will trigger the issue (172.16.206.156 being the openldap server): ldapsearch -x -H ldap://172.16.206.156 -b "ou=yyyy,o=xxxx" -LLL "uid=aaaa" uid st ldapsearch -x -H ldap://172.16.206.156 -b "ou=yyyy,o=xxxx" -LLL "uid=bbbb" uid st Whether aaaa and bbbb exist or not does not matter. The following config is used: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/nis.schema moduleload pcache.la moduleload translucent.la database bdb suffix "o=xxxx" #checkpoint 1024 15 rootdn "uid=amoneger,ou=yyyy,o=xxxx" overlay translucent translucent_local uidNumber,gidNumber,homeDirectory,loginShell translucent_strict rootdn "uid=amoneger,ou=yyyy,o=xxxx" uri ldap://zzzz/ #tls ldaps tls_reqcert=demand tls_cacert=/usr/local/etc/openldap/certs/Cisco_ca_chain overlay pcache pcache bdb 10000 1 50 100 pcacheAttrset 0 * pcacheTemplate (uid=) 0 3600 pcacheBind (uid=) 0 1800 sub ou=yyyy,o=xxxx pcacheOffline TRUE pcachePersist TRUE pcacheValidate FALSE directory /var/cache/ldap cachesize 1000 index pcacheQueryid eq The crash seems to be caused by a SIGABRT which is raised by libc free() due to a double free. Here is the traceback: Breakpoint 2, 0x000000312aa33f10 in abort () from /lib64/libc.so.6 (gdb) c Continuing. Program received signal SIGABRT, Aborted. 0x000000312aa328a5 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x000000312aa328a5 in raise () from /lib64/libc.so.6 #1 0x000000312aa34085 in abort () from /lib64/libc.so.6 #2 0x000000312aa707b7 in __libc_message () from /lib64/libc.so.6 #3 0x000000312aa760e6 in malloc_printerr () from /lib64/libc.so.6 #4 0x000000000042391e in do_search (op=0x7f135c000b80, rs=0x7f1366764930) at search.c:263 #5 0x0000000000421449 in connection_operation (ctx=0x7f1366764a90, arg_v=0x7f135c000b80) at connection.c:1155 #6 0x0000000000421c25 in connection_read_thread (ctx=0x7f1366764a90, argv=<value optimized out>) at connection.c:1291 #7 0x00000000005601f0 in ldap_int_thread_pool_wrapper (xpool=0x1f42770) at tpool.c:688 #8 0x000000312b207851 in start_thread () from /lib64/libpthread.so.0 #9 0x000000312aae890d in clone () from /lib64/libc.so.6 I was unable to track back the particular piece of code triggering the double free, but the same pointer p is freed twice by ber_memfree_x() in memory.c: (gdb) delete 3 (gdb) break search.c:263 Breakpoint 4 at 0x5645df: file search.c, line 263. (gdb) c Continuing. Breakpoint 4, do_search (op=0x7fa554002930, rs=0x7fa5623a4930) at search.c:263 263 op->o_tmpfree( op->ors_attrs, op->o_tmpmemctx ); (gdb) s slap_sl_free (ptr=0x1d64a10, ctx=0x7fa554002780) at sl_malloc.c:493 493 { (gdb) s 498 if (!ptr) (gdb) s 501 if (No_sl_malloc || !sh || ptr < sh->sh_base || ptr >= sh->sh_end) { (gdb) s 502 ber_memfree_x(ptr, NULL); (gdb) s 649 } (gdb) s 502 ber_memfree_x(ptr, NULL); (gdb) s ber_memfree_x (p=0x1d64a10, ctx=0x0) at memory.c:127 127 { (gdb) s 128 if( p == NULL ) { (gdb) s 134 if( ber_int_memory_fns == NULL || ctx == NULL ) { (gdb) s 160 } (gdb) s 152 free( p ); (gdb) print p $1 = (void *) 0x1d64a10 (gdb) x/10x p 0x1d64a10: 0x00000001 0x00000000 0x005ffd31 0x00000000 0x1d64a20: 0x00000000 0x00000000 0x00000000 0x00000000 0x1d64a30: 0x00000000 0x00000000 (gdb) c Continuing. [New Thread 0x7fa561994700 (LWP 5823)] Breakpoint 4, do_search (op=0x7fa554002930, rs=0x7fa5623a4930) at search.c:263 263 op->o_tmpfree( op->ors_attrs, op->o_tmpmemctx ); (gdb) s slap_sl_free (ptr=0x1d64a10, ctx=0x7fa554002780) at sl_malloc.c:493 493 { (gdb) s 498 if (!ptr) (gdb) s 501 if (No_sl_malloc || !sh || ptr < sh->sh_base || ptr >= sh->sh_end) { (gdb) s 502 ber_memfree_x(ptr, NULL); (gdb) s 649 } (gdb) s 502 ber_memfree_x(ptr, NULL); (gdb) s ber_memfree_x (p=0x1d64a10, ctx=0x0) at memory.c:127 127 { (gdb) s 128 if( p == NULL ) { (gdb) s 134 if( ber_int_memory_fns == NULL || ctx == NULL ) { (gdb) s 160 } (gdb) s 152 free( p ); (gdb) print P No symbol "P" in current context. (gdb) print p $2 = (void *) 0x1d64a10 (gdb) x/10x p 0x1d64a10: 0x00000000 0x00000000 0x005ffd31 0x00000000 0x1d64a20: 0x00000000 0x00000000 0x00000000 0x00000000 0x1d64a30: 0x00000000 0x00000000 So the same pointer is being freed twice by the 2 connections which miss the cache. I'm unable to figure out who is responsible for that call though, but the same op->ors_attrs is freed by do_search(): if ( op->ors_attrs != NULL ) { op->o_tmpfree( op->ors_attrs, op->o_tmpmemctx ); Parameters seem correct in both cases: (gdb) print op->o_hdr->oh_tmpmfuncs->bmf_free $12 = (BER_MEMFREE_FN *) 0x4733f0 <slap_sl_free> (gdb) print op->o_request.oq_search.rs_attrs $15 = (AttributeName *) 0x1f85a10 The call is done via connection_operation(), but that code part is a bit above my head, so I'm unable to track this further. I thought this could be due to a threading problem, but building slapd with --with-threads=no does not make a difference. I tried uploading the core dump to your ftp server, but seems like there is an issue with ftp.openldap.org [root@centos63 tmp]# ftp ftp.openldap.org Trying 204.152.186.57... Connected to ftp.openldap.org (204.152.186.57). 220- OpenLDAP FTP Service 220 boole.openldap.org FTP server (Version 6.00LS) ready. Name (ftp.openldap.org:cisco): anonymous 331 Guest login ok, send your email address as password. Password: 230- Copyright 1998-2010, The OpenLDAP Foundation, All Rights Reserved. 230- COPYING RESTRICTIONS APPLY, see: 230- ftp://ftp.openldap.org/COPYRIGHT 230- ftp://ftp.openldap.org/LICENSE 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd incoming 250 CWD command successful. ftp> binary 200 Type set to I. ftp> put core-slapd-6-55-55-26548-1368063267 local: core-slapd-6-55-55-26548-1368063267 remote: core-slapd-6-55-55-26548-1368063267 227 Entering Passive Mode (204,152,186,57,242,33) 553 core-slapd-6-55-55-26548-1368063267: No space left on device. Let me know if you need anything. I can provide further debugs or cores. I'm also happy to try things out. Cheers, Alex

1 0

Re: (ITS#7586) MDB tests crash
by hyc＠symas.com 08 May '13

08 May '13

josephg(a)gmail.com wrote: > Full_Name: Joseph Gentle > Version: Gitorius master 2d6aed7 > OS: MacOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (50.1.123.217) > > > Using the latest version of lmdb in https://gitorious.org/mdb/mdb (2d6aed7), I > went into the liblmdb directory, ran make then ran the tests. > > All tests crash with Segmentation Fault. Problem can be reproduced compiling > with gcc or clang, and gcc on linux. This is normal behavior. The tests do no error checking. The tests are not meant to be run blindly, you are expected to read their source code. Ordinarily I only "run" them by single-stepping under gdb so I can examine the library state at each point. Closing this ITS. > env->me_txns is NULL in mdb.c line 1840. > > > Process 63426 stopped > * thread #1: tid = 0x1c03, 0x0000000100001a2d > mtest`mdb_txn_renew0(txn=0x0000000100103de0) + 125 at mdb.c:1840, stop reason = > EXC_BAD_ACCESS (code=1, address=0x28) > frame #0: 0x0000000100001a2d mtest`mdb_txn_renew0(txn=0x0000000100103de0) + > 125 at mdb.c:1840 > 1837 } else { > 1838 LOCK_MUTEX_W(env); > 1839 > -> 1840 txn->mt_txnid = env->me_txns->mti_txnid; > 1841 txn->mt_toggle = txn->mt_txnid & 1; > 1842 txn->mt_next_pgno = env->me_metas[txn->mt_toggle]->mm_last_pg+1; > 1843 txn->mt_txnid++; > (lldb) p env > (MDB_env *) $0 = 0x0000000100103c70 > (lldb) p env->me_txns > (MDB_txninfo *) $1 = 0x0000000000000000 > > -- -- 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#7586) MDB tests crash
by josephg＠gmail.com 08 May '13

08 May '13

Full_Name: Joseph Gentle Version: Gitorius master 2d6aed7 OS: MacOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.1.123.217) Using the latest version of lmdb in https://gitorious.org/mdb/mdb (2d6aed7), I went into the liblmdb directory, ran make then ran the tests. All tests crash with Segmentation Fault. Problem can be reproduced compiling with gcc or clang, and gcc on linux. env->me_txns is NULL in mdb.c line 1840. Process 63426 stopped * thread #1: tid = 0x1c03, 0x0000000100001a2d mtest`mdb_txn_renew0(txn=0x0000000100103de0) + 125 at mdb.c:1840, stop reason = EXC_BAD_ACCESS (code=1, address=0x28) frame #0: 0x0000000100001a2d mtest`mdb_txn_renew0(txn=0x0000000100103de0) + 125 at mdb.c:1840 1837 } else { 1838 LOCK_MUTEX_W(env); 1839 -> 1840 txn->mt_txnid = env->me_txns->mti_txnid; 1841 txn->mt_toggle = txn->mt_txnid & 1; 1842 txn->mt_next_pgno = env->me_metas[txn->mt_toggle]->mm_last_pg+1; 1843 txn->mt_txnid++; (lldb) p env (MDB_env *) $0 = 0x0000000100103c70 (lldb) p env->me_txns (MDB_txninfo *) $1 = 0x0000000000000000

1 0

(ITS#7585) LDAPI with GSSAPI does not work if SASL_NOCANON=on
by sbose＠redhat.com 07 May '13

07 May '13

Full_Name: Sumit Bose Version: 2.4.34 OS: Fedora 18 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.72.5.29) When using LDAPI with GSSAPI and SASL_NOCANON=on I get the following error: # LDAPSASL_NOCANON=on ldapsearch -H 'ldapi://%2fvar%2frun%2fslapd-IPA18-DEVEL.socket' -Y GSSAPI -s base dn SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server krbtgt/SOCKET(a)IPA18.DEVEL not found in Kerberos database) This happens because if SASL_NOCANON=on the "host" part from the LDAP URI is used as SASL host, which just contains a local path in the LDAPI case. The related Fedora issue is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=960222 which also contains a patch for the issue https://bugzilla.redhat.com/attachment.cgi?id=744866 .

1 0

Re: (ITS#7584) slapd ignores loglevel packets, ber and parse.
by fumiyas＠osstech.jp 07 May '13

07 May '13

At Tue, 7 May 2013 10:39:47 GMT, hyc(a)symas.com wrote: > > "slapd -s 'packets,ber,parse'" does not send specified log to syslog. > > slapd ignores "loglevel packets ber parse" in slapd.conf too. > > > > "slapd -d 'packets,ber,parse'" sends specified log to stderr as expected. > > > This works as intended. syslog is too slow to keep up with this output so it's > only provided for debug. Some syslog implementation have "no sync" option (e.g. rsyslog version 3.12.4+ has $ActionFileEnableSync global option and defaults to "off") and is reasonably fast in some situation. Anyway, if this issue is a specification (limitation) of slapd, slapd(8) and slapd.conf(5) manpages should be fixed to describe it. Thanks. -- -- Name: SATOH Fumiyasu @ OSS Technology Corp. (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/ -- PGP Fingerprint: BBE1 A1C9 525A 292E 6729 CDEC ADC2 9DCA 5E1C CBCA

1 0

Re: (ITS#7584) slapd ignores loglevel packets, ber and parse.
by hyc＠symas.com 07 May '13

07 May '13

fumiyas(a)osstech.co.jp wrote: > Full_Name: SATOH Fumiyasu > Version: master > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (240b:10:2640:bf0:222:5fff:fe95:3cda) > > > "slapd -s 'packets,ber,parse'" does not send specified log to syslog. > slapd ignores "loglevel packets ber parse" in slapd.conf too. > > "slapd -d 'packets,ber,parse'" sends specified log to stderr as expected. > This works as intended. syslog is too slow to keep up with this output so it's only provided for debug. -- -- 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#7584) slapd ignores loglevel packets, ber and parse.
by fumiyas＠osstech.co.jp 07 May '13

07 May '13

Full_Name: SATOH Fumiyasu Version: master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (240b:10:2640:bf0:222:5fff:fe95:3cda) "slapd -s 'packets,ber,parse'" does not send specified log to syslog. slapd ignores "loglevel packets ber parse" in slapd.conf too. "slapd -d 'packets,ber,parse'" sends specified log to stderr as expected.

1 0

(ITS#7583) ldap_init_fd() does not work with LDAP_PROTO_UDP
by stefw＠redhat.com 03 May '13

03 May '13

Full_Name: Stef Walter Version: 2.4.35 OS: Fedora 18 URL: http://fedorapeople.org/~stefw/patches/openldap-02/0001-Make-ldap_init_fd-w… Submission from: (NULL) (77.3.95.123) The ldap_init_fd() function does not work with UDP sockets (ie: LDAP_PROTO_UDP passed in as the proto argument). Later uses of the LDAP connection returned fail unceremoniously. This patch fixes the issue: http://fedorapeople.org/~stefw/patches/openldap-02/0001-Make-ldap_init_fd-w… Some test code to exercise and demonstrate the problem. The code does not actually wait for a UDP response, but should exit with a zero return code when successful. http://fedorapeople.org/~stefw/patches/openldap-02/frob-cldap-initfd.c $ gcc -o frob-cldap-initfd -Wall -lldap -llber frob-cldap-initfd.c $ ./frob-cldap-initfd frob-cldap-initfd: ldap_search_ext: -1 The above result occurs before the patch is applied.

1 0

(ITS#7582) Access to uninitialized memory when sending cldap packet
by stefw＠redhat.com 02 May '13

02 May '13

Full_Name: Stef Walter Version: 2.4.35 OS: Fedora 18 URL: http://fedorapeople.org/~stefw/patches/openldap-01/0001-Fix-usage-of-uninit… Submission from: (NULL) (77.3.95.123) When sending a cldap (UDP) packet, like a search request, uninitialized memory is accessed. This shows up in valgrind like this: ==31445== Conditional jump or move depends on uninitialised value(s) ==31445== at 0x36632244E6: ldap_send_server_request (request.c:377) ==31445== by 0x36632247C2: ldap_send_initial_request (request.c:166) ==31445== by 0x36632142F8: ldap_pvt_search (search.c:128) ==31445== by 0x366321454F: ldap_search_ext (search.c:69) ==31445== by 0x400838: main (in /data/projects/openldap/frob-cldap-search) ==31445== This is due to parsing the resulting packet to pull out a requestDN. UDP packets have different BER layout, and therefore the assumptions made when parsing the outgoing request are invalid. It does not seem necessary to track the request DN for UDP packets. The linked patch disables this code path for UDP packets. Patch which fixes the issue: http://fedorapeople.org/~stefw/patches/openldap-01/0001-Fix-usage-of-uninit… Test code for the issue: http://fedorapeople.org/~stefw/patches/openldap-01/frob-cldap-search.c Note that the test code doesn't detect the issue on its own (or do anything useful). Use valgrind to detect the issue: $ gcc -o frob-cldap-search -Wall -lldap -llber frob-cldap-search.c $ valgrind ./frob-cldap-search

1 0

(ITS#7581) adding meta backend in cn=config with ldapadd / ldapmodify
by dcoutadeur＠linagora.com 02 May '13

02 May '13

Full_Name: dcoutadeur Version: 2.4.35 / git OS: openSuse 11.3 x86_64 URL: Submission from: (NULL) (80.67.162.201) I apologize in advance if this is not considered as a bug, but I thought this ticket should help the community anyway... The problem is that it seems impossible to add meta backend in cn=config thanks to ldapadd / ldapmodify clients. I thought the major interest for cn=config was precisely to let administrators change the configuration in a remote way, but maybe new database configuration is an exception ? Here are the technical elements : Content of meta.ldif : dn: olcDatabase={2}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {2}meta olcSuffix: dc=foo,dc=com debug information in slapd, after the command : ldapadd -H "ldap://localhost:389" -D "cn=config" -W -f meta.ldif 518220f1 conn=1002 op=1 ADD dn="olcDatabase={2}meta,cn=config" 518220f1 meta_back_db_open: no targets defined 518220f1 backend_startup_one (type=meta, suffix="dc=foo,dc=com"): bi_db_open failed! (1) 518220f1 olcSuffix: value #0: <olcSuffix> failed startup (dc=foo,dc=com)! However, I can add this entry via slapadd : dn: olcDatabase={2}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {2}meta olcSuffix: dc=foo,dc=com olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcDbOnErr: continue olcDbPseudoRootBindDefer: TRUE olcDbSingleConn: FALSE olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbBindTimeout: 100000 olcDbCancel: abandon olcDbChaseReferrals: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbNretries: 10 olcDbProtocolVersion: 3 olcDbRebindAsUser: FALSE olcDbSessionTrackingRequest: FALSE olcDbTFSupport: no structuralObjectClass: olcMetaConfig entryUUID: cf8afa3a-a284-4ac8-b60e-9431b0807ed4 creatorsName: cn=config createTimestamp: 20130430162302Z entryCSN: 20130430162302.509672Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130430162302Z The fact is I don't have a metatarget configuration, because this is a subentry of olcDatabase={2}meta,cn=config, thus I must add the latter entry first. Also notice that I can't do a slapadd with just the meta configuration. (the ldif above). If I do this, I have an error : slapadd: could not add entry dn="olcDatabase={2}meta,cn=config" (line=1): autocreation of "olcDatabase={-1}frontend" failed I had to make a backup of the full configuration, and then add the meta configuration and import the resulting file.

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