January 2013 - openldap-bugs

by benintechnologies＠yahoo.fr

>>>>Yes, it's a bug. The conversion should have used double-quotes on these >>>>parameters. Will be fixed shortly. ok thanks, I added manually the double-quotes on olcSqlInsEntryStmt in the file olcDatabase={1}sql.ldif, like this : olcSqlInsEntryStmt: "insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from ldap_entries),?,?,?,?)" Now slapd starts, but ldapsearch returns "80 Other (e.g., implementation specific error)". With the old "slapd.conf", ldapsearch works fine. Is there anything else to do when converting slapd.conf to cn=config on a back-sql implementation ? Le 24/01/2013 02:44, hyc(a)symas.com a écrit : > benintechnologies(a)yahoo.fr wrote: >> Hi, >> >> thank you for your reply >> >> I simply took the slapd.conf file adapted to PostgreSQL in the source >> (/openldap-2.4.33/servers/slapd/back-sql/rdbms_depend/pgsql) >> >> In that file, we have : >> olcSqlInsEntryStmt: insert into ldap_entries >> (id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from >> ldap_entries),?,?,?,?) >> >> it works with static configuration (slapd.conf) : I successfully managed >> to insert some data into the postgresql tables >> >> But after having converted it to cn=config (slaptest -f slapd.conf -F >> slapd.d) slapd doesn't start anymore : >> 0ff3f0a<<< dnPrettyNormal:<cn=root,dc=example,dc=com>, >> <cn=root,dc=example,dc=com> >> 50ff3f0a olcSqlInsEntryStmt: value #0:<olcSqlInsEntryStmt> extra cruft >> after<SQL expression>. >> 50ff3f0a config error processing olcDatabase={1}sql,cn=config: >> <olcSqlInsEntryStmt> *extra cruft after<SQL expression>* >> 50ff3f0a send_ldap_result: conn=-1 op=0 p=0 >> 50ff3f0a send_ldap_result: err=19 matched="" text="" >> 50ff3f0a slapd destroy: freeing system resources. >> 50ff3f0a slapd stopped. >> 50ff3f0a connections_destroy: nothing to destroy. >> >> I believe it's a bug, no ?

10 years, 10 months

1
0
0 / 0

