openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Permission denied while opening odbcinst.ini
by Andreas Backman 23 May '08

23 May '08

Hi all! I'm trying to configure an OpenLDAP server with a mySQL server as back-end. This is what happens when i try to start the server. root@ldap:~# slapd -d1 --------- backsql_open_db_handle(): SQLConnect() to database "MySQL" failed. Return code: -1 nativeErrCode=0 SQLengineState=IM002 msg="[unixODBC][Driver Manager]Data source name not found, and no default driver specified" --------- I couldn't find anything wrong with my configuration (see odbc.ini and odbcinst.ini below) so i tried strace: root@ldap:~# strace -o /tmp/out.txt slapd root@ldap:~# grep odbc /tmp/out.txt open("/usr/lib/libodbc.so.1", O_RDONLY) = 3 open("/etc/odbcinst.ini", O_RDONLY) = -1 EACCES (Permission denied) access("/etc/odbc.ini", F_OK) = 0 stat64("/etc/odbc.ini", {st_mode=S_IFREG|0644, st_size=598, ...}) = 0 open("/etc/odbcinst.ini", O_RDONLY) = -1 EACCES (Permission denied) Permissions of odbc.ini and odbcinst.ini root@ldap:/etc# ls odbc*.ini -l -rw-r--r-- 1 root root 598 2008-05-23 08:50 odbc.ini -rw-r--r-- 1 root root 549 2008-05-23 08:49 odbcinst.ini Contents of my odbc.ini and odbcinst.ini: odbc.ini: --------- [MySQL] Description = MySQL test database Driver = MySQL SERVER = 192.168.100.38 USER = root PASSWORD = *** PORT = 3306 DATABASE = kplatsen ---------- odbsinst.ini ---------- [MySQL] Description = MySQL driver for Linux & Win32 Driver = /usr/lib/odbc/libmyodbc3.so Setup = /usr/lib/odbc/libmyodbc3S.so FileUsage = 1 [Default] Driver = /usr/lib/odbc/libmyodbc.so UsageCount = 1 ---------- I've tested the ODBC-connection with: root@ldap:~# isql MySQL and it works... Please help!

1 0

Re: (ITS#5518) Assertion error in io.c:234: ber_flush2
by hyc＠symas.com 23 May '08

23 May '08

paul(a)mad-scientist.us wrote: > Hi all; I just posted a new bug 5525 that describes exactly how this > happens and where the bug is. I came to this conclusion while trying to > find a crasher in Evolution Exchange: I ran it under valgrind to find > the use of freed memory. > > Hopefully this will provide us with a quick fix! Thanks for tracking this down Paul. I think you've nailed it for us, we should be able to patch this pretty soon. -- -- 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#5522) Quarantine causes segmentation fault
by quanah＠zimbra.com 22 May '08

22 May '08

--On Thursday, May 22, 2008 3:11 PM +0000 andrew.graham(a)agustawestland.com wrote: > Full_Name: Drew Graham > Version: 2.4.9 > OS: SUSE 10 > URL: > Submission from: (NULL) (194.169.32.250) > ******************* > > Slapd then exits with Segmentation Fault. Gdb shows... This bug has been patched by Pierangelo in HEAD, and it will be in the 2.3.42 and 2.4.10 releases. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5518) Assertion error in io.c:234: ber_flush2
by paul＠mad-scientist.us 22 May '08

22 May '08

Hi all; I just posted a new bug 5525 that describes exactly how this happens and where the bug is. I came to this conclusion while trying to find a crasher in Evolution Exchange: I ran it under valgrind to find the use of freed memory. Hopefully this will provide us with a quick fix!

1 0

