openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by subbarao＠computer.org 03 Feb '11

03 Feb '11

I'd like to add one clarification to this message. I named the attached test script that illustrates the two RESULT messages problem test099-ppolicy-update, per Howard's previous advice not to duplicate existing names. But I just realized that this script relies on the same data files that I previously submitted (slapd-ppolicy.conf, ppolicy.ldif) so when running this script please ensure that those files are in place. Thanks, -Kartik On 02/02/2011 11:50 AM, Kartik Subbarao wrote: >>> Another problem is that bind operations to the consumer server start to > >> return two result messages -- one with the error code of the chained > >> operation, and one with the error code of the bind operation. > > I'm continuing to see this problem, even after I fix the acl-bind and > the 'manage' ACL configuration. See the attached for an updated test > script that illustrates the problem -- I've added a bind with an > incorrect password which should return 49, but instead is returning 0 to > the client. > > The last line of output from the test script is: > > ldap bind operation returned 0, expected 49 > > For the relevant operation in slapd.2.log, I see the following: > > conn=1003 op=0 RESULT tag=103 err=0 text= > [...] > conn=1003 op=0 RESULT tag=97 err=49 text= > > slapd is returning two RESULT messages for the BIND operation. Error 0 > seems to be from the successful chained modification of the > pwdFailureTime attribute, and Error 49 seems to be for the incorrect > password. > > -Kartik

1 0

Re: (ITS#6824) slap_sasl2dn can erroneously set c_authz_backend
by hyc＠symas.com 03 Feb '11

03 Feb '11

masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2.40.0.119) > Submitted by: ando > > > slap_sasl2dn may set c_authz_backend; however, this function can be called > concurrently by multiple operations without mutex protection, and under > erroneous conditions (e.g. while applying the proxied authorization control). > > Not exactly sure about ho to proceed; I assume this should only happen during > SASL bind. Yes. Check if op == op->o_conn->c_sasl_bindop. If true, set c_authz_backend. No mutex protection is required since actual Binds are already serialized. -- -- 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