(ITS#7500) libldap starttls crashes if invalid GnuTLS cipher suite string

by jouko.orava＠iki.fi

Full_Name: Jouko Orava Version: 2.4.28, 2.4.33 OS: Debian/Ubuntu URL: Submission from: (NULL) (82.181.197.37) If the cipher suite string is unacceptable to GnuTLS, libldap_r-2.4 crashes in ldap_start_tls_s() due to a double free. See https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1103353 for my original bug submission, including a suggested patch, https://launchpadlibrarian.net/129174364/openldap-ciphersuite.patch and a simple example ldapsearch-like program that can be used to test the issue. This bug is not critical, since using a valid GnuTLS cipher suite does work, for example "NORMAL" or "SECURE256". However, trying to use anything more specific is exceedingly difficult -- basically trial and error, due to applications crashing in libldap with an invalid one. The two other TLS implementations in OpenLDAP are not affected by this bug. The double free occurs in openldap/libraries/libldap/tls2.c:ldap_int_tls_init_ctx(), in the ldap_pvt_tls_ctx_free(lo->ldo_tls_ctx); call in the error_exit: path. Because the cipher suite string was unacceptable to GnuTLS, the context is either released by GnuTLS or never properly initialized. The error_exit: path tries to release that context, and causes the C library to abort the program as it detects a double free. Simply commenting the ldap_pvt_tls_ctx_free(lo->ldo_tls_ctx); call in the error_exit: path in openldap/libraries/libldap/tls2.c:ldap_int_tls_init_ctx() masks the issue, but is obviously incorrect (as it affects the two other TLS implementations too). My suggested patch is to use the configured cipher suite string when creating the new TLS context, instead of "NORMAL" as is currently done, in openldap/libraries/libldap/tls_g.c:tlsg_ctx_new(). If there is a problem with the cipher suite priority string, the initial context is torn down, and caught earlier in openldap/libraries/libldap/tls2.c, avoiding the crash. (However, the cipher suite string will be parsed twice.) There seem to be numerous unhandled bug reports in various distributions and applications, including http://www.openldap.org/its/index.cgi/Incoming?id=6939#themesg which are quite tricky to investigate, as the actual bug occurs deep in libldap. Only user checks with a patched libldap will prove whether these are actually caused by this bug or not. It is very easy to assume it is an application bug, due to the symptoms and pretty limited circumstances. Recap: libldap + GnuTLS, application using ldap_start_tls, and any cipher suite string not acceptable to GnuTLS will cause libldap to crash due to a double free.

10 years, 10 months

1
0
0 / 0

Re: (ITS#7499)

by hyc＠symas.com

benintechnologies(a)yahoo.fr wrote: > Hi, > > thank you for your reply > > I simply took the slapd.conf file adapted to PostgreSQL in the source > (/openldap-2.4.33/servers/slapd/back-sql/rdbms_depend/pgsql) > > In that file, we have : > olcSqlInsEntryStmt: insert into ldap_entries > (id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from > ldap_entries),?,?,?,?) > > it works with static configuration (slapd.conf) : I successfully managed > to insert some data into the postgresql tables > > But after having converted it to cn=config (slaptest -f slapd.conf -F > slapd.d) slapd doesn't start anymore : > 0ff3f0a <<< dnPrettyNormal: <cn=root,dc=example,dc=com>, > <cn=root,dc=example,dc=com> > 50ff3f0a olcSqlInsEntryStmt: value #0: <olcSqlInsEntryStmt> extra cruft > after <SQL expression>. > 50ff3f0a config error processing olcDatabase={1}sql,cn=config: > <olcSqlInsEntryStmt> *extra cruft after <SQL expression>* > 50ff3f0a send_ldap_result: conn=-1 op=0 p=0 > 50ff3f0a send_ldap_result: err=19 matched="" text="" > 50ff3f0a slapd destroy: freeing system resources. > 50ff3f0a slapd stopped. > 50ff3f0a connections_destroy: nothing to destroy. > > I believe it's a bug, no ? Yes, it's a bug. The conversion should have used double-quotes on these parameters. Will be fixed shortly. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

10 years, 10 months

1
0
0 / 0

Re: (ITS#7499)

by benintechnologies＠yahoo.fr

Hi, thank you for your reply I simply took the slapd.conf file adapted to PostgreSQL in the source (/openldap-2.4.33/servers/slapd/back-sql/rdbms_depend/pgsql) In that file, we have : olcSqlInsEntryStmt: insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from ldap_entries),?,?,?,?) it works with static configuration (slapd.conf) : I successfully managed to insert some data into the postgresql tables But after having converted it to cn=config (slaptest -f slapd.conf -F slapd.d) slapd doesn't start anymore : 0ff3f0a <<< dnPrettyNormal: <cn=root,dc=example,dc=com>, <cn=root,dc=example,dc=com> 50ff3f0a olcSqlInsEntryStmt: value #0: <olcSqlInsEntryStmt> extra cruft after <SQL expression>. 50ff3f0a config error processing olcDatabase={1}sql,cn=config: <olcSqlInsEntryStmt> *extra cruft after <SQL expression>* 50ff3f0a send_ldap_result: conn=-1 op=0 p=0 50ff3f0a send_ldap_result: err=19 matched="" text="" 50ff3f0a slapd destroy: freeing system resources. 50ff3f0a slapd stopped. 50ff3f0a connections_destroy: nothing to destroy. I believe it's a bug, no ? thanks BT Le 24/01/2013 00:39, quanah(a)zimbra.com a écrit : > --On Wednesday, January 23, 2013 10:58 PM +0000 benintechnologies(a)yahoo.fr > wrote: > >> I just noticed I forgot some infos, so here is the problem again : >> >> If I edit slapd.d/cn=config/olcDatabase={1}sql.ldif and I comment the >> line starting with olcSqlInsEntryStmt, then slapd starts fine. >> >> So what's the right syntax for olcSqlInsEntryStmt ??? > > From the man page: > > > insentry_stmt<SQL expression> > The statement that is used to insert a new entry in table > ldap_entries; see "METAINFORMATION USED" for details. The > default is "INSERT INTO ldap_entries (dn, oc_map_id, parent, > keyval) VALUES (?, ?, ?, ?)". > > --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 > > >

10 years, 10 months

1
0
0 / 0

