openldap-bugs March 2007

openldap-bugs@openldap.org

42 participants
123 discussions

(ITS#4858) sasl_client_init Problem
by m.birkenkamp＠e-fact-gmbh.de 07 Mar '07

07 Mar '07

Full_Name: Marcel Birkenkamp Version: 2.1.22 OS: HP UX 11.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.63.24.153) Hi, i have a Problem, i've implemented a c program using OpenLDAP to connect to an ActiveDirectory for uservalidation, the Problem is that whenever i use one of the OpenLDAP functions (i.e. ldap_init, ldap_initialize) i get the following error: "/usr/lib/dld.sl: Unresolvable symbol: sasl_client_init (code) from /opt/iexpress/openldap/lib/libldap.sl - IOT trap". I've reinstalled OpenLDAP but the Problem persists. Does anyone have an idea what might be causing this or how i can find out where this Problem originates? thanks in advance Marcel

1 0

(ITS#4857) Subtree accesslog support
by quanah＠stanford.edu 06 Mar '07

06 Mar '07

Full_Name: Quanah Gibson-Mount Version: 2.3/2.4/HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) I was looking at adding access log configurations to my main database that would log operations based on subtree. For example, I'd like to have all operations on "cn=accounts,dc=stanford,dc=edu" go into one accesslog, and operations on "cn=people,dc=stanford,dc=edu" go into another accesslog. My root is "dc=stanford,dc=edu". There doesn't seem to be a way with the way accesslog is currently designed to do this. I believe it would be a useful feature. --Quanah

1 0

Re: slapd segfaults with certain ACL's (ITS#4854)
by ando＠sys-net.it 06 Mar '07

06 Mar '07

hjensen(a)gmx.de wrote: > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 16384 (LWP 16160)] > 0x4043e049 in free () from /lib/libc.so.6 > (gdb) bt > #0 0x4043e049 in free () from /lib/libc.so.6 > #1 0x40069ef8 in ber_memfree_x () from /usr/lib/liblber-2.3.so.0 > #2 0x0809d4b6 in ch_free () > #3 0x080be84d in str2anlist () > #4 0x080ab33e in parse_acl () > #5 0x08070c5c in config_generic () > #6 0x0807b0f6 in config_set_vals () > #7 0x0807cdd9 in read_config_file () > #8 0x08075d1d in config_include () > #9 0x0807b0f6 in config_set_vals () > #10 0x0807cdd9 in read_config_file () > #11 0x0807667b in read_config () > #12 0x0806ffce in main () OK, then it should be fixed; you can pull servers/slapd/ad.c from the CVS under the OPENLDAP_REL_ENG_2_3 tag and rebuild. Note that this confirms that your schema is missing either or both the offending objectClasses mozillaAbPersonAlpha, evolutionPerson. Please test and feedback. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: slapd segfaults with certain ACL's (ITS#4854)
by hjensen＠gmx.de 06 Mar '07

06 Mar '07

Hello, here the additional information: configure command line: ./configure --prefix=/usr \ --sysconfdir=/etc \ --libexecdir=/usr/sbin \ --localstatedir=/var/openldap \ --disable-nls \ --enable-debug \ --enable-syslog \ --with-threads \ --with-tls \ --with-cyrus-sasl \ --enable-spasswd \ --enable-dynamic \ --enable-ipv6 \ --enable-modules \ --enable-crypt \ --enable-rewrite \ --enable-ldbm \ --enable-ldbm-api=berkeley \ --enable-ldbm-type=btree \ --enable-bdb \ --enable-hdb \ --enable-ldap \ --enable-meta \ --enable-monitor \ --enable-dnssrv \ --enable-null \ --enable-perl \ --with-dyngroup \ --with-proxycache \ --enable-wrappers \ --enable-slurpd \ --enable-aci \ --enable-shared Backtrace of the segfault: (gdb) run Starting program: /ports/openldap/work/src/openldap-2.3.34/servers/slapd/.libs/slapd [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 16160)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 16160)] 0x4043e049 in free () from /lib/libc.so.6 (gdb) bt #0 0x4043e049 in free () from /lib/libc.so.6 #1 0x40069ef8 in ber_memfree_x () from /usr/lib/liblber-2.3.so.0 #2 0x0809d4b6 in ch_free () #3 0x080be84d in str2anlist () #4 0x080ab33e in parse_acl () #5 0x08070c5c in config_generic () #6 0x0807b0f6 in config_set_vals () #7 0x0807cdd9 in read_config_file () #8 0x08075d1d in config_include () #9 0x0807b0f6 in config_set_vals () #10 0x0807cdd9 in read_config_file () #11 0x0807667b in read_config () #12 0x0806ffce in main () Regards, Henry

