openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

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

07 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

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

05 Mar '07

Full_Name: Gaël Roualland Version: 2.3.34 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.56.0.199) Hello, Upgrading 2.3.33 to 2.3.34 introduced a bug on slapd stop: the daemon segfaults while waiting for threads to stop. This is reproducible on every run, and without any queries processed. Running under gdb on a test system, the following is reported: slapd starting [New Thread 32769 (LWP 22877)] [New Thread 16386 (LWP 22878)] daemon: added 7r listener=(nil) daemon: added 9r listener=0x813df78 [New Thread 32771 (LWP 22879)] daemon: select: listen=9 active_threads=0 tvp=zero Program received signal SIGTERM, Terminated. [Switching to Thread 16384 (LWP 22876)] 0x40070604 in __pthread_sigsuspend () from /lib/libpthread.so.0 (gdb) n Single stepping until exit from function __pthread_wait_for_restart_signal, which has no line number information. daemon: shutdown requested and initiated. daemon: closing 9 slapd shutdown: waiting for 0 threads to terminate Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 32771 (LWP 22879)] 0x401e1aa0 in __check_rhosts_file () from /lib/libc.so.6 (gdb) bt #0 0x401e1aa0 in __check_rhosts_file () from /lib/libc.so.6 #1 0x080c3c36 in ldap_pvt_thread_pool_context_reset (vctx=0xbf5ff94c) at tpool.c:670 #2 0x080c38df in ldap_int_thread_pool_wrapper (xpool=0x814aa78) at tpool.c:494 #3 0x4006de51 in pthread_start_thread () from /lib/libpthread.so.0 #4 0x4006decf in pthread_start_thread_event () from /lib/libpthread.so.0 #5 0x401908aa in clone () from /lib/libc.so.6 (gdb) info threads * 4 Thread 32771 (LWP 22879) 0x401e1aa0 in __check_rhosts_file () from /lib/libc.so.6 3 Thread 16386 (LWP 22878) 0x40070604 in __pthread_sigsuspend () from /lib/libpthread.so.0 2 Thread 32769 (LWP 22877) 0x40187a5a in poll () from /lib/libc.so.6 1 Thread 16384 (LWP 22876) 0x40070604 in __pthread_sigsuspend () from /lib/libpthread.so.0 Looking at ldap_pvt_thread_pool_context_reset, it seems that the test "if ( ctx[i].ltk_key )" should be reversed as "if ( ctx[i].ltk_key != NULL )". This change fixed the bug. Regards,

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