Re: (ITS#7499)

by quanah＠zimbra.com

--On Wednesday, January 23, 2013 10:58 PM +0000 benintechnologies(a)yahoo.fr wrote: > I just noticed I forgot some infos, so here is the problem again : > > If I edit slapd.d/cn=config/olcDatabase={1}sql.ldif and I comment the > line starting with olcSqlInsEntryStmt, then slapd starts fine. > > So what's the right syntax for olcSqlInsEntryStmt ??? >From the man page: insentry_stmt <SQL expression> The statement that is used to insert a new entry in table ldap_entries; see "METAINFORMATION USED" for details. The default is "INSERT INTO ldap_entries (dn, oc_map_id, parent, keyval) VALUES (?, ?, ?, ?)". --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

10 years, 10 months

1
0
0 / 0

(ITS#7499)

by benintechnologies＠yahoo.fr

I just noticed I forgot some infos, so here is the problem again : Hi, Has anyone out there managed to successfully convert slapd.conf into cn=config with back-sql enabled ? I'm on Debian 6 / OpenLDAP 2.4.33 with back-sql support (./configure --enable-sql) According tohttp://www.openldap.org/software/release/changes.html, back-sql supports dynamic config as of version 2.4.27. So I converted slapd.conf to slapd.d, conversion went well. However, when I start slapd, I get the following message : # /usr/local/libexec/slapd -u openldap -g openldap -d -1 ....... 50ff3f0a<<< dnPrettyNormal:<cn=root,dc=example,dc=com>,<cn=root,dc=example,dc=com> 50ff3f0a olcSqlInsEntryStmt: value #0:<olcSqlInsEntryStmt> extra cruft after<SQL expression>. 50ff3f0a config error processing olcDatabase={1}sql,cn=config: <olcSqlInsEntryStmt> extra cruft after<SQL expression> 50ff3f0a send_ldap_result: conn=-1 op=0 p=0 50ff3f0a send_ldap_result: err=19 matched="" text="" 50ff3f0a slapd destroy: freeing system resources. 50ff3f0a slapd stopped. 50ff3f0a connections_destroy: nothing to destroy. The error message seems to be "extra cruft after<SQL expression>" If I edit slapd.d/cn=config/olcDatabase={1}sql.ldif and I comment the line starting with olcSqlInsEntryStmt, then slapd starts fine. So what's the right syntax for olcSqlInsEntryStmt ??? Thanks Ben

10 years, 10 months

1
0
0 / 0

(ITS#7499) bug on dynamic configuration with back-sql

by benintechnologies＠yahoo.fr

Full_Name: Ben Tech Version: 2.4.33 OS: Debian 6.0.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (41.85.161.126) Hi, I'm on Debian 6 / OpenLDAP 2.4.33 with back-sql. According to http://www.openldap.org/software/release/changes.html, back-sql supports dynamic config as of version 2.4.27. So I converted slapd.conf to slapd.d, conversion went well. However, when I start slapd, I get the following message : # /usr/local/libexec/slapd -u openldap -g openldap -d -1 ....... 50ff3f0a <<< dnPrettyNormal: <cn=root,dc=example,dc=com>, <cn=root,dc=example,dc=com> 50ff3f0a olcSqlInsEntryStmt: value #0: <olcSqlInsEntryStmt> extra cruft after <SQL expression>. 50ff3f0a config error processing olcDatabase={1}sql,cn=config: <olcSqlInsEntryStmt> extra cruft after <SQL expression> 50ff3f0a send_ldap_result: conn=-1 op=0 p=0 50ff3f0a send_ldap_result: err=19 matched="" text="" 50ff3f0a slapd destroy: freeing system resources. 50ff3f0a slapd stopped. 50ff3f0a connections_destroy: nothing to destroy. If I comment that line, the server starts fine # olcSqlInsEntryStmt: insert into ldap_entries (id,dn,oc_map_id,parent,keyval) v alues ((select max(id)+1 from ldap_entries),?,?,?,?)

10 years, 10 months

1
0
0 / 0

Re: (ITS#7495) access filter not correctly validated if assertion attribute not requested

by michael＠stroeder.com

Using extra_attrs would be a possible work-around (tested). Unfortunately it seems to trigger a seg fault in slapo-rwm in my setup which is hard to track down to a certain cause. slapd starts ok but quite soon a seg fault message is written to syslog. Just before the seg fault I see the usual search requests of sssd in the logs... Ciao, Michael.

10 years, 10 months

1
0
0 / 0

Re: (ITS#7498) Openldap syncrepl issue

by quanah＠zimbra.com

--On Wednesday, January 23, 2013 11:59 AM +0000 arunkumar_1123(a)yahoo.com wrote: > Full_Name: Arunkumar shanmugam > Version: 2.4.33 > OS: rhel5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.83.248.32) > > > Hi, > > I've been having issues with syncrepl in openldap. This is plain > syncrepl. I'm not using delta-syncrepl as I run with mirror mode on. MMR has supported delta-syncrepl since 2.4.27. You should use it. --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

10 years, 10 months

1
0
0 / 0

(ITS#7498) Openldap syncrepl issue

by arunkumar_1123＠yahoo.com

Full_Name: Arunkumar shanmugam Version: 2.4.33 OS: rhel5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.83.248.32) Hi, I've been having issues with syncrepl in openldap. This is plain syncrepl. I'm not using delta-syncrepl as I run with mirror mode on. I've noticed that when there are a large number of writes on the writemaster (Typically around 10 per second) the data on the readslave goes out of sync with the master, typically having entries which have been deleted on the master. The contextCSNs on both the readslaves and writemaster match eventually, but the data doesn't. I'm running the readslave in refreshOnly mode with an interval of 1 minute. I'm using a reasonably large DB of size ~ 2 GB. I turned on the sync logs and found lots of entries with "nonpresent_callback" and "syncrepl_del_nonpresent". Tested this and found it occurring in both 2.4.29 and 2.4.33 (Latest as of this time), and with BDB 4.2.36 as the backend. I was wondering if anyone has faced similar issues before, and if there exists a solution to this problem. I will send any relevant configuration and log snippets as needed. Thanks

10 years, 10 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2013