Re: (ITS#5731) Don't rewrite filter when it is undefined
by ando＠sys-net.it
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
-----------------------------------
14 years, 11 months
(ITS#5733) core dump in re24's slapd-ldap(5)
by ando＠sys-net.it
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.
14 years, 11 months
(ITS#5731) Don't rewrite filter when it is undefined
by kouk＠noc.uoa.gr
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.
14 years, 11 months
Re: (ITS#5369) GSSAPI support for client library
by hyc＠symas.com
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/
14 years, 11 months
SIZELIMIT 0 gives a zero limit
by Fabio Pedretti
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
14 years, 11 months
(ITS#5730) Seg fault with referral entry and search filter (name=some name)
by michael＠stroeder.com
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
14 years, 11 months
Re: (ITS#5729) back-hdb segfaults
by quanah＠zimbra.com
--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
14 years, 11 months
(ITS#5729) back-hdb segfaults
by quanah＠zimbra.com
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
14 years, 11 months