(ITS#5525) libldap causes a core dump due to accessing freed memory
by paul＠mad-scientist.us 22 May '08

22 May '08

Full_Name: Paul Smith Version: 2.4.7 OS: Ubuntu 8.04 URL: Submission from: (NULL) (65.78.30.67) I've been trying to track down a crasher in Evolution's Exchange server backend, and I believe it's a bug in OpenLDAP's libldap. The core manifests as an assert() in io.c:ber_flush2(), but by using valgrind I can see that the real problem is using already-freed memory. You can see various backtraces and valgrind outputs in the Gnome bug tracking system here: http://bugzilla.gnome.org/show_bug.cgi?id=512605 Note that the later stack traces are better as I've installed debugging versions of OpenLDAP so there are better symbols shown. In Evolution we have a loop we use to look up global contacts, which looks like this: for (try = 0; try < 2; try++) { ldap_error = get_gc_connection (gc, op); if (ldap_error != LDAP_SUCCESS) return ldap_error; ldap_error = ldap_search_ext (gc->priv->ldap, base, scope, filter, (char **)attrs, FALSE, NULL, NULL, NULL, 0, &msgid); if (ldap_error == LDAP_SERVER_DOWN) continue; else if (ldap_error != LDAP_SUCCESS) return ldap_error; ldap_error = gc_ldap_result (gc->priv->ldap, op, msgid, msg); if (ldap_error == LDAP_SERVER_DOWN) continue; else if (ldap_error != LDAP_SUCCESS) return ldap_error; return LDAP_SUCCESS; } where get_gc_connection() eventually calls ldap_ntlm_bind() and where gc_ldap_result() calls ldap_result(). When the core happens, the first trip through the for loop here gives an error LDAP_SERVER_DOWN as the return code from ldap_result(). We go back to the top of the loop, and ldap_ntlm_bind() is called. That eventually ends up in ldap_send_initial_request() which invokes ldap_send_server_request() like this: rc = ldap_send_server_request( ld, ber, msgid, NULL, NULL, NULL, NULL ); Inside ldap_send_server_request() we need to find an LDAPConn* structure, but the one passed in is NULL as is the srvlist, so, we use the default connection: if ( lc == NULL ) { if ( srvlist == NULL ) { lc = ld->ld_defconn; Valgrind reports that the very next line, attempting to access lc->lconn_status, is referencing freed memory: if ( lc != NULL && lc->lconn_status == LDAP_CONNST_CONNECTING ) { So, basically, we know that ld->ld_defconn is a non-NULL pointer pointing to already freed memory. This seems like it is a buggy state. How did we get here? In ldap_result() we get into this loop invoking try_read1msg() (I'm removing the mutex locking for readability, even though it IS enabled in my version of libldap): for ( lc = ld->ld_conns; rc == LDAP_MSG_X_KEEP_LOOKING && lc != NULL; ) { if ( lc->lconn_status == LDAP_CONNST_CONNECTED && ldap_is_read_ready( ld, lc->lconn_sb ) ) { rc = try_read1msg( ld, msgid, all, &lc, result ); if ( lc == NULL ) { /* if lc gets free()'d, * there's no guarantee * lc->lconn_next is still * sane; better restart * (ITS#4405) */ lc = ld->ld_conns; /* don't get to next conn! */ break; } } /* next conn */ lc = lc->lconn_next; } Inside try_read1msg() we call "tag = ber_get_next( lc->lconn_sb, &len, ber );" and if the tag we get back is LBER_DEFAULT, then we declare an error and we free the connection and set the pointer to NULL: case LBER_DEFAULT: ld->ld_errno = LDAP_SERVER_DOWN; ldap_free_connection( ld, lc, 1, 0 ); lc = *lcp = NULL; return -1; If you check ldap_free_connection() you'll see that it removes the LDAPConn pointer "lc" from the list of connections before it is freed. BUT! The ldap_free_connection() function never does anything with the ld->ld_defconn pointer, so if the connection we just freed is the one pointed to by ld->ld_defconn, it is now pointing to freed memory. And that causes the problem detected above by valgrind, or causing an assert later on: accessing freed memory. I'm not really sure what the right thing to do here is, or I'd provide a patch. Should we set ld_defconn to NULL? Is that ever a valid state? Or should we just pick another connection from the list (and what if there isn't one?)

1 0

Re: (ITS#5523) BDB 4.7 support
by hyc＠symas.com 22 May '08

22 May '08

hyc(a)symas.com wrote: > Hooray, they've finally got a partitioned lock manager. The lock subsystem has > always been a huge bottleneck in previous releases... (Relatively speaking. Back in OpenLDAP 2.0 we had plenty of other problems, but today most of those are gone, and BerkeleyDB's lock manager is quite conspicuous in current profile results...) -- -- 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#5523) BDB 4.7 support
by hyc＠symas.com 22 May '08

22 May '08

quanah(a)zimbra.com wrote: > --On Thursday, May 22, 2008 7:28 PM +0000 quanah(a)OpenLDAP.org wrote: > > Change log at: > > <http://www.oracle.com/technology/documentation/berkeley-db/db/ref/changelog…> Hooray, they've finally got a partitioned lock manager. The lock subsystem has always been a huge bottleneck in previous releases... The last time I looked at 4.7, the main problem was that they stopped exporting the __lock_getlocker() function. As a quick hack to allow testing the rest of OpenLDAP, I just patched it back in to my copy. The clean approach would be to once again resurrect the long-lived read-transaction code that we dropped a long time back. -- -- 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#5523) BDB 4.7 support
by quanah＠zimbra.com 22 May '08

22 May '08

--On Thursday, May 22, 2008 7:28 PM +0000 quanah(a)OpenLDAP.org wrote: Change log at: <http://www.oracle.com/technology/documentation/berkeley-db/db/ref/changelog…> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5524) Additions to the Security section of the Admin Guide
by andrew.findlay＠skills-1st.co.uk 22 May '08

22 May '08

Full_Name: Andrew Findlay Version: 2.4.9 OS: Linux URL: http://www.skills-1st.co.uk/pub/code/openldap-guide-patch-20080522 Submission from: (NULL) (88.97.25.132) This patch adds text to the Security chapter in the Admin Guide. It describes the password storage schemes, including the {SASL} scheme that triggers pass-through authentication. The latter facility has existed since version 2.0 but has never been mentioned in the docs, so I have included a section with an example of its use.

1 0

(ITS#5523) BDB 4.7 support
by quanah＠OpenLDAP.org 22 May '08

22 May '08

Full_Name: Quanah Gibson-Mount Version: HEAD/RE24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) BDB 4.7 is officially released. We should add support for it.

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