1 0

Re: (ITS#4856) Back-SQL + Subtree search hits 'assert(0)'
by ando＠sys-net.it 05 Mar '07

05 Mar '07

Kevin Vargo wrote: > Hi Pierangelo, Please keep replies in CC to the ITS system. > Thanks for the quick response. I just want to make sure I understand: you're saying that removing the assertion (as I did) is the correct solution? Well, removing the assert(0) prevents the crash; the right fix is to disallow the "subtree shortcut" in slapd.conf (slapd-sql(5)), which causes the extra filtering on the DN to take place, so no false hits show up. But yes, the assert(0) was overparanoid, and I removed it from the code. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4856) Back-SQL + Subtree search hits 'assert(0)'
by ando＠sys-net.it 05 Mar '07

05 Mar '07

vargok(a)yahoo.com wrote: > Full_Name: K Vargo > Version: 2.3.32 > OS: Linux (RH-EL4) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.237.233.195) > > > Given a Base-DN, Subtree scoped ldapsearch, while the database contains > non-DN-matching items runs up against the 'assert(0)' in Back-SQL/search.c > +2186. > > Based on how the selection works, there doesn't appear to be a reason for the > assertion. The FIXME does not indicate WHY the dnIsSuffix should never fail: > the comparison in dnIsSuffix tries to compare incompatible-dn records and fails > -- as it should. > > Removing the assertion provides for the expected behavior in my simple case. > Basically, it appears that a Base-DN is not being pre-filtered by the Back-SQL > selection search, so it needs to be filtered by the dnIsSuffix check. > > While I could certainly see that my metadata is not correct (stock metadata from > 2.3 + changes from 200511/msg00504.html) I'm not sure an assert(0) is > appropriate. > > Additionally, there's no indication that back-sql can't support data with > multiple DNs. Actually, your assumption is partially incorrect, since back-sql doesn't do prefiltering of the DN if the search is rooted at the database's suffix (it's called the "subtree shortcut") unless you tell it otherwise, by using "use_subtree_shortcut no" (the docs state it's the default; this is wrong). I admit assert(0) there is a bit too strong, but I believe it was put there to catch this type of problems. I think the "right" solution, apart from fixing the docs, consists in removing the assertion. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4856) Back-SQL + Subtree search hits 'assert(0)'
by vargok＠yahoo.com 05 Mar '07

05 Mar '07

Full_Name: K Vargo Version: 2.3.32 OS: Linux (RH-EL4) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.237.233.195) Given a Base-DN, Subtree scoped ldapsearch, while the database contains non-DN-matching items runs up against the 'assert(0)' in Back-SQL/search.c +2186. Based on how the selection works, there doesn't appear to be a reason for the assertion. The FIXME does not indicate WHY the dnIsSuffix should never fail: the comparison in dnIsSuffix tries to compare incompatible-dn records and fails -- as it should. Removing the assertion provides for the expected behavior in my simple case. Basically, it appears that a Base-DN is not being pre-filtered by the Back-SQL selection search, so it needs to be filtered by the dnIsSuffix check. While I could certainly see that my metadata is not correct (stock metadata from 2.3 + changes from 200511/msg00504.html) I'm not sure an assert(0) is appropriate. Additionally, there's no indication that back-sql can't support data with multiple DNs.

1 0

Re: (ITS#4855) slapd crash on exit (tpool)
by gael.roualland＠oleane.net 05 Mar '07

05 Mar '07

Pierangelo Masarati a écrit : > gael.roualland(a)oleane.net wrote: >> Full_Name: Gaël Roualland >> Version: 2.3.34 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (213.56.0.199) > > Good catch. This is a re23-only bug; fixed, will appear in next > release. Please test re23 out of the CVS, if you can. It works fine with the version from CVS. Thanks, -- Gaël Roualland -+- gael.roualland(a)oleane.net

1 0

Re: (ITS#4855) slapd crash on exit (tpool)
by ando＠sys-net.it 05 Mar '07

05 Mar '07

gael.roualland(a)oleane.net wrote: > Full_Name: Gaël Roualland > Version: 2.3.34 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.56.0.199) Good catch. This is a re23-only bug; fixed, will appear in next release. Please test re23 out of the CVS, if you can. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4855) slapd crash on exit (tpool)
by gael.roualland＠oleane.net 05 Mar '07

05 Mar '07

Erratum : the changed line is "( ctx[i].ltk_key == NULL )" and not "( ctx[i].ltk_key != NULL )" which is the same as the release... -- Gaël Roualland -+- gael.roualland(a)oleane.net

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2007