(ITS#6824) slap_sasl2dn can erroneously set c_authz_backend
by masarati＠aero.polimi.it 03 Feb '11

03 Feb '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.0.119) Submitted by: ando slap_sasl2dn may set c_authz_backend; however, this function can be called concurrently by multiple operations without mutex protection, and under erroneous conditions (e.g. while applying the proxied authorization control). Not exactly sure about ho to proceed; I assume this should only happen during SASL bind. p.

1 0

Fwd: Re: (ITS#6821) ldap modify with ndb backend causes segfault
by hyc＠symas.com 02 Feb '11

02 Feb '11

This is a multi-part message in MIME format. --------------080208070703090506020001 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Confirmation... --------------080208070703090506020001 Content-Type: message/rfc822; name="Re: (ITS#6821) ldap modify with ndb backend causes segfault.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Re: (ITS#6821) ldap modify with ndb backend causes segfault."; filename*1="eml" X-Account-Key: account3 X-Mozilla-Keys: Return-path: <anderson(a)vailsys.com> Envelope-to: hyc(a)symas.com Delivery-date: Wed, 02 Feb 2011 15:44:52 -0800 Received: from chrobd01.vailsys.com ([63.210.102.138] helo=dprobd02.vailsys.com) by lirone.symas.net with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <anderson(a)vailsys.com>) id 1PkmNX-0006Dz-C1 for hyc(a)symas.com; Wed, 02 Feb 2011 15:44:52 -0800 Received: from dpluser01.vail (dpluser01.vail [192.168.129.158]) by dprobd02.vailsys.com (Postfix) with ESMTP id A301E8A5C6C for <hyc(a)symas.com>; Wed, 2 Feb 2011 17:44:49 -0600 (CST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dpluser01.vail (Postfix) with ESMTP id 792731C810E for <hyc(a)symas.com>; Wed, 2 Feb 2011 17:44:49 -0600 (CST) X-Virus-Scanned: amavisd-new at vail Received: from dpluser01.vail ([127.0.0.1]) by localhost (dpluser01.vail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0mdB0KuN0MP for <hyc(a)symas.com>; Wed, 2 Feb 2011 17:44:49 -0600 (CST) Received: from [172.29.10.129] (anderson-vpn.vail [172.29.10.129]) by dpluser01.vail (Postfix) with ESMTP id E068F1C810B for <hyc(a)symas.com>; Wed, 2 Feb 2011 17:44:48 -0600 (CST) Subject: Re: (ITS#6821) ldap modify with ndb backend causes segfault From: Nathanael Anderson <anderson(a)vailsys.com> To: Howard Chu <hyc(a)symas.com> In-Reply-To: <4D49DDA7.90402(a)symas.com> References: <201102012257.p11MvJ92053380(a)boole.openldap.org> <4D49282B.7060603(a)symas.com> <1296657834.10413.0.camel@Yume> <4D49CA7F.7020804(a)symas.com> <1296684181.10413.1.camel@Yume> <4D49D4E9.70606(a)symas.com> <1296685813.10413.3.camel@Yume> <4D49DDA7.90402(a)symas.com> Content-Type: text/plain; charset="UTF-8" Organization: Vail Systems Date: Wed, 02 Feb 2011 17:44:48 -0600 Message-ID: <1296690288.10413.6.camel@Yume> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Spam_score: -1.9 X-Spam_score_int: -18 X-Spam_bar: - The fix commited to cvs resolved this issue. On Wed, 2011-02-02 at 14:41 -0800, Howard Chu wrote: > Nathanael Anderson wrote: > > Let me know if this doesn't have what you need. > > Can you also print *ml and *ml->sml_desc ? It looks like you're performing a > modify on an attribute that back-ndb doesn't already know about. > > > > Program terminated with signal 11, Segmentation fault. > > #0 0x000000000050cce9 in ndb_modify_internal (op=0x12daaf0, > > NA=0x7fa45b342570, text=0x7fa45b343a30, > > textbuf=0x7fa45b3425e0 "\340\345R\001", textlen=256) at > > modify.cpp:397 > > 397 if ( modai[nai]->na_flag& NDB_INFO_INDEX ) > > (gdb) bt > > #0 0x000000000050cce9 in ndb_modify_internal (op=0x12daaf0, > > NA=0x7fa45b342570, text=0x7fa45b343a30, > > textbuf=0x7fa45b3425e0 "\340\345R\001", textlen=256) at > > modify.cpp:397 > > #1 0x000000000050d769 in ndb_back_modify (op=0x12daaf0, > > rs=0x7fa45b343a10) > > at modify.cpp:594 > > #2 0x0000000000466510 in fe_op_modify (op=0x12daaf0, rs=0x7fa45b343a10) > > at modify.c:303 > > #3 0x0000000000465d80 in do_modify (op=0x12daaf0, rs=0x7fa45b343a10) > > at modify.c:177 > > #4 0x00000000004452b8 in connection_operation (ctx=0x7fa45b343b50, > > arg_v=0x12daaf0) at connection.c:1113 > > #5 0x0000000000445856 in connection_read_thread (ctx=0x7fa45b343b50, > > argv=0xe) > > at connection.c:1249 > > #6 0x00007fa4602b9e09 in ldap_int_thread_pool_wrapper (xpool=0x11b83f0) > > at tpool.c:685 > > #7 0x00007fa45eab29ca in start_thread () from /lib/libpthread.so.0 > > #8 0x00007fa45d27a70d in clone () from /lib/libc.so.6 > > #9 0x0000000000000000 in ?? () > > > > > > On Wed, 2011-02-02 at 14:04 -0800, Howard Chu wrote: > >> Nathanael Anderson wrote: > >>> I tried to build openldap without compilier optimiations, but its > >>> ignoring CFLAGS and CXXFLAGS when i set them to > >>> > >>> export CFLAGS = "-g -ggdb" > >>> > >>> export CXXFLAGS=$CFLAGS > >> > >> use > >> make AC_CFLAGS=-g > >> > >>> and still passes -O2, doesn't pass -ggdb. what am I missing to disable > >>> optimizations when building. > >>> > >>> On Wed, 2011-02-02 at 13:19 -0800, Howard Chu wrote: > >>>> Unfortunately this trace is nonsensical because of the compiler optimizations. > >>>> It shows a call path that simply doesn't exist (connection_read -> syslog -> > >>>> connection_operation). > >>>> > >>>> Please try again with all optimization turned off in your build. > >>>> > >>>> Nathanael Anderson wrote: > >>>>> Program terminated with signal 11, Segmentation fault. > >>>>> #0 0x00000000004c4a2d in ndb_modify_internal (op=0x1ae74c0, NA=0x0, > >>>>> text=<value optimized out>, textbuf=<value optimized out>, > >>>>> textlen=<value optimized out>) > >>>>> at modify.cpp:416 > >>>>> 416 for ( i=0; i<nai; i++ ) { > >>>>> (gdb) bt > >>>>> #0 0x00000000004c4a2d in ndb_modify_internal (op=0x1ae74c0, NA=0x0, > >>>>> text=<value optimized out>, textbuf=<value optimized out>, > >>>>> textlen=<value optimized out>) > >>>>> at modify.cpp:416 > >>>>> #1 0x00000000004c5605 in ndb_back_modify (op=0x1bcd940, > >>>>> rs=0x7f1d3a7bd9f0) at modify.cpp:646 > >>>>> #2 0x0000000000450141 in fe_op_modify (op=0x1bcd940, rs=0x7f1d3a7bd9f0) > >>>>> at modify.c:211 > >>>>> #3 0x0000000000450a96 in do_modify (op=0x1bcd940, rs=0x7f1d3a7bd9f0) at > >>>>> modify.c:142 > >>>>> #4 0x0000000000437b78 in connection_operation (ctx=0x7f1d3a7bdb50, > >>>>> arg_v=<value optimized out>) at connection.c:1129 > >>>>> #5 0x000000000043876d in syslog (ctx=<value optimized out>, argv=<value > >>>>> optimized out>) at /usr/include/bits/syslog.h:32 > >>>>> #6 connection_read (ctx=<value optimized out>, argv=<value optimized > >>>>> out>) at connection.c:1429 > >>>>> #7 connection_read_thread (ctx=<value optimized out>, argv=<value > >>>>> optimized out>) at connection.c:1242 > >>>>> #8 0x00007f1d3ef30b48 in ldap_int_thread_pool_wrapper (xpool=<value > >>>>> optimized out>) at tpool.c:685 > >>>>> #9 0x00007f1d3d72b9ca in start_thread () from /lib/libpthread.so.0 > >>>>> #10 0x00007f1d3bef370d in clone () from /lib/libc.so.6 > >>>>> #11 0x0000000000000000 in ?? () > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Wed, 2011-02-02 at 01:47 -0800, Howard Chu wrote: > >>>>>> This trace has no line numbers, so it's not very useful. Make sure you > >>>>>> use an > >>>>>> unstripped binary. > >>>>>> > >>>>>>> Program terminated with signal 11, Segmentation fault. > >>>>>>> #0 0x00000000004c491d in ndb_modify_internal () > >>>>>>> (gdb) bt > >>>>>>> #0 0x00000000004c491d in ndb_modify_internal () > >>>>>>> #1 0x00000000004c5515 in ndb_back_modify () > >>>>>>> #2 0x0000000000450001 in fe_op_modify () > >>>>>>> #3 0x0000000000450956 in do_modify () > >>>>>>> #4 0x0000000000437ad8 in ?? () > >>>>>>> #5 0x00000000004386cd in ?? () > >>>>>>> #6 0x00007ff79450ab08 in ldap_int_thread_pool_wrapper (xpool=<value > >>>>>> optimized > >>>>>>> out>) at tpool.c:685 > >>>>>>> #7 0x00007ff792d059ca in start_thread () from /lib/libpthread.so.0 > >>>>>>> #8 0x00007ff7914cd70d in clone () from /lib/libc.so.6 > >>>>>>> #9 0x0000000000000000 in ?? () > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > > > > > > > > --------------080208070703090506020001--

1 0

Re: (ITS#6821) ldap modify with ndb backend causes segfault
by anderson＠vailsys.com 02 Feb '11

02 Feb '11

#0 0x000000000050cce9 in ndb_modify_internal (op=0x12daaf0, NA=0x7fa45b342570, text=0x7fa45b343a30, textbuf=0x7fa45b3425e0 "\340\345R\001", textlen=256) at modify.cpp:397 397 if ( modai[nai]->na_flag & NDB_INFO_INDEX ) (gdb) bt #0 0x000000000050cce9 in ndb_modify_internal (op=0x12daaf0, NA=0x7fa45b342570, text=0x7fa45b343a30, textbuf=0x7fa45b3425e0 "\340\345R\001", textlen=256) at modify.cpp:397 #1 0x000000000050d769 in ndb_back_modify (op=0x12daaf0, rs=0x7fa45b343a10) at modify.cpp:594 #2 0x0000000000466510 in fe_op_modify (op=0x12daaf0, rs=0x7fa45b343a10) at modify.c:303 #3 0x0000000000465d80 in do_modify (op=0x12daaf0, rs=0x7fa45b343a10) at modify.c:177 #4 0x00000000004452b8 in connection_operation (ctx=0x7fa45b343b50, arg_v=0x12daaf0) at connection.c:1113 #5 0x0000000000445856 in connection_read_thread (ctx=0x7fa45b343b50, argv=0xe) at connection.c:1249 #6 0x00007fa4602b9e09 in ldap_int_thread_pool_wrapper (xpool=0x11b83f0) at tpool.c:685 #7 0x00007fa45eab29ca in start_thread () from /lib/libpthread.so.0 #8 0x00007fa45d27a70d in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () (gdb) print *ml $1 = {sml_mod = {sm_desc = 0x154d6c0, sm_values = 0x15514c0, sm_nvalues = 0x12daeb0, sm_numvals = 1, sm_op = 2, sm_flags = 0, sm_type = {bv_len = 13, bv_val = 0x15513a6 "homedirectory"}}, sml_next = 0x154d280} (gdb) print *ml->sml_desc There is no member named sml_desc. (gdb) print *ml->sml_mod.sm_desc $2 = {ad_next = 0x0, ad_type = 0x1222de0, ad_cname = {bv_len = 13, bv_val = 0x1222d00 "homeDirectory"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0}

1 0

Re: (ITS#6532) Support for common orderingMatching rules in extensible match filters
by h.b.furuseth＠usit.uio.no 02 Feb '11

02 Feb '11

Also added support for CSNOrderingMatch extensible filters. UUIDOrderingMatch awaits checking what's going on with it. -- Hallvard

1 0

Re: (ITS#6821) ldap modify with ndb backend causes segfault
by hyc＠symas.com 02 Feb '11

02 Feb '11

Unfortunately this trace is nonsensical because of the compiler optimizations. It shows a call path that simply doesn't exist (connection_read -> syslog -> connection_operation). Please try again with all optimization turned off in your build. Nathanael Anderson wrote: > Program terminated with signal 11, Segmentation fault. > #0 0x00000000004c4a2d in ndb_modify_internal (op=0x1ae74c0, NA=0x0, > text=<value optimized out>, textbuf=<value optimized out>, > textlen=<value optimized out>) > at modify.cpp:416 > 416 for ( i=0; i<nai; i++ ) { > (gdb) bt > #0 0x00000000004c4a2d in ndb_modify_internal (op=0x1ae74c0, NA=0x0, > text=<value optimized out>, textbuf=<value optimized out>, > textlen=<value optimized out>) > at modify.cpp:416 > #1 0x00000000004c5605 in ndb_back_modify (op=0x1bcd940, > rs=0x7f1d3a7bd9f0) at modify.cpp:646 > #2 0x0000000000450141 in fe_op_modify (op=0x1bcd940, rs=0x7f1d3a7bd9f0) > at modify.c:211 > #3 0x0000000000450a96 in do_modify (op=0x1bcd940, rs=0x7f1d3a7bd9f0) at > modify.c:142 > #4 0x0000000000437b78 in connection_operation (ctx=0x7f1d3a7bdb50, > arg_v=<value optimized out>) at connection.c:1129 > #5 0x000000000043876d in syslog (ctx=<value optimized out>, argv=<value > optimized out>) at /usr/include/bits/syslog.h:32 > #6 connection_read (ctx=<value optimized out>, argv=<value optimized > out>) at connection.c:1429 > #7 connection_read_thread (ctx=<value optimized out>, argv=<value > optimized out>) at connection.c:1242 > #8 0x00007f1d3ef30b48 in ldap_int_thread_pool_wrapper (xpool=<value > optimized out>) at tpool.c:685 > #9 0x00007f1d3d72b9ca in start_thread () from /lib/libpthread.so.0 > #10 0x00007f1d3bef370d in clone () from /lib/libc.so.6 > #11 0x0000000000000000 in ?? () > > > > > On Wed, 2011-02-02 at 01:47 -0800, Howard Chu wrote: >> This trace has no line numbers, so it's not very useful. Make sure you >> use an >> unstripped binary. >> >>> Program terminated with signal 11, Segmentation fault. >>> #0 0x00000000004c491d in ndb_modify_internal () >>> (gdb) bt >>> #0 0x00000000004c491d in ndb_modify_internal () >>> #1 0x00000000004c5515 in ndb_back_modify () >>> #2 0x0000000000450001 in fe_op_modify () >>> #3 0x0000000000450956 in do_modify () >>> #4 0x0000000000437ad8 in ?? () >>> #5 0x00000000004386cd in ?? () >>> #6 0x00007ff79450ab08 in ldap_int_thread_pool_wrapper (xpool=<value >> optimized >>> out>) at tpool.c:685 >>> #7 0x00007ff792d059ca in start_thread () from /lib/libpthread.so.0 >>> #8 0x00007ff7914cd70d in clone () from /lib/libc.so.6 >>> #9 0x0000000000000000 in ?? () > > -- -- 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

Re: (ITS#6823) unknown attrs in pcache attrsets may be useful
by masarati＠aero.polimi.it 02 Feb '11

02 Feb '11

> masarati(a)aero.polimi.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2.40.14.92) >> Submitted by: ando >> >> >> Currently attributes in pcache attrsets must be defined. As far as I >> recall >> this was introduced to catch misconfigurations (e.g. a typo would have >> silently >> resulted in erroneous caching). However, one may wish to cache attrs >> whose >> schema is not known. I've modified pcache to allow undef:attrname in >> attrsets, >> so the administrator needs to know what he's doing. The "undef:" is >> stripped >> during parsing, but slapd will not complain and the administrator. > > I think this is a mistake. Anything slapd handles must have a defined > schema. > Probably the recent patches for back-ldap to support undefined filters are > also a mistake. We have already documented that schema must be provided in > order to get proper functioning of e.g. back-ldap. There is no reason to > relax > this requirement since one can always obtain the relevant schema from the > target server. I understand your point and I fully agree with it. However, we have been swaying between these two extremes many times, and there's always some good reason to need strictness as well as (some) relaxation. I think this ITS' solution approach represents a reasonable trade-off: we require schema to be defined, but we accept that it's not provided the admin knows what he's doing. I'm prepared to back this feature out as soon as it creates harm. p.

1 0

Re: (ITS#6823) unknown attrs in pcache attrsets may be useful
by hyc＠symas.com 02 Feb '11

02 Feb '11

masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2.40.14.92) > Submitted by: ando > > > Currently attributes in pcache attrsets must be defined. As far as I recall > this was introduced to catch misconfigurations (e.g. a typo would have silently > resulted in erroneous caching). However, one may wish to cache attrs whose > schema is not known. I've modified pcache to allow undef:attrname in attrsets, > so the administrator needs to know what he's doing. The "undef:" is stripped > during parsing, but slapd will not complain and the administrator. I think this is a mistake. Anything slapd handles must have a defined schema. Probably the recent patches for back-ldap to support undefined filters are also a mistake. We have already documented that schema must be provided in order to get proper functioning of e.g. back-ldap. There is no reason to relax this requirement since one can always obtain the relevant schema from the target server. -- -- 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

(ITS#6823) unknown attrs in pcache attrsets may be useful
by masarati＠aero.polimi.it 02 Feb '11

02 Feb '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.14.92) Submitted by: ando Currently attributes in pcache attrsets must be defined. As far as I recall this was introduced to catch misconfigurations (e.g. a typo would have silently resulted in erroneous caching). However, one may wish to cache attrs whose schema is not known. I've modified pcache to allow undef:attrname in attrsets, so the administrator needs to know what he's doing. The "undef:" is stripped during parsing, but slapd will not complain and the administrator. p.

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