openldap-bugs October 2008

openldap-bugs@openldap.org

36 participants
187 discussions

Re: (ITS#5731) Don't rewrite filter when it is undefined
by ando＠sys-net.it 09 Oct '08

09 Oct '08

The bug is confirmed; the proposed fix is incorrect, since it only addresses the case of a(n undefined) simple filter. A more complete fix (see also ITS#5732) is in HEAD, please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5733) core dump in re24's slapd-ldap(5)
by ando＠sys-net.it 09 Oct '08

09 Oct '08

Full_Name: Pierangelo Masarati Version: re24 OS: Linux x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I had a strange core dump while testing re24 (test039). I'm reporting it in order to be able to investigate it further later. Backtrace follows: (gdb) bt #0 0x00800402 in __kernel_vsyscall () #1 0x00c9ad20 in raise () from /lib/libc.so.6 #2 0x00c9c631 in abort () from /lib/libc.so.6 #3 0x00c9416b in __assert_fail () from /lib/libc.so.6 #4 0x0817c7e5 in ldap_back_conn_delete (li=0x8a9ef30, lc=0x8b55df8) at bind.c:157 #5 0x0817d20a in ldap_back_freeconn (li=0x8a9ef30, lc=0x8b55df8, dolock=0) at bind.c:467 #6 0x0817e8cf in ldap_back_release_conn_lock (li=0x8a9ef30, lcp=0xb4376d10, dolock=1) at bind.c:1144 #7 0x0817cf12 in ldap_back_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:355 #8 0x080fac38 in overlay_op_walk (op=0x8b973e0, rs=0xb4377128, which=op_bind, oi=0x8a82d78, on=0x0) at backover.c:667 #9 0x080faded in over_op_func (op=0x8b973e0, rs=0xb4377128, which=op_bind) at backover.c:719 #10 0x080fae2d in over_op_bind (op=0x8b973e0, rs=0xb4377128) at backover.c:729 #11 0x080a8311 in fe_op_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:383 #12 0x080fac38 in overlay_op_walk (op=0x8b973e0, rs=0xb4377128, which=op_bind, oi=0x8a85090, on=0x0) at backover.c:667 #13 0x080faded in over_op_func (op=0x8b973e0, rs=0xb4377128, which=op_bind) at backover.c:719 #14 0x080fae2d in over_op_bind (op=0x8b973e0, rs=0xb4377128) at backover.c:729 #15 0x080a7aa7 in do_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:205 #16 0x08083c40 in connection_operation (ctx=0xb4377210, arg_v=0x8b973e0) at connection.c:1084 #17 0x0808411a in connection_read_thread (ctx=0xb4377210, argv=0x1f) at connection.c:1210 #18 0x08207d35 in ldap_int_thread_pool_wrapper (xpool=0x8a595b8) at tpool.c:663 #19 0x00deb46b in start_thread () from /lib/libpthread.so.0 #20 0x00d42dbe in clone () from /lib/libc.so.6 (gdb) f 4 #4 0x0817c7e5 in ldap_back_conn_delete (li=0x8a9ef30, lc=0x8b55df8) at bind.c:157 157 assert( !LDAP_BACK_CONN_TAINTED( lc ) ); (gdb) p *lc $1 = {lc_conn = 0xb7e91ba0, lc_ld = 0x8b79160, lc_cred = {bv_len = 0, bv_val = 0x0}, lc_bound_ndn = {bv_len = 68, bv_val = 0x8b2dce8 "cn=james a jones 1,ou=alumni association,ou=people,dc=example,dc=com"}, lc_local_ndn = {bv_len = 68, bv_val = 0x8b37e28 "cn=james a jones 1,ou=alumni association,ou=people,dc=example,dc=com"}, lc_lcflags = 289, lc_refcnt = 0, lc_flags = 4096, lc_create_time = 0, lc_time = 0, lc_q = {tqe_next = 0x0, tqe_prev = 0x0}} (gdb) p /x lc->lc_lcflags $2 = 0x121 The connection is simultaneously cached (0x100) and tainted (0x20); this triggers an assert. Note that (gdb) f 7 #7 0x0817cf12 in ldap_back_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:355 355 ldap_back_release_conn( li, lc ); (gdb) p retrying $4 = LDAP_BACK_RETRYING so apparently no one had a chance to taint the connection (from within this thread). Probably, the assert is too tight. Either tainting and uncaching should occur simultaneously, or the assert should just be relaxed. p.

1 0

(ITS#5732) slapo-rwm can free and reuse a filter in case of error
by ando＠sys-net.it 09 Oct '08

09 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando A fix is coming, along with the right fix to ITS#5731 p.

1 0

Re: (ITS#5731) Don't rewrite filter when it is undefined
by kouk＠noc.uoa.gr 09 Oct '08

09 Oct '08

it turns out that the ftp client uploaded the patch here: ftp://ftp.openldap.org/incoming/kostantinos-koukopoulos-0811009.patch.1

1 0

(ITS#5731) Don't rewrite filter when it is undefined
by kouk＠noc.uoa.gr 09 Oct '08

09 Oct '08

Full_Name: Kostantinos Koukopoulos Version: 2.4.11 OS: Solaris URL: ftp://ftp.openldap.org/incoming/kostantinos-koukopoulos-0811009.patch Submission from: (NULL) (195.134.100.30) When a client provides a search filter which turns out to be undefined (for example if the assertion value doesn't conform to the syntax) then the rwm overlay will try to map the value without knowing if it's normalized or not. In one case this caused an assertion failure. The following is the backtrace when searching with '(entryUUID=123)': Assertion failed: val->bv_len == 16, file schema_init.c, line 2539 t@3 (l@3) signal ABRT (Abort) in _lwp_kill at 0xfe29fc54 0xfe29fc54: _lwp_kill+0x0008: bgeu,a _lwp_kill+0x1c Current function is map_attr_value 426 NULL, NULL, value, &vtmp, NULL ) ) /opt/OpenLdap>where current thread: t@3 [1] _lwp_kill(0x0, 0x6, 0x0, 0xfe2bc000, 0x0, 0x0), at 0xfe29fc54 [2] raise(0x6, 0x0, 0xfcfff168, 0x0, 0x0, 0x0), at 0xfe250c48 [3] abort(0x43, 0xfcfff1f8, 0x43, 0x7efefeff, 0x81010100, 0xff00), at 0xfe236d50 [4] __assert(0x258080, 0x258094, 0x9eb, 0x0, 0x0, 0x0), at 0xfe236ff0 [5] UUIDNormalize(0x4001, 0x0, 0x0, 0x700598, 0xfcfff504, 0x0), at 0xd3d8c =>[6] map_attr_value(dc = 0xfcfff6f8, adp = 0xfcfff5e0, mapped_attr = 0xfcfff5d8, value = 0x700598, mapped_value = 0xfcfff5d0, remap = 0), line 426 in "rwmmap.c" [7] rwm_int_filter_map_rewrite(op = 0x3885d8, dc = 0xfcfff6f8, f = 0x7005ac, fstr = 0xfcfff6f0), line 500 in "rwmmap.c" [8] rwm_filter_map_rewrite(op = 0x3885d8, dc = 0xfcfff6f8, f = 0x7005ac, fstr = 0xfcfff6f0), line 759 in "rwmmap.c" [9] rwm_op_search(op = 0x3885d8, rs = 0xfcfffcb0), line 765 in "rwm.c" [10] overlay_op_walk(0x3885d8, 0xfcfffcb0, 0x2, 0x33cea8, 0x33cfb0, 0xff00), at 0x121b70 [11] 0x121ecc(0x3885d8, 0xfcfffcb0, 0x2, 0xfcfff1e4, 0x2fc920, 0x2902d8), at 0x121ecb [12] 0x121ff8(0x3885d8, 0xfcfffcb0, 0x3886d8, 0x70052c, 0xfcfff9ec, 0x7005bc), at 0x121ff7 [13] do_search(0x388608, 0xfcfffcb0, 0xfcfffca0, 0x1, 0x0, 0x0), at 0x7791c [14] 0x73968(0xfcfffe0c, 0x3885d8, 0xfe2d0400, 0x0, 0x0, 0x0), at 0x73967 [15] 0x7406c(0xfcfffe0c, 0xd, 0x0, 0x0, 0x0, 0x0), at 0x7406b [16] ldap_int_thread_pool_wrapper(xpool = 0x3038f8), line 663 in "tpool.c" In this case the function 'map_attr_value' believes that the value is normalized and tries to de-normalize it. I have included a patch which skips rewriting of a filter when it is undefined.

1 0

Re: (ITS#5369) GSSAPI support for client library
by hyc＠symas.com 09 Oct '08

09 Oct '08

kurt(a)OpenLDAP.org wrote: > I note that the patch appears to be incomplete. No gssapi.c included. Sorry for the tardy review. The patch is also corrupted (both patches actually) and doesn't compile. Note this section of the patch to cyrus.c: +static ber_int_t +sb_sasl_cyrus_encode( + struct sb_sasl_generic_data *p, + unsigned char *buf, + ber_len_t len, + Sockbuf_Buf *dst) +{ + sasl_conn_t *sasl_context = (sasl_conn_t *)p->ops_private; + ber_int_t ret; + unsigned tmpsize = dst->buf_size; + + ret = sasl_encode( sasl_context, buf, len, + (SASL_CONST char **)&dst->buf_base, + &tmpsize ); - assert( sbiod != NULL ); + dst->buf_size = tmpsize; + dst->buf_end = dst->buf_ The last line appears to be truncated in both versions of the diff. > > -- Kurt > > On Feb 14, 2008, at 8:26 PM, kurt(a)openldap.org wrote: > >> You've only included one of the two required statements. You need >> also need to include either a copyright + license statement, or a >> public domain release statement. -- Kurt >> >> On Feb 14, 2008, at 9:12 AM, mimir(a)samba.org wrote: >> >>> --OgqxwSJOaUobr8KG >>> Content-Type: text/plain; charset=iso-8859-2 >>> Content-Disposition: inline >>> Content-Transfer-Encoding: quoted-printable >>> >>> Kurt, >>> >>> On Mon, Feb 11, 2008 at 09:06:19AM -0800, Kurt Zeilenga wrote: >>>>> Full_Name: Rafal Szczesniak >>>>> Version: HEAD >>>>> OS: GNU/Linux >>>>> URL: http://www.samba.org/~mimir/gssapi-head.diff >>>> The submitted patch file does not contain (at the top of the file, >>>> not = >>> =20 >>>> as part of the diffs) the required notices. Please review=20 >>>> http://www.openldap.org/devel/contributing.html and insert >>>> appropriate=20 >>>> notices. Also, please don't include in the diffs derived files >>>> (e.g.,=20 >>>> configure). >>> I've updated the patch file with necessary changes. Please take a >>> look >>> if it's fine now. >>> >>> >>> cheers, >>> --=20 >>> Rafal Szczesniak >>> Samba Team member http://www.samba.org >>> Likewise Software http://www.likewisesoftware.com >>> -- -- 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

SIZELIMIT 0 gives a zero limit
by Fabio Pedretti 08 Oct '08

08 Oct '08

The ldap.conf man page says this: SIZELIMIT <integer> Specifies a size limit to use when performing searches. The number should be a non-negative integer. SIZELIMIT of zero (0) specifies unlimited search size. However it appears that putting "SIZELIMIT 0" in my ldap.conf gives a: # search result search: 2 result: 4 Size limit exceeded To workaround this I put a very large value and it works. I am using openldap 2.4.11 compiled from source on a Slackware 10.0. Is it an openldap bug? Thanks, Fabio

3 3

(ITS#5730) Seg fault with referral entry and search filter (name=some name)
by michael＠stroeder.com 08 Oct '08

08 Oct '08

Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.79.146) HI! if searching with (name=some name) slapd seg faults when processing a referral entry (referral chasing is off). If I delete the entry it works. FWIW: It's back-hdb. Ciao, Michael. ------------------- referral entry ------------------- dn: cn=Refers to ldap.openldap.org,ou=Testing,dc=stroeder,dc=de cn: Refers to ldap.openldap.org createTimestamp: 20050228152803Z creatorsName:: Y249TWljaGFlbCBTdHLDtmRlcixvdT1GcmllbmRzLGRjPXN0cm9lZGVyLGRjP WRl entryCSN: 20071213003755.763469Z#000000#000#000000 entryDN: cn=Refers to ldap.openldap.org,ou=Testing,dc=stroeder,dc=de entryUUID: 150b8f52-1de9-1029-9a2d-eaab50cd2b83 hasSubordinates: FALSE modifiersName:: Y249bWljaGFlbCBzdHLDtmRlcixvdT1mcmllbmRzLGRjPXN0cm9lZGVyLGRj PWRl modifyTimestamp: 20051021165032Z objectClass: extensibleObject objectClass: referral ref: ldap://ldap.openldap.org/dc=openldap,dc=org structuralObjectClass: referral subschemaSubentry: cn=Subschema ------------------- excerpt of syslog ------------------- Oct 8 15:44:05 nb2 slapd[10257]: conn=0 op=5 SRCH base="dc=stroeder,dc=de" scope=2 deref=0 filter="(|(name=*some name*))" Oct 8 15:44:05 nb2 slapd[10257]: conn=0 op=5 SRCH attr=telephonenumber countImmSubordinates labeledurl displayName cn subordinateCount objectClass description countTotSubordinates hasSubordinates msDS-Approx-Immed-Subordinates mobile structuralObjectClass subschemaSubentry mail numSubordinates numAllSubordinates homephone uid Oct 8 15:44:05 nb2 slapd[10257]: <= bdb_substring_candidates: (name) not indexed Oct 8 15:44:10 nb2 kernel: slapd[10260]: segfault at 29 ip 08091834 sp b37da2a0 error 4 in slapd[8048000+1e5000] ------------------- end of console debug output ------------------- ldap_url_parse_ext(ldap://ldap.openldap.org/dc=openldap,dc=org) >>> dnPretty: <dc=openldap,dc=org> => ldap_bv2dn(dc=openldap,dc=org,0) <= ldap_bv2dn(dc=openldap,dc=org)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=openldap,dc=org)=0 <<< dnPretty: <dc=openldap,dc=org> => send_search_reference: dn="(null)" => access_allowed: read access to "(null)" "entry" requested => dn: [5] dc=stroeder,dc=de Segmentation fault

1 0

Re: (ITS#5729) back-hdb segfaults
by quanah＠zimbra.com 07 Oct '08

07 Oct '08

--On Tuesday, October 07, 2008 7:22 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 10/7/2008 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > I have a database using back-hdb, which segfaults while creating a domain > in the database (zimbra style). Works correctly with dn2id.c 1.158 -> 1.159 patch applied. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5729) back-hdb segfaults
by quanah＠zimbra.com 07 Oct '08

07 Oct '08

Full_Name: Quanah Gibson-Mount Version: RE24 10/7/2008 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) I have a database using back-hdb, which segfaults while creating a domain in the database (zimbra style). It's clearly logged here: Tue Oct 7 12:16:26 2008 *** Running as zimbra user: /opt/zimbra/bin/zmprov -l cd freelancer.lab.zimbra.com ERROR: service.FAILURE (system failure: unable to create domain: freelancer.lab.zimbra.com) (cause: javax.naming.ServiceUnavailableException freelancer.lab.zimbra.com:389; socket closed) where the socket got closed during the operation (cd means create domain, and would add a dc=freelancer,dc=lab,dc=zimbra,dc=com object in the database). backtrace has: (gdb) bt #0 0x00002b41adac6839 in hdb_dn2id_add (op=0x1d11bc00, txn=0x1dc6ea20, eip=0x1b765080, e=0x1d01f828) at dn2id.c:617 #1 0x00002b41adab2029 in hdb_add (op=0x1d11bc00, rs=0x434aac70) at add.c:329 #2 0x000000000043cecd in fe_op_add (op=0x1d11bc00, rs=0x434aac70) at add.c:334 #3 0x000000000043c857 in do_add (op=0x1d11bc00, rs=0x434aac70) at add.c:194 #4 0x0000000000433d59 in connection_operation (ctx=0x434aadc0, arg_v=0x1d11bc00) at connection.c:1084 #5 0x0000000000434274 in connection_read_thread (ctx=0x434aadc0, argv=0xc) at connection.c:1210 #6 0x00002b41aa6c3a27 in ldap_int_thread_pool_wrapper (xpool=0x1b75fe00) at tpool.c:663 #7 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #8 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #9 0x0000000000000000 in ?? () (gdb) print *eip $2 = {bei_parent = 0x0, bei_id = 0, bei_lockpad = 0, bei_state = 128, bei_finders = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_rdn = {bv_len = 0, bv_val = 0x0}, bei_modrdns = 0, bei_ckids = 1, bei_dkids = 0, bei_e = 0x1d01f008, bei_kids = 0x1da3c080, bei_kids_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\0' <repeats 39 times>, __align = 0}, bei_lrunext = 0x0, bei_lruprev = 0x0} (gdb) print *eip->bei_e $3 = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x1d13e9d8 ""}, e_nname = {bv_len = 0, bv_val = 0x1d13e9d0 ""}, e_attrs = 0x0, e_ocflags = 288, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x1b765080} --Quanah

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 October 2008