- openldap-bugs - openldap.org

ITS#6826 Apache htpasswd MD5 support
by hyc＠symas.com 05 Feb '11

05 Feb '11

New password hash mechanisms should simply be implemented as standalone modules for inclusion under contrib/slapd-modules. See contrib/slapd-modules/passwd for existing examples. -- -- 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#6238) contrib: lastbind overlay to record timestamp of last successful bind
by hyc＠symas.com 05 Feb '11

05 Feb '11

michael(a)stroeder.com wrote: > Could we have this overlay in contrib/ shipped with 2.4.24? > That would be really nice. > > I've tested it with 2.4.23 and it still seems to work. Committed with changes in HEAD. -- -- 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#6826) Apache htpasswd MD5 support [patch]
by djpohly＠gmail.com 04 Feb '11

04 Feb '11

Full_Name: Devin J. Pohly Version: 2.4.23 OS: Linux URL: http://openldap.pastebin.com/t4jWaUfe Submission from: (NULL) (75.102.64.250) == Proposed enhancement == When migrating an Apache .htpasswd-based system to LDAP authentication, it would be nice if the password hashes would migrate cleanly. .htpasswd uses three hash formats: {SHA}, {CRYPT}, and "apr1", an MD5-based variant not supported by OpenLDAP. If OpenLDAP had a hash which was equivalent to (i.e. could be freely converted to and from) Apache's apr1, conversion would be easy. == Solution == If you're willing to have OpenLDAP depend on APR-Util, it would be trivial to use the apr_md5_encode and apr_password_validate functions to support this hash. If not, I created a patch [1] which implements the apr1 hash. The algorithm is the same as PHK MD5 with a different magic number. I derived the code from the PHK source which is freely usable under the Beer-ware license (see patch). This patch adds an {APR1} hash type to OpenLDAP when configured with --enable-apr1. [1] http://openldap.pastebin.com/t4jWaUfe (Note: patch is against release, but passwd.c has not changed significantly in HEAD.) == Discussion == The patch has held up to my (limited) testing, but it could probably be written better. It might be useful to put the algorithm into its own function or file, since it's fairly complex and used in both the chk_apr1 and hash_apr1 functions. It might also be useful to specify the magic number to the functions; then we would get PHK $1$ hashes for free. Apache selects salts with 48 bits of randomness but treats them as 64-bit salts. The lines referring to apr64[] replicate this behavior for backward compatibility (so {APR1} hashes generated by slappasswd can be converted to .htpasswd). If you're not concerned about being able to convert in the opposite direction, that code can be removed, and OpenLDAP can then use any size salt. == Tools == The hashes are stored in OpenLDAP's base64(hash + salt) format for consistency. I put together a couple pipe-able scripts for converting between Apache's $apr1$ and OpenLDAP {APR1} formats: Apache to OpenLDAP: http://openldap.pastebin.com/0SSbzjhH OpenLDAP to Apache: http://openldap.pastebin.com/rfLBRASr

1 0

Re: (ITS#6810) slapd crashes writing to bdb backend
by bruno.haleblian＠gmail.com 04 Feb '11

04 Feb '11

--0016e644d08a200ed6049b76654a Content-Type: text/plain; charset=ISO-8859-1 Hi Quanah, Anyway, exactly same core is dumped with BDB 4.8,.30 downloaded from Oracle... I'm likely to misconfig my replication but can't figure out for now .... Regards, Bruno -- --0016e644d08a200ed6049b76654a Content-Type: text/html; charset=ISO-8859-1 Hi Quanah,<br><br>Anyway, exactly same core is dumped with BDB 4.8,.30 downloaded from Oracle...<br clear="all">I'm likely to misconfig my replication but can't figure out for now ....<br><br>Regards, Bruno<br>--<br> --0016e644d08a200ed6049b76654a--

1 0

Re: (ITS#6825) unique_uri filter reaching beyond its intended target
by subbarao＠computer.org 04 Feb '11

04 Feb '11

On 02/03/2011 06:24 PM, Howard Chu wrote: > Looks like a bug, the filter check is only implemented for Add > operations, not for Modify or ModDN. > > In the meantime, as a workaround you should simply use a more fully > qualified URI. Restrict the URI to the ou containing your posixGroup > entries. Since user names and group names are separate name spaces in > POSIX, you cannot store them both in the same branches of a DIT anyway. The workaround works, thanks for the quick response! There will be other uniqueness scenarios where it will be good to have the full functionality, but for this situation we should be fine. Regards, -Kartik

1 0

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

04 Feb '11

On 02/03/2011 06:27 PM, Howard Chu wrote: > Kartik Subbarao wrote: >> 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. > > That's fine. I've stopped working on this issue until I get some > feedback from Ando on my previous comments. Ok understood. One request, can the status be changed from "Closed" to whatever is appropriate? Thanks, -Kartik

1 0

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by hyc＠symas.com 04 Feb '11

04 Feb '11

Kartik Subbarao wrote: > 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. That's fine. I've stopped working on this issue until I get some feedback from Ando on my previous comments. -- -- 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#6825) unique_uri filter reaching beyond its intended target
by hyc＠symas.com 04 Feb '11

04 Feb '11

subbarao(a)computer.org wrote: > Full_Name: Kartik Subbarao > Version: 2.4.23 > OS: Debian Linux 5.0.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.99.175.5) > > > I have the uniqueness overlay configured as follows in slapd.conf: > > overlay unique > unique_uri ldap:///?gidNumber?sub?(objectClass=posixGroup) > > The policy I want to enforce is that all posixGroup entries must have a unique > gidNumber attribute. At the same time, I want to *allow* non-posixGroup entries > (such as inetOrgPerson) to have the same gidNumber attribute that a posixGroup > entry has. This is so that a user can have a login group id set to that of an > existing group. > > With the above configuration in place, if I create a posixGroup entry with > gidNumber 389, and then try to add a gidNumber attribute of 389 to an > inetOrgPerson entry, the operation fails with a constraint error "some > attributes not unique". > > As I read the manpage for slapo-unique, the unique_uri filter seems to support > the functionality that I want: > > ===== > The filter component causes the domain to apply uniqueness constraints only to > matching objects. e.g. ldap:///?cn?sub?(sn=e*) would require unique cn > attributes for > all objects in the subtree of the back-end database whose sn starts with an e. > ===== > > I'm inferring from this that uniqueness constraints on the cn attribute would > *not* be applied to objects that don't match the filter. But that doesn't seem > to be happening here. Is this a bug in the uniqueness overlay or am I not > understanding the implementation? Looks like a bug, the filter check is only implemented for Add operations, not for Modify or ModDN. In the meantime, as a workaround you should simply use a more fully qualified URI. Restrict the URI to the ou containing your posixGroup entries. Since user names and group names are separate name spaces in POSIX, you cannot store them both in the same branches of a DIT anyway. -- -- 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#6825) unique_uri filter reaching beyond its intended target
by subbarao＠computer.org 03 Feb '11

03 Feb '11

One clarification -- in my original message, I meant to say "posixAccount" in place of "inetOrgPerson". These are inetOrgPerson objects, but they also have the posixAccount objectClass which allows them to have the gidNumber attribute. -Kartik

1 0

(ITS#6825) unique_uri filter reaching beyond its intended target
by subbarao＠computer.org 03 Feb '11

03 Feb '11

Full_Name: Kartik Subbarao Version: 2.4.23 OS: Debian Linux 5.0.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.99.175.5) I have the uniqueness overlay configured as follows in slapd.conf: overlay unique unique_uri ldap:///?gidNumber?sub?(objectClass=posixGroup) The policy I want to enforce is that all posixGroup entries must have a unique gidNumber attribute. At the same time, I want to *allow* non-posixGroup entries (such as inetOrgPerson) to have the same gidNumber attribute that a posixGroup entry has. This is so that a user can have a login group id set to that of an existing group. With the above configuration in place, if I create a posixGroup entry with gidNumber 389, and then try to add a gidNumber attribute of 389 to an inetOrgPerson entry, the operation fails with a constraint error "some attributes not unique". As I read the manpage for slapo-unique, the unique_uri filter seems to support the functionality that I want: ===== The filter component causes the domain to apply uniqueness constraints only to matching objects. e.g. ldap:///?cn?sub?(sn=e*) would require unique cn attributes for all objects in the subtree of the back-end database whose sn starts with an e. ===== I'm inferring from this that uniqueness constraints on the cn attribute would *not* be applied to objects that don't match the filter. But that doesn't seem to be happening here. Is this a bug in the uniqueness overlay or am I not understanding the implementation?

1 0

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 03 Feb '11

03 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

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by hyc＠symas.com 02 Feb '11

02 Feb '11

hyc(a)symas.com wrote: > masarati(a)aero.polimi.it wrote: >>>>> The way I read this, it seems to imply that if acl-bind is not set, the >>>>> identity specified by idassert-bind will be used -- which is clearly >>>>> not >>>>> happening here. Am I misreading this, or do you think the wording >>>>> should >>>>> be changed here? >>>> >>>> As far as I remember, the above is (or was) true in some cases (which I >>>> do >>>> not remember); in any case, the above statement is in contradiction with >>>> Howard's statement. Either the behavior stated above should be >>>> generalized (if desirable, in order to avoid the need to configure >>>> things >>>> twice when the same identity is going to be used), or the two should be >>>> decoupled everywhere in the code. >>> >>> The current code in ldap_back_prepare_conn: >>> >>> >>>> >>> #ifdef HAVE_TLS >>> if ( LDAP_BACK_CONN_ISPRIV( lc ) ) { >>> sb =&li->li_acl; >>> >>> } else if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { >>> sb =&li->li_idassert.si_bc; >>> >>> } else { >>> sb =&li->li_tls; >>> } >>> >>> if ( sb->sb_tls_do_init ) { >>> bindconf_tls_set( sb, ld ); >>> } else if ( sb->sb_tls_ctx ) { >>> ldap_set_option( ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); >>> } >>> >>> /* if required by the bindconf configuration, force TLS */ >>> if ( ( sb ==&li->li_acl || sb ==&li->li_idassert.si_bc )&& >>> sb->sb_tls_ctx ) >>> { >>> flags |= LDAP_BACK_F_USE_TLS; >>> } >>> <<<< >>> >>> It seems the initial if/else belongs outside the #ifdef, first of all. Not >>> sure how to handle the fallback to li->li_tls. >> >> Uh, no, that's fine: sb is only used to decide whether and how to start >> TLS, as far as I understand, so the #ifdef is fine. li_tls is only about >> configuring TLS for regular connections, which could be different from >> that of li_acl and li_idassert (and in any case one may want to configure >> TLS without configuring li_acl nor li_idassert. > > OK. The error I saw before was that TLS was started without the CA cert being > configured, and that's because at this point, li->li_acl was used but only > li->li_idassert had any TLS configuration. I've patched this now to also use > li->li_idassert if li_acl was not configured. > >> Later, in ldap_back_getconn(), there's some code that either uses li_acl >> or li_idassert; however, in ldap_back_dobind_int(), private connections >> only use li_acl for private connections when SASL is configured. Probably >> here we should use either li_acl or li_idassert if defined. > > Yeah, that sounds right. OK, will look into this. Corresponding changes made, but the entire body of code here needs some review. There's quite a bit of duplication of effort, compared to slap_client_connect(). Can we strip most of this out? Why does the privileged connection code not use the sb_authzID on the SASL bind, it always uses NULL instead? There are a lot more parameters supported by the bindconf mechanism, which the config parser will accept here (e.g. related to timeouts) that will not get used because slap_client_connect() is not being used. -- -- 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#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by hyc＠symas.com 02 Feb '11

02 Feb '11

masarati(a)aero.polimi.it wrote: >>>> The way I read this, it seems to imply that if acl-bind is not set, the >>>> identity specified by idassert-bind will be used -- which is clearly >>>> not >>>> happening here. Am I misreading this, or do you think the wording >>>> should >>>> be changed here? >>> >>> As far as I remember, the above is (or was) true in some cases (which I >>> do >>> not remember); in any case, the above statement is in contradiction with >>> Howard's statement. Either the behavior stated above should be >>> generalized (if desirable, in order to avoid the need to configure >>> things >>> twice when the same identity is going to be used), or the two should be >>> decoupled everywhere in the code. >> >> The current code in ldap_back_prepare_conn: >> >> >>>> >> #ifdef HAVE_TLS >> if ( LDAP_BACK_CONN_ISPRIV( lc ) ) { >> sb =&li->li_acl; >> >> } else if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { >> sb =&li->li_idassert.si_bc; >> >> } else { >> sb =&li->li_tls; >> } >> >> if ( sb->sb_tls_do_init ) { >> bindconf_tls_set( sb, ld ); >> } else if ( sb->sb_tls_ctx ) { >> ldap_set_option( ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); >> } >> >> /* if required by the bindconf configuration, force TLS */ >> if ( ( sb ==&li->li_acl || sb ==&li->li_idassert.si_bc )&& >> sb->sb_tls_ctx ) >> { >> flags |= LDAP_BACK_F_USE_TLS; >> } >> <<<< >> >> It seems the initial if/else belongs outside the #ifdef, first of all. Not >> sure how to handle the fallback to li->li_tls. > > Uh, no, that's fine: sb is only used to decide whether and how to start > TLS, as far as I understand, so the #ifdef is fine. li_tls is only about > configuring TLS for regular connections, which could be different from > that of li_acl and li_idassert (and in any case one may want to configure > TLS without configuring li_acl nor li_idassert. OK. The error I saw before was that TLS was started without the CA cert being configured, and that's because at this point, li->li_acl was used but only li->li_idassert had any TLS configuration. I've patched this now to also use li->li_idassert if li_acl was not configured. > Later, in ldap_back_getconn(), there's some code that either uses li_acl > or li_idassert; however, in ldap_back_dobind_int(), private connections > only use li_acl for private connections when SASL is configured. Probably > here we should use either li_acl or li_idassert if defined. Yeah, that sounds right. OK, will look into this. -- -- 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#6822) overlays on cn=config break back-config's default acl
by Ralf Haferkamp 02 Feb '11

02 Feb '11

Fix is in servers/slapd/bconfig.c r1.423

1 0

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by masarati＠aero.polimi.it 02 Feb '11

02 Feb '11

>>> The way I read this, it seems to imply that if acl-bind is not set, the >>> identity specified by idassert-bind will be used -- which is clearly >>> not >>> happening here. Am I misreading this, or do you think the wording >>> should >>> be changed here? >> >> As far as I remember, the above is (or was) true in some cases (which I >> do >> not remember); in any case, the above statement is in contradiction with >> Howard's statement. Either the behavior stated above should be >> generalized (if desirable, in order to avoid the need to configure >> things >> twice when the same identity is going to be used), or the two should be >> decoupled everywhere in the code. > > The current code in ldap_back_prepare_conn: > > >>>> > #ifdef HAVE_TLS > if ( LDAP_BACK_CONN_ISPRIV( lc ) ) { > sb = &li->li_acl; > > } else if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { > sb = &li->li_idassert.si_bc; > > } else { > sb = &li->li_tls; > } > > if ( sb->sb_tls_do_init ) { > bindconf_tls_set( sb, ld ); > } else if ( sb->sb_tls_ctx ) { > ldap_set_option( ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); > } > > /* if required by the bindconf configuration, force TLS */ > if ( ( sb == &li->li_acl || sb == &li->li_idassert.si_bc ) && > sb->sb_tls_ctx ) > { > flags |= LDAP_BACK_F_USE_TLS; > } > <<<< > > It seems the initial if/else belongs outside the #ifdef, first of all. Not > sure how to handle the fallback to li->li_tls. Uh, no, that's fine: sb is only used to decide whether and how to start TLS, as far as I understand, so the #ifdef is fine. li_tls is only about configuring TLS for regular connections, which could be different from that of li_acl and li_idassert (and in any case one may want to configure TLS without configuring li_acl nor li_idassert. Later, in ldap_back_getconn(), there's some code that either uses li_acl or li_idassert; however, in ldap_back_dobind_int(), private connections only use li_acl for private connections when SASL is configured. Probably here we should use either li_acl or li_idassert if defined. p.

1 0

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by hyc＠symas.com 02 Feb '11

02 Feb '11

>> The way I read this, it seems to imply that if acl-bind is not set, the >> identity specified by idassert-bind will be used -- which is clearly not >> happening here. Am I misreading this, or do you think the wording should >> be changed here? > > As far as I remember, the above is (or was) true in some cases (which I do > not remember); in any case, the above statement is in contradiction with > Howard's statement. Either the behavior stated above should be > generalized (if desirable, in order to avoid the need to configure things > twice when the same identity is going to be used), or the two should be > decoupled everywhere in the code. The current code in ldap_back_prepare_conn: >>>> #ifdef HAVE_TLS if ( LDAP_BACK_CONN_ISPRIV( lc ) ) { sb = &li->li_acl; } else if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { sb = &li->li_idassert.si_bc; } else { sb = &li->li_tls; } if ( sb->sb_tls_do_init ) { bindconf_tls_set( sb, ld ); } else if ( sb->sb_tls_ctx ) { ldap_set_option( ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); } /* if required by the bindconf configuration, force TLS */ if ( ( sb == &li->li_acl || sb == &li->li_idassert.si_bc ) && sb->sb_tls_ctx ) { flags |= LDAP_BACK_F_USE_TLS; } <<<< It seems the initial if/else belongs outside the #ifdef, first of all. Not sure how to handle the fallback to li->li_tls. -- -- 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#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by subbarao＠computer.org 02 Feb '11

02 Feb '11

This is a multi-part message in MIME format. --------------060105070408050605050000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> 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 --------------060105070408050605050000 Content-Type: text/plain; name="test099-ppolicy-update" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="test099-ppolicy-update" #! /bin/sh # $OpenLDAP: pkg/ldap/tests/scripts/test022-ppolicy,v 1.17.2.9 2010/04/13 20:24:03 kurt Exp $ ## This work is part of OpenLDAP Software <http://www.openldap.org/>. ## ## Copyright 1998-2010 The OpenLDAP Foundation. ## All rights reserved. ## ## Redistribution and use in source and binary forms, with or without ## modification, are permitted only as authorized by the OpenLDAP ## Public License. ## ## A copy of this license is available in the file LICENSE in the ## top-level directory of the distribution or, alternatively, at ## <http://www.OpenLDAP.org/license.html>. echo "running defines.sh" . $SRCDIR/scripts/defines.sh if test $PPOLICY = ppolicyno; then echo "Password policy overlay not available, test skipped" exit 0 fi mkdir -p $TESTDIR $DBDIR1 $SLAPPASSWD -g -n >$CONFIGPWF echo "rootpw `$SLAPPASSWD -T $CONFIGPWF`" >$TESTDIR/configpw.conf echo "Starting slapd on TCP/IP port $PORT1..." . $CONFFILTER $BACKEND $MONITORDB < $PPOLICYCONF > $CONF1 $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 & PID=$! if test $WAIT != 0 ; then echo PID $PID read foo fi KILLPIDS="$PID" USER="uid=nd, ou=People, dc=example, dc=com" PASS=testpassword sleep 1 echo "Using ldapsearch to check that slapd is running..." for i in 0 1 2 3 4 5; do $LDAPSEARCH -s base -b "$MONITOR" -h $LOCALHOST -p $PORT1 \ 'objectclass=*' > /dev/null 2>&1 RC=$? if test $RC = 0 ; then break fi echo "Waiting 5 seconds for slapd to start..." sleep 5 done if test $RC != 0 ; then echo "ldapsearch failed ($RC)!" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit $RC fi echo /dev/null > $TESTOUT echo "Using ldapadd to populate the database..." # may need "-e relax" for draft 09, but not yet. $LDAPADD -D "$MANAGERDN" -h $LOCALHOST -p $PORT1 -w $PASSWD < \ $LDIFPPOLICY >> $TESTOUT 2>&1 RC=$? if test $RC != 0 ; then echo "ldapadd failed ($RC)!" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit $RC fi if test "$BACKLDAP" != "ldapno" && test "$SYNCPROV" != "syncprovno" ; then echo "" echo "Setting up policy state forwarding test..." mkdir $DBDIR2 sed -e "s,$DBDIR1,$DBDIR2," < $CONF1 > $CONF2 echo "Starting slapd consumer on TCP/IP port $PORT2..." $SLAPD -f $CONF2 -h $URI2 -d $LVL $TIMING > $LOG2 2>&1 & PID=$! if test $WAIT != 0 ; then echo PID $PID read foo fi KILLPIDS="$KILLPIDS $PID" echo "Configuring syncprov on provider..." if [ "$SYNCPROV" = syncprovmod ]; then $LDAPADD -D cn=config -H $URI1 -y $CONFIGPWF <<EOF >> $TESTOUT 2>&1 dn: cn=module,cn=config objectclass: olcModuleList cn: module olcModulePath: $TESTWD/../servers/slapd/overlays olcModuleLoad: syncprov.la EOF RC=$? if test $RC != 0 ; then echo "ldapadd failed for moduleLoad ($RC)!" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit $RC fi fi $LDAPADD -D cn=config -H $URI1 -y $CONFIGPWF <<EOF >> $TESTOUT 2>&1 dn: olcOverlay={1}syncprov,olcDatabase={1}$BACKEND,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov EOF RC=$? if test $RC != 0 ; then echo "ldapadd failed for provider database config ($RC)!" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit $RC fi echo "Using ldapsearch to check that slapd is running..." for i in 0 1 2 3 4 5; do $LDAPSEARCH -s base -b "$MONITOR" -H $URI2 \ 'objectclass=*' > /dev/null 2>&1 RC=$? if test $RC = 0 ; then break fi echo "Waiting 5 seconds for slapd to start..." sleep 5 done if test $RC != 0 ; then echo "ldapsearch failed ($RC)!" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit $RC fi echo "Configuring syncrepl on consumer..." if [ "$BACKLDAP" = ldapmod ]; then $LDAPADD -D cn=config -H $URI2 -y $CONFIGPWF <<EOF >> $TESTOUT 2>&1 dn: cn=module,cn=config objectclass: olcModuleList cn: module olcModulePath: $TESTWD/../servers/slapd/back-ldap olcModuleLoad: back_ldap.la EOF RC=$? if test $RC != 0 ; then echo "ldapadd failed for moduleLoad ($RC)!" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit $RC fi fi $LDAPMODIFY -D cn=config -H $URI2 -y $CONFIGPWF <<EOF >> $TESTOUT 2>&1 dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainReturnError: TRUE dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDBURI: $URI1 olcDBStartTLS: start olcDBIDAssertBind: mode=none bindmethod=sasl saslmech=EXTERNAL tls_cert=$DATADIR/localhost.crt tls_key=$DATADIR/localhost.key tls_cacert=$DATADIR/localhost.crt tls_reqcert=never olcDBIDAssertAuthzFrom: * olcDBACLBind: bindmethod=sasl saslmech=EXTERNAL tls_cert=$DATADIR/localhost.crt tls_key=$DATADIR/localhost.key tls_cacert=$DATADIR/localhost.crt tls_reqcert=never dn: olcDatabase={1}$BACKEND,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: rid=1 provider=$URI1 starttls=yes bindmethod=sasl saslmech=EXTERNAL tls_key=$DATADIR/localhost.key tls_cert=$DATADIR/localhost.crt tls_cacert=$DATADIR/localhost.crt tls_reqcert=never tls_crlcheck=none searchbase="dc=example,dc=com" type=refreshAndPersist retry="3 5 300 5" - add: olcUpdateref olcUpdateref: $URI1 - dn: olcOverlay={0}ppolicy,olcDatabase={1}$BACKEND,cn=config changetype: modify replace: olcPPolicyForwardUpdates olcPPolicyForwardUpdates: TRUE - EOF RC=$? if test $RC != 0 ; then echo "ldapmodify failed ($RC)!" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit $RC fi echo "Waiting for consumer to sync..." sleep $SLEEP1 echo "Testing policy state forwarding..." $LDAPSEARCH -H $URI2 -D "$USER" -w wrongpw >$SEARCHOUT 2>&1 if test $? != 49; then echo "ldap bind operation returned $?, expected 49" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit 1 fi $LDAPSEARCH -H $URI1 -D "$MANAGERDN" -w $PASSWD -b "$USER" \* \+ >> $SEARCHOUT 2>&1 COUNT=`grep "pwdFailureTime" $SEARCHOUT | wc -l` if test $COUNT != 1 ; then echo "Policy state forwarding failed" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit 1 fi # End of chaining test fi test $KILLSERVERS != no && kill -HUP $KILLPIDS echo ">>>>> Test succeeded" test $KILLSERVERS != no && wait exit 0 --------------060105070408050605050000--

1 0

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by masarati＠aero.polimi.it 02 Feb '11

02 Feb '11

> On 02/01/2011 04:25 PM, Howard Chu wrote: >> 1) since ppolicy uses the database rootdn to perform the pwdFailuretime >> update, this is considered a privileged connection. Note from the >> slapd-ldap(5) manpage that acl-bind is used for root/privileged >> connections. Your idassert-bind directive had no effect here. The TLS >> session failed because the acl-bind context had no CA cert configured. >> Adding an appropriate olcDbACLBind directive got past this issue. > > Ahh, this is a key point that I was missing, thanks for the > explanation!! (I still have a problem, but I'll continue that in a > separate message) > > FYI though, in slapd-ldap(5), the acl-bind section states the following: > > ===== > The default is to use simple bind, with empty binddn and credentials, > which means that the related operations will be performed anonymously. > If not set, and if idassert-bind is defined, this latter identity is > used instead. See idassert-bind for details. > ===== > > The way I read this, it seems to imply that if acl-bind is not set, the > identity specified by idassert-bind will be used -- which is clearly not > happening here. Am I misreading this, or do you think the wording should > be changed here? As far as I remember, the above is (or was) true in some cases (which I do not remember); in any case, the above statement is in contradiction with Howard's statement. Either the behavior stated above should be generalized (if desirable, in order to avoid the need to configure things twice when the same identity is going to be used), or the two should be decoupled everywhere in the code. p. > Also, do you think it might be helpful to add the following kind of > language to the ppolicy_forward_updates section of the slapo-ppolicy man > page. I know others have had the same confusion that I have had on this > general area, so this might save them a lot of time: > > ===== > Make sure to grant the "manage" ACL privilege to the pwdFailureTime and > pwdAccountLockedTime attributes on the master server. Also, since a > privileged connection is used, the acl-bind directive needs to be > properly configured in the chain overlay. > ===== > >> 2) since pwdFailuretime is an operational attribute, you need to have >> manage privilege to update it. With (1) fixed the modify is correctly >> chained to the provider, but the provider rejects it with Insufficient >> Access. Changing the ACL in slapd-ppolicy.conf to grant "manage' instead >> of "write" access fixes that. With both of those corrections, your test >> script succeeds. Closing this ITS as user config error, there is no >> software bug here. > > Yep. I actually had set this properly in my real environment, I just > neglected to include it in the test file. > > Thanks, > > -Kartik > > > >

1 0

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

02 Feb '11

On 02/01/2011 04:25 PM, Howard Chu wrote: > 1) since ppolicy uses the database rootdn to perform the pwdFailuretime > update, this is considered a privileged connection. Note from the > slapd-ldap(5) manpage that acl-bind is used for root/privileged > connections. Your idassert-bind directive had no effect here. The TLS > session failed because the acl-bind context had no CA cert configured. > Adding an appropriate olcDbACLBind directive got past this issue. Ahh, this is a key point that I was missing, thanks for the explanation!! (I still have a problem, but I'll continue that in a separate message) FYI though, in slapd-ldap(5), the acl-bind section states the following: ===== The default is to use simple bind, with empty binddn and credentials, which means that the related operations will be performed anonymously. If not set, and if idassert-bind is defined, this latter identity is used instead. See idassert-bind for details. ===== The way I read this, it seems to imply that if acl-bind is not set, the identity specified by idassert-bind will be used -- which is clearly not happening here. Am I misreading this, or do you think the wording should be changed here? Also, do you think it might be helpful to add the following kind of language to the ppolicy_forward_updates section of the slapo-ppolicy man page. I know others have had the same confusion that I have had on this general area, so this might save them a lot of time: ===== Make sure to grant the "manage" ACL privilege to the pwdFailureTime and pwdAccountLockedTime attributes on the master server. Also, since a privileged connection is used, the acl-bind directive needs to be properly configured in the chain overlay. ===== > 2) since pwdFailuretime is an operational attribute, you need to have > manage privilege to update it. With (1) fixed the modify is correctly > chained to the provider, but the provider rejects it with Insufficient > Access. Changing the ACL in slapd-ppolicy.conf to grant "manage' instead > of "write" access fixes that. With both of those corrections, your test > script succeeds. Closing this ITS as user config error, there is no > software bug here. Yep. I actually had set this properly in my real environment, I just neglected to include it in the test file. Thanks, -Kartik

1 0

(ITS#6822) overlays on cn=config break back-config's default acl
by ralf＠OpenLDAP.org 02 Feb '11

02 Feb '11

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.241.48) Submitted by: ralf By default, if no ACLs are defined for back-config, back-config creates default ACL to deny access to everybody (see config_back_db_open() in bconfig.c), instead of just using the global ACLs as other backends do. If however an overlay in configured for cn=config (e.g. syncprov) this default-deny ACL is not present. I am currently working on a fix for this.

1 0

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

02 Feb '11

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 ?? ()

1 0

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

02 Feb '11

anderson(a)vailsys.com wrote: > Full_Name: Nathanael Anderson > Version: head > OS: linux (Ubuntu 10.10) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.63.156.11) > > > when doing a modify operation against head results in this segfault > > the same operation works fine against the bdb backend. > > I don't currently have an ldif example, as I noticed this issue when using > phpldapadmin to modify an entry. If an ldif is needed let me know and i'll work > on making one that crashes in the same way. > > these schema's are loaded in the config: > > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/ppolicy.schema > include /usr/local/etc/openldap/schema/nis.schema > > compiled with these options: > ./configure --enable-ndb --enable-passwd --enable-modules --enable-slp > --enable-crypt --enable-overlays --enable-dynamic --enable-syslog --enable-debug > --enable-auditlog --disable-cleartext --enable-wrappers --enable-ppolicy > > Back Trace: 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 ?? () > > Debug -1: > > ldap_read: want=348, got=348 > 0000: 82 01 59 04 26 75 69 64 3d 61 74 75 73 65 72 2c ..Y.&uid=atuser, > 0010: 6f 75 3d 70 65 6f 70 6c 65 2c 64 63 3d 76 61 69 ou=people,dc=vai > 0020: 6c 73 79 73 2c 64 63 3d 63 6f 6d 30 82 01 2d 30 lsys,dc=com0..-0 > 0030: 18 0a 01 02 30 13 04 09 67 69 64 6e 75 6d 62 65 ....0...gidnumbe > 0040: 72 31 06 04 04 31 30 30 30 30 2b 0a 01 02 30 26 r1...10000+...0& > 0050: 04 0d 68 6f 6d 65 64 69 72 65 63 74 6f 72 79 31 ..homedirectory1 > 0060: 15 04 13 2f 65 78 70 6f 72 74 2f 68 6f 6d 65 2f .../export/home/ > 0070: 61 74 75 73 65 72 30 1e 0a 01 02 30 19 04 0a 6c atuser0....0...l > 0080: 6f 67 69 6e 73 68 65 6c 6c 31 0b 04 09 2f 62 69 oginshell1.../bi > 0090: 6e 2f 62 61 73 68 30 31 0a 01 02 30 2c 04 0b 6f n/bash01...0,..o > 00a0: 62 6a 65 63 74 63 6c 61 73 73 31 1d 04 0d 69 6e bjectclass1...in > 00b0: 65 74 4f 72 67 50 65 72 73 6f 6e 04 0c 70 6f 73 etOrgPerson..pos > 00c0: 69 78 41 63 63 6f 75 6e 74 30 77 0a 01 02 30 72 ixAccount0w...0r > 00d0: 04 0c 75 73 65 72 70 61 73 73 77 6f 72 64 31 62 ..userpassword1b > 00e0: 04 60 7b 53 48 41 35 31 32 7d 43 78 44 30 42 38 .`{SHA512}CxD0B8 > 00f0: 55 45 62 72 4c 5a 4f 39 43 7a 64 58 77 4c 78 79 UEbrLZO9CzdXwLxy > 0100: 2f 64 41 2b 58 68 42 39 30 6b 2b 36 4e 4a 59 4b /dA+XhB90k+6NJYK > 0110: 56 2f 6d 73 59 79 41 7a 63 32 45 6a 65 67 6b 55 V/msYyAzc2EjegkU > 0120: 42 4b 6e 2b 48 62 50 2f 4a 76 6b 43 6a 76 30 76 BKn+HbP/JvkCjv0v > 0130: 4a 68 61 4d 6e 46 48 45 2b 6e 30 57 50 67 6d 77 JhaMnFHE+n0WPgmw > 0140: 3d 3d 30 18 0a 01 02 30 13 04 09 75 69 64 6e 75 ==0....0...uidnu > 0150: 6d 62 65 72 31 06 04 04 31 30 30 30 mber1...1000 > ber_get_next: tag 0x30 len 352 contents: > ber_dump: buf=0x26c2380 ptr=0x26c2380 end=0x26c24e0 len=352 > 0000: 02 01 06 66 82 01 59 04 26 75 69 64 3d 61 74 75 ...f..Y.&uid=atu > 0010: 73 65 72 2c 6f 75 3d 70 65 6f 70 6c 65 2c 64 63 ser,ou=people,dc > 0020: 3d 76 61 69 6c 73 79 73 2c 64 63 3d 63 6f 6d 30 =vailsys,dc=com0 > 0030: 82 01 2d 30 18 0a 01 02 30 13 04 09 67 69 64 6e ..-0....0...gidn > 0040: 75 6d 62 65 72 31 06 04 04 31 30 30 30 30 2b 0a umber1...10000+. > 0050: 01 02 30 26 04 0d 68 6f 6d 65 64 69 72 65 63 74 ..0&..homedirect > 0060: 6f 72 79 31 15 04 13 2f 65 78 70 6f 72 74 2f 68 ory1.../export/h > 0070: 6f 6d 65 2f 61 74 75 73 65 72 30 1e 0a 01 02 30 ome/atuser0....0 > 0080: 19 04 0a 6c 6f 67 69 6e 73 68 65 6c 6c 31 0b 04 ...loginshell1.. > 0090: 09 2f 62 69 6e 2f 62 61 73 68 30 31 0a 01 02 30 ./bin/bash01...0 > 00a0: 2c 04 0b 6f 62 6a 65 63 74 63 6c 61 73 73 31 1d ,..objectclass1. > 00b0: 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e 04 ..inetOrgPerson. > 00c0: 0c 70 6f 73 69 78 41 63 63 6f 75 6e 74 30 77 0a .posixAccount0w. > 00d0: 01 02 30 72 04 0c 75 73 65 72 70 61 73 73 77 6f ..0r..userpasswo > 00e0: 72 64 31 62 04 60 7b 53 48 41 35 31 32 7d 43 78 rd1b.`{SHA512}Cx > 00f0: 44 30 42 38 55 45 62 72 4c 5a 4f 39 43 7a 64 58 D0B8UEbrLZO9CzdX > 0100: 77 4c 78 79 2f 64 41 2b 58 68 42 39 30 6b 2b 36 wLxy/dA+XhB90k+6 > 0110: 4e 4a 59 4b 56 2f 6d 73 59 79 41 7a 63 32 45 6a NJYKV/msYyAzc2Ej > 0120: 65 67 6b 55 42 4b 6e 2b 48 62 50 2f 4a 76 6b 43 egkUBKn+HbP/JvkC > 0130: 6a 76 30 76 4a 68 61 4d 6e 46 48 45 2b 6e 30 57 jv0vJhaMnFHE+n0W > 0140: 50 67 6d 77 3d 3d 30 18 0a 01 02 30 13 04 09 75 Pgmw==0....0...u > 0150: 69 64 6e 75 6d 62 65 72 31 06 04 04 31 30 30 30 idnumber1...1000 > op tag 0x66, time 1296600090 > ber_get_next > ldap_read: want=8 error=Resource temporarily unavailable > conn=1002 op=5 do_modify > ber_scanf fmt ({m) ber: > ber_dump: buf=0x26c2380 ptr=0x26c2383 end=0x26c24e0 len=349 > 0000: 66 82 01 59 04 26 75 69 64 3d 61 74 75 73 65 72 f..Y.&uid=atuser > 0010: 2c 6f 75 3d 70 65 6f 70 6c 65 2c 64 63 3d 76 61 ,ou=people,dc=va > 0020: 69 6c 73 79 73 2c 64 63 3d 63 6f 6d 30 82 01 2d ilsys,dc=com0..- > 0030: 30 18 0a 01 02 30 13 04 09 67 69 64 6e 75 6d 62 0....0...gidnumb > 0040: 65 72 31 06 04 04 31 30 30 30 30 2b 0a 01 02 30 er1...10000+...0 > 0050: 26 04 0d 68 6f 6d 65 64 69 72 65 63 74 6f 72 79&..homedirectory > 0060: 31 15 04 13 2f 65 78 70 6f 72 74 2f 68 6f 6d 65 1.../export/home > 0070: 2f 61 74 75 73 65 72 30 1e 0a 01 02 30 19 04 0a /atuser0....0... > 0080: 6c 6f 67 69 6e 73 68 65 6c 6c 31 0b 04 09 2f 62 loginshell1.../b > 0090: 69 6e 2f 62 61 73 68 30 31 0a 01 02 30 2c 04 0b in/bash01...0,.. > 00a0: 6f 62 6a 65 63 74 63 6c 61 73 73 31 1d 04 0d 69 objectclass1...i > 00b0: 6e 65 74 4f 72 67 50 65 72 73 6f 6e 04 0c 70 6f netOrgPerson..po > 00c0: 73 69 78 41 63 63 6f 75 6e 74 30 77 0a 01 02 30 sixAccount0w...0 > 00d0: 72 04 0c 75 73 65 72 70 61 73 73 77 6f 72 64 31 r..userpassword1 > 00e0: 62 04 60 7b 53 48 41 35 31 32 7d 43 78 44 30 42 b.`{SHA512}CxD0B > 00f0: 38 55 45 62 72 4c 5a 4f 39 43 7a 64 58 77 4c 78 8UEbrLZO9CzdXwLx > 0100: 79 2f 64 41 2b 58 68 42 39 30 6b 2b 36 4e 4a 59 y/dA+XhB90k+6NJY > 0110: 4b 56 2f 6d 73 59 79 41 7a 63 32 45 6a 65 67 6b KV/msYyAzc2Ejegk > 0120: 55 42 4b 6e 2b 48 62 50 2f 4a 76 6b 43 6a 76 30 UBKn+HbP/JvkCjv0 > 0130: 76 4a 68 61 4d 6e 46 48 45 2b 6e 30 57 50 67 6d vJhaMnFHE+n0WPgm > 0140: 77 3d 3d 30 18 0a 01 02 30 13 04 09 75 69 64 6e w==0....0...uidn > 0150: 75 6d 62 65 72 31 06 04 04 31 30 30 30 umber1...1000 > conn=1002 op=5 do_modify: dn (uid=atuser,ou=people,dc=vailsys,dc=com) > ber_scanf fmt ({e{m[W]}}) ber: > ber_dump: buf=0x26c2380 ptr=0x26c23b3 end=0x26c24e0 len=301 > 0000: 30 18 0a 01 02 30 13 04 09 67 69 64 6e 75 6d 62 0....0...gidnumb > 0010: 65 72 31 06 04 04 31 30 30 30 30 2b 0a 01 02 30 er1...10000+...0 > 0020: 26 04 0d 68 6f 6d 65 64 69 72 65 63 74 6f 72 79&..homedirectory > 0030: 31 15 04 13 2f 65 78 70 6f 72 74 2f 68 6f 6d 65 1.../export/home > 0040: 2f 61 74 75 73 65 72 30 1e 0a 01 02 30 19 04 0a /atuser0....0... > 0050: 6c 6f 67 69 6e 73 68 65 6c 6c 31 0b 04 09 2f 62 loginshell1.../b > 0060: 69 6e 2f 62 61 73 68 30 31 0a 01 02 30 2c 04 0b in/bash01...0,.. > 0070: 6f 62 6a 65 63 74 63 6c 61 73 73 31 1d 04 0d 69 objectclass1...i > 0080: 6e 65 74 4f 72 67 50 65 72 73 6f 6e 04 0c 70 6f netOrgPerson..po > 0090: 73 69 78 41 63 63 6f 75 6e 74 30 77 0a 01 02 30 sixAccount0w...0 > 00a0: 72 04 0c 75 73 65 72 70 61 73 73 77 6f 72 64 31 r..userpassword1 > 00b0: 62 04 60 7b 53 48 41 35 31 32 7d 43 78 44 30 42 b.`{SHA512}CxD0B > 00c0: 38 55 45 62 72 4c 5a 4f 39 43 7a 64 58 77 4c 78 8UEbrLZO9CzdXwLx > 00d0: 79 2f 64 41 2b 58 68 42 39 30 6b 2b 36 4e 4a 59 y/dA+XhB90k+6NJY > 00e0: 4b 56 2f 6d 73 59 79 41 7a 63 32 45 6a 65 67 6b KV/msYyAzc2Ejegk > 00f0: 55 42 4b 6e 2b 48 62 50 2f 4a 76 6b 43 6a 76 30 UBKn+HbP/JvkCjv0 > 0100: 76 4a 68 61 4d 6e 46 48 45 2b 6e 30 57 50 67 6d vJhaMnFHE+n0WPgm > 0110: 77 3d 3d 30 18 0a 01 02 30 13 04 09 75 69 64 6e w==0....0...uidn > 0120: 75 6d 62 65 72 31 06 04 04 31 30 30 30 umber1...1000 > ber_scanf fmt ({e{m[W]}}) ber: > ber_dump: buf=0x26c2380 ptr=0x26c23cd end=0x26c24e0 len=275 > 0000: 30 2b 0a 01 02 30 26 04 0d 68 6f 6d 65 64 69 72 0+...0&..homedir > 0010: 65 63 74 6f 72 79 31 15 04 13 2f 65 78 70 6f 72 ectory1.../expor > 0020: 74 2f 68 6f 6d 65 2f 61 74 75 73 65 72 30 1e 0a t/home/atuser0.. > 0030: 01 02 30 19 04 0a 6c 6f 67 69 6e 73 68 65 6c 6c ..0...loginshell > 0040: 31 0b 04 09 2f 62 69 6e 2f 62 61 73 68 30 31 0a 1.../bin/bash01. > 0050: 01 02 30 2c 04 0b 6f 62 6a 65 63 74 63 6c 61 73 ..0,..objectclas > 0060: 73 31 1d 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 s1...inetOrgPers > 0070: 6f 6e 04 0c 70 6f 73 69 78 41 63 63 6f 75 6e 74 on..posixAccount > 0080: 30 77 0a 01 02 30 72 04 0c 75 73 65 72 70 61 73 0w...0r..userpas > 0090: 73 77 6f 72 64 31 62 04 60 7b 53 48 41 35 31 32 sword1b.`{SHA512 > 00a0: 7d 43 78 44 30 42 38 55 45 62 72 4c 5a 4f 39 43 }CxD0B8UEbrLZO9C > 00b0: 7a 64 58 77 4c 78 79 2f 64 41 2b 58 68 42 39 30 zdXwLxy/dA+XhB90 > 00c0: 6b 2b 36 4e 4a 59 4b 56 2f 6d 73 59 79 41 7a 63 k+6NJYKV/msYyAzc > 00d0: 32 45 6a 65 67 6b 55 42 4b 6e 2b 48 62 50 2f 4a 2EjegkUBKn+HbP/J > 00e0: 76 6b 43 6a 76 30 76 4a 68 61 4d 6e 46 48 45 2b vkCjv0vJhaMnFHE+ > 00f0: 6e 30 57 50 67 6d 77 3d 3d 30 18 0a 01 02 30 13 n0WPgmw==0....0. > 0100: 04 09 75 69 64 6e 75 6d 62 65 72 31 06 04 04 31 ..uidnumber1...1 > 0110: 30 30 30 000 > ber_scanf fmt ({e{m[W]}}) ber: > ber_dump: buf=0x26c2380 ptr=0x26c23fa end=0x26c24e0 len=230 > 0000: 30 1e 0a 01 02 30 19 04 0a 6c 6f 67 69 6e 73 68 0....0...loginsh > 0010: 65 6c 6c 31 0b 04 09 2f 62 69 6e 2f 62 61 73 68 ell1.../bin/bash > 0020: 30 31 0a 01 02 30 2c 04 0b 6f 62 6a 65 63 74 63 01...0,..objectc > 0030: 6c 61 73 73 31 1d 04 0d 69 6e 65 74 4f 72 67 50 lass1...inetOrgP > 0040: 65 72 73 6f 6e 04 0c 70 6f 73 69 78 41 63 63 6f erson..posixAcco > 0050: 75 6e 74 30 77 0a 01 02 30 72 04 0c 75 73 65 72 unt0w...0r..user > 0060: 70 61 73 73 77 6f 72 64 31 62 04 60 7b 53 48 41 password1b.`{SHA > 0070: 35 31 32 7d 43 78 44 30 42 38 55 45 62 72 4c 5a 512}CxD0B8UEbrLZ > 0080: 4f 39 43 7a 64 58 77 4c 78 79 2f 64 41 2b 58 68 O9CzdXwLxy/dA+Xh > 0090: 42 39 30 6b 2b 36 4e 4a 59 4b 56 2f 6d 73 59 79 B90k+6NJYKV/msYy > 00a0: 41 7a 63 32 45 6a 65 67 6b 55 42 4b 6e 2b 48 62 Azc2EjegkUBKn+Hb > 00b0: 50 2f 4a 76 6b 43 6a 76 30 76 4a 68 61 4d 6e 46 P/JvkCjv0vJhaMnF > 00c0: 48 45 2b 6e 30 57 50 67 6d 77 3d 3d 30 18 0a 01 HE+n0WPgmw==0... > 00d0: 02 30 13 04 09 75 69 64 6e 75 6d 62 65 72 31 06 .0...uidnumber1. > 00e0: 04 04 31 30 30 30 ..1000 > ber_scanf fmt ({e{m[W]}}) ber: > ber_dump: buf=0x26c2380 ptr=0x26c241a end=0x26c24e0 len=198 > 0000: 30 31 0a 01 02 30 2c 04 0b 6f 62 6a 65 63 74 63 01...0,..objectc > 0010: 6c 61 73 73 31 1d 04 0d 69 6e 65 74 4f 72 67 50 lass1...inetOrgP > 0020: 65 72 73 6f 6e 04 0c 70 6f 73 69 78 41 63 63 6f erson..posixAcco > 0030: 75 6e 74 30 77 0a 01 02 30 72 04 0c 75 73 65 72 unt0w...0r..user > 0040: 70 61 73 73 77 6f 72 64 31 62 04 60 7b 53 48 41 password1b.`{SHA > 0050: 35 31 32 7d 43 78 44 30 42 38 55 45 62 72 4c 5a 512}CxD0B8UEbrLZ > 0060: 4f 39 43 7a 64 58 77 4c 78 79 2f 64 41 2b 58 68 O9CzdXwLxy/dA+Xh > 0070: 42 39 30 6b 2b 36 4e 4a 59 4b 56 2f 6d 73 59 79 B90k+6NJYKV/msYy > 0080: 41 7a 63 32 45 6a 65 67 6b 55 42 4b 6e 2b 48 62 Azc2EjegkUBKn+Hb > 0090: 50 2f 4a 76 6b 43 6a 76 30 76 4a 68 61 4d 6e 46 P/JvkCjv0vJhaMnF > 00a0: 48 45 2b 6e 30 57 50 67 6d 77 3d 3d 30 18 0a 01 HE+n0WPgmw==0... > 00b0: 02 30 13 04 09 75 69 64 6e 75 6d 62 65 72 31 06 .0...uidnumber1. > 00c0: 04 04 31 30 30 30 ..1000 > ber_scanf fmt ({e{m[W]}}) ber: > ber_dump: buf=0x26c2380 ptr=0x26c244d end=0x26c24e0 len=147 > 0000: 30 77 0a 01 02 30 72 04 0c 75 73 65 72 70 61 73 0w...0r..userpas > 0010: 73 77 6f 72 64 31 62 04 60 7b 53 48 41 35 31 32 sword1b.`{SHA512 > 0020: 7d 43 78 44 30 42 38 55 45 62 72 4c 5a 4f 39 43 }CxD0B8UEbrLZO9C > 0030: 7a 64 58 77 4c 78 79 2f 64 41 2b 58 68 42 39 30 zdXwLxy/dA+XhB90 > 0040: 6b 2b 36 4e 4a 59 4b 56 2f 6d 73 59 79 41 7a 63 k+6NJYKV/msYyAzc > 0050: 32 45 6a 65 67 6b 55 42 4b 6e 2b 48 62 50 2f 4a 2EjegkUBKn+HbP/J > 0060: 76 6b 43 6a 76 30 76 4a 68 61 4d 6e 46 48 45 2b vkCjv0vJhaMnFHE+ > 0070: 6e 30 57 50 67 6d 77 3d 3d 30 18 0a 01 02 30 13 n0WPgmw==0....0. > 0080: 04 09 75 69 64 6e 75 6d 62 65 72 31 06 04 04 31 ..uidnumber1...1 > 0090: 30 30 30 000 > ber_scanf fmt ({e{m[W]}}) ber: > ber_dump: buf=0x26c2380 ptr=0x26c24c6 end=0x26c24e0 len=26 > 0000: 30 18 0a 01 02 30 13 04 09 75 69 64 6e 75 6d 62 0....0...uidnumb > 0010: 65 72 31 06 04 04 31 30 30 30 er1...1000 >>>> dnPrettyNormal:<uid=atuser,ou=people,dc=vailsys,dc=com> > => ldap_bv2dn(uid=atuser,ou=people,dc=vailsys,dc=com,0) > <= ldap_bv2dn(uid=atuser,ou=people,dc=vailsys,dc=com)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(uid=atuser,ou=people,dc=vailsys,dc=com)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(uid=atuser,ou=people,dc=vailsys,dc=com)=0 > <<< dnPrettyNormal:<uid=atuser,ou=people,dc=vailsys,dc=com>, > <uid=atuser,ou=people,dc=vailsys,dc=com> > conn=1002 op=5 modifications: > replace: gidnumber > one value, length 4 > replace: homedirectory > one value, length 19 > replace: loginshell > one value, length 9 > replace: objectclass > multiple values > replace: userpassword > one value, length 96 > replace: uidnumber > one value, length 4 > conn=1002 op=5 MOD dn="uid=atuser,ou=people,dc=vailsys,dc=com" > daemon: activity on 1 descriptor > daemon: activity on: > daemon: epoll: listen=7 active_threads=0 tvp=NULL > daemon: epoll: listen=8 active_threads=0 tvp=NULL > conn=1002 op=5 MOD attr=gidnumber homedirectory loginshell objectclass > userpassword uidnumber > ndb_back_modify: uid=atuser,ou=people,dc=vailsys,dc=com > slap_queue_csn: queing 0x7fe9b3e28c50 20110201224130.989215Z#000000#000#000000 > conn=1002 op=4 SEARCH RESULT tag=101 err=0 nentries=0 text= >>>> dnNormalize:<cn=admin,dc=vailsys,dc=com> > => ldap_bv2dn(cn=admin,dc=vailsys,dc=com,0) > <= ldap_bv2dn(cn=admin,dc=vailsys,dc=com)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(cn=admin,dc=vailsys,dc=com)=0 > <<< dnNormalize:<cn=admin,dc=vailsys,dc=com> >>>> dnNormalize:<cn=admin,dc=vailsys,dc=com> > => ldap_bv2dn(cn=admin,dc=vailsys,dc=com,0) > <= ldap_bv2dn(cn=admin,dc=vailsys,dc=com)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(cn=admin,dc=vailsys,dc=com)=0 > <<< dnNormalize:<cn=admin,dc=vailsys,dc=com> > ndb_modify_internal: 0x00006d61: uid=atuser,ou=people,dc=vailsys,dc=com > <= acl_access_allowed: granted to database root > ndb_modify_internal: replace gidNumber > ndb_modify_internal: replace homeDirectory > ndb_modify_internal: replace loginShell > ndb_modify_internal: replace objectClass > ndb_modify_internal: replace userPassword > ndb_modify_internal: replace uidNumber > ndb_modify_internal: replace entryCSN > ndb_modify_internal: replace modifiersName > ndb_modify_internal: replace modifyTimestamp > oc_check_required entry (uid=atuser,ou=people,dc=vailsys,dc=com), objectClass > "inetOrgPerson" > oc_check_required entry (uid=atuser,ou=people,dc=vailsys,dc=com), objectClass > "posixAccount" > oc_check_allowed type "sn" > oc_check_allowed type "cn" > oc_check_allowed type "givenName" > oc_check_allowed type "uid" > oc_check_allowed type "structuralObjectClass" > oc_check_allowed type "entryUUID" > oc_check_allowed type "creatorsName" > oc_check_allowed type "createTimestamp" > oc_check_allowed type "gidNumber" > oc_check_allowed type "homeDirectory" > oc_check_allowed type "loginShell" > oc_check_allowed type "objectClass" > oc_check_allowed type "userPassword" > oc_check_allowed type "uidNumber" > oc_check_allowed type "entryCSN" > oc_check_allowed type "modifiersName" > oc_check_allowed type "modifyTimestamp" > Segmentation fault (core dumped) > > -- -- 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#6652) accesslog anomaly in db drop/re-import
by marco.pizzoli＠gmail.com 02 Feb '11

02 Feb '11

--000e0cd157581b9a96049b48f417 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Done. The slapcat/drop/slapadd procedure went fine. Thanks Marco On Tue, Feb 1, 2011 at 4:53 PM, Marco Pizzoli <marco.pizzoli(a)gmail.com>wrot= e: > Ok, I re-downloaded the source tree and now the accesslog.c file is > updated. > > I started the daemon and tomorrow I will re-try the drop/import. > > Thanks > Marco Pizzoli > > > On Tue, Feb 1, 2011 at 4:41 PM, Hallvard B Furuseth < > h.b.furuseth(a)usit.uio.no> wrote: > >> marco.pizzoli(a)gmail.com writes: >> > I downloaded the HEAD repository, compiled and tried the import. Same >> > problem on the same line. >> > (...) >> > Had I downloaded the wrong repository? >> >> Probably not, but you can check CVS/Root - it should contain >> :pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP >> >> However, try again now. The public CVS repository it is regularly >> synced with the main repository, but you may have updated from it >> before the patch reached it. >> >> > I went to see the version of the source accesslog.c and saw this line = on >> top >> > of it: >> > /* accesslog.c - log operations for audit/history purposes */ >> > /* $OpenLDAP: pkg/ldap/servers/slapd/overlays/accesslog.c,v 1.37.2.34 = * >> > 2011/01/26* 23:23:34 quanah Exp $ */ >> >> That from the release branch, which has not merged this patch. >> >> HEAD is the main branch used for development, currently with accesslog >> 1.115. >> >> -- >> Hallvard >> > > > > -- > _________________________________________ > Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. > Jim Morrison > --=20 _________________________________________ Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison --000e0cd157581b9a96049b48f417 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Done. <br>The slapcat/drop/slapadd procedure went fine.<br><br>Thanks<br>= =A0=A0=A0=A0=A0=A0 Marco<br><br><br><br><div class=3D"gmail_quote">On Tue, = Feb 1, 2011 at 4:53 PM, Marco Pizzoli <span dir=3D"ltr"><<a href=3D"mail= to:marco.pizzoli@gmail.com">marco.pizzoli(a)gmail.com</a>></span> wrote:<b= r> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Ok, I re-download= ed the source tree and now the accesslog.c file is updated.<br><br>I starte= d the daemon and tomorrow I will re-try the drop/import.<br> <br>Thanks<br><font color=3D"#888888">=A0=A0=A0=A0=A0 Marco Pizzoli</font><= div><div></div><div class=3D"h5"><br><br><div class=3D"gmail_quote">On Tue,= Feb 1, 2011 at 4:41 PM, Hallvard B Furuseth <span dir=3D"ltr"><<a href= =3D"mailto:h.b.furuseth@usit.uio.no" target=3D"_blank">h.b.furuseth(a)usit.ui= o.no</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><a href=3D"m= ailto:marco.pizzoli@gmail.com" target=3D"_blank">marco.pizzoli(a)gmail.com</a= > writes:<br> > I downloaded the HEAD repository, compiled and tried the import. Same<= br> > problem on the same line.<br> </div>> (...)<br> <div>> Had I downloaded the wrong repository?<br> <br> </div>Probably not, but you can check CVS/Root - it should contain<br> =A0 =A0 =A0 =A0:pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP<br> <br> However, try again now. =A0The public CVS repository it is regularly<br> synced with the main repository, but you may have updated from it<br> before the patch reached it.<br> <div><br> > I went to see the version of the source accesslog.c and saw this line = on top<br> > of it:<br> > /* accesslog.c - log operations for audit/history purposes */<br> > /* $OpenLDAP: pkg/ldap/servers/slapd/overlays/accesslog.c,v 1.37.2.34 = *<br> > 2011/01/26* 23:23:34 quanah Exp $ */<br> <br> </div>That from the release branch, which has not merged this patch.<br> <br> HEAD is the main branch used for development, currently with accesslog<br> 1.115.<br> <br> --<br> <font color=3D"#888888">Hallvard<br> </font></blockquote></div><br><br clear=3D"all"><br></div></div><div><div><= /div><div class=3D"h5">-- <br>_________________________________________<br>= Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi.<br>=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jim Morrison<br> <div style=3D"padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hi= dden; word-wrap: break-word; color: black; font-size: 10px; text-align: lef= t; line-height: 130%;"> </div> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>___________= ______________________________<br>Non =E8 forte chi non cade, ma chi cadend= o ha la forza di rialzarsi.<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jim = Morrison<br> <div style=3D"visibility: hidden; left: -5000px; position: absolute; z-inde= x: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden;= word-wrap: break-word; color: black; font-size: 10px; text-align: left; li= ne-height: 130%;" id=3D"avg_ls_inline_popup"> </div> --000e0cd157581b9a96049b48f417--

1 0

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

01 Feb '11

Full_Name: Nathanael Anderson Version: head OS: linux (Ubuntu 10.10) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.63.156.11) when doing a modify operation against head results in this segfault the same operation works fine against the bdb backend. I don't currently have an ldif example, as I noticed this issue when using phpldapadmin to modify an entry. If an ldif is needed let me know and i'll work on making one that crashes in the same way. these schema's are loaded in the config: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/ppolicy.schema include /usr/local/etc/openldap/schema/nis.schema compiled with these options: ./configure --enable-ndb --enable-passwd --enable-modules --enable-slp --enable-crypt --enable-overlays --enable-dynamic --enable-syslog --enable-debug --enable-auditlog --disable-cleartext --enable-wrappers --enable-ppolicy Back Trace: 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 ?? () Debug -1: ldap_read: want=348, got=348 0000: 82 01 59 04 26 75 69 64 3d 61 74 75 73 65 72 2c ..Y.&uid=atuser, 0010: 6f 75 3d 70 65 6f 70 6c 65 2c 64 63 3d 76 61 69 ou=people,dc=vai 0020: 6c 73 79 73 2c 64 63 3d 63 6f 6d 30 82 01 2d 30 lsys,dc=com0..-0 0030: 18 0a 01 02 30 13 04 09 67 69 64 6e 75 6d 62 65 ....0...gidnumbe 0040: 72 31 06 04 04 31 30 30 30 30 2b 0a 01 02 30 26 r1...10000+...0& 0050: 04 0d 68 6f 6d 65 64 69 72 65 63 74 6f 72 79 31 ..homedirectory1 0060: 15 04 13 2f 65 78 70 6f 72 74 2f 68 6f 6d 65 2f .../export/home/ 0070: 61 74 75 73 65 72 30 1e 0a 01 02 30 19 04 0a 6c atuser0....0...l 0080: 6f 67 69 6e 73 68 65 6c 6c 31 0b 04 09 2f 62 69 oginshell1.../bi 0090: 6e 2f 62 61 73 68 30 31 0a 01 02 30 2c 04 0b 6f n/bash01...0,..o 00a0: 62 6a 65 63 74 63 6c 61 73 73 31 1d 04 0d 69 6e bjectclass1...in 00b0: 65 74 4f 72 67 50 65 72 73 6f 6e 04 0c 70 6f 73 etOrgPerson..pos 00c0: 69 78 41 63 63 6f 75 6e 74 30 77 0a 01 02 30 72 ixAccount0w...0r 00d0: 04 0c 75 73 65 72 70 61 73 73 77 6f 72 64 31 62 ..userpassword1b 00e0: 04 60 7b 53 48 41 35 31 32 7d 43 78 44 30 42 38 .`{SHA512}CxD0B8 00f0: 55 45 62 72 4c 5a 4f 39 43 7a 64 58 77 4c 78 79 UEbrLZO9CzdXwLxy 0100: 2f 64 41 2b 58 68 42 39 30 6b 2b 36 4e 4a 59 4b /dA+XhB90k+6NJYK 0110: 56 2f 6d 73 59 79 41 7a 63 32 45 6a 65 67 6b 55 V/msYyAzc2EjegkU 0120: 42 4b 6e 2b 48 62 50 2f 4a 76 6b 43 6a 76 30 76 BKn+HbP/JvkCjv0v 0130: 4a 68 61 4d 6e 46 48 45 2b 6e 30 57 50 67 6d 77 JhaMnFHE+n0WPgmw 0140: 3d 3d 30 18 0a 01 02 30 13 04 09 75 69 64 6e 75 ==0....0...uidnu 0150: 6d 62 65 72 31 06 04 04 31 30 30 30 mber1...1000 ber_get_next: tag 0x30 len 352 contents: ber_dump: buf=0x26c2380 ptr=0x26c2380 end=0x26c24e0 len=352 0000: 02 01 06 66 82 01 59 04 26 75 69 64 3d 61 74 75 ...f..Y.&uid=atu 0010: 73 65 72 2c 6f 75 3d 70 65 6f 70 6c 65 2c 64 63 ser,ou=people,dc 0020: 3d 76 61 69 6c 73 79 73 2c 64 63 3d 63 6f 6d 30 =vailsys,dc=com0 0030: 82 01 2d 30 18 0a 01 02 30 13 04 09 67 69 64 6e ..-0....0...gidn 0040: 75 6d 62 65 72 31 06 04 04 31 30 30 30 30 2b 0a umber1...10000+. 0050: 01 02 30 26 04 0d 68 6f 6d 65 64 69 72 65 63 74 ..0&..homedirect 0060: 6f 72 79 31 15 04 13 2f 65 78 70 6f 72 74 2f 68 ory1.../export/h 0070: 6f 6d 65 2f 61 74 75 73 65 72 30 1e 0a 01 02 30 ome/atuser0....0 0080: 19 04 0a 6c 6f 67 69 6e 73 68 65 6c 6c 31 0b 04 ...loginshell1.. 0090: 09 2f 62 69 6e 2f 62 61 73 68 30 31 0a 01 02 30 ./bin/bash01...0 00a0: 2c 04 0b 6f 62 6a 65 63 74 63 6c 61 73 73 31 1d ,..objectclass1. 00b0: 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e 04 ..inetOrgPerson. 00c0: 0c 70 6f 73 69 78 41 63 63 6f 75 6e 74 30 77 0a .posixAccount0w. 00d0: 01 02 30 72 04 0c 75 73 65 72 70 61 73 73 77 6f ..0r..userpasswo 00e0: 72 64 31 62 04 60 7b 53 48 41 35 31 32 7d 43 78 rd1b.`{SHA512}Cx 00f0: 44 30 42 38 55 45 62 72 4c 5a 4f 39 43 7a 64 58 D0B8UEbrLZO9CzdX 0100: 77 4c 78 79 2f 64 41 2b 58 68 42 39 30 6b 2b 36 wLxy/dA+XhB90k+6 0110: 4e 4a 59 4b 56 2f 6d 73 59 79 41 7a 63 32 45 6a NJYKV/msYyAzc2Ej 0120: 65 67 6b 55 42 4b 6e 2b 48 62 50 2f 4a 76 6b 43 egkUBKn+HbP/JvkC 0130: 6a 76 30 76 4a 68 61 4d 6e 46 48 45 2b 6e 30 57 jv0vJhaMnFHE+n0W 0140: 50 67 6d 77 3d 3d 30 18 0a 01 02 30 13 04 09 75 Pgmw==0....0...u 0150: 69 64 6e 75 6d 62 65 72 31 06 04 04 31 30 30 30 idnumber1...1000 op tag 0x66, time 1296600090 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=1002 op=5 do_modify ber_scanf fmt ({m) ber: ber_dump: buf=0x26c2380 ptr=0x26c2383 end=0x26c24e0 len=349 0000: 66 82 01 59 04 26 75 69 64 3d 61 74 75 73 65 72 f..Y.&uid=atuser 0010: 2c 6f 75 3d 70 65 6f 70 6c 65 2c 64 63 3d 76 61 ,ou=people,dc=va 0020: 69 6c 73 79 73 2c 64 63 3d 63 6f 6d 30 82 01 2d ilsys,dc=com0..- 0030: 30 18 0a 01 02 30 13 04 09 67 69 64 6e 75 6d 62 0....0...gidnumb 0040: 65 72 31 06 04 04 31 30 30 30 30 2b 0a 01 02 30 er1...10000+...0 0050: 26 04 0d 68 6f 6d 65 64 69 72 65 63 74 6f 72 79 &..homedirectory 0060: 31 15 04 13 2f 65 78 70 6f 72 74 2f 68 6f 6d 65 1.../export/home 0070: 2f 61 74 75 73 65 72 30 1e 0a 01 02 30 19 04 0a /atuser0....0... 0080: 6c 6f 67 69 6e 73 68 65 6c 6c 31 0b 04 09 2f 62 loginshell1.../b 0090: 69 6e 2f 62 61 73 68 30 31 0a 01 02 30 2c 04 0b in/bash01...0,.. 00a0: 6f 62 6a 65 63 74 63 6c 61 73 73 31 1d 04 0d 69 objectclass1...i 00b0: 6e 65 74 4f 72 67 50 65 72 73 6f 6e 04 0c 70 6f netOrgPerson..po 00c0: 73 69 78 41 63 63 6f 75 6e 74 30 77 0a 01 02 30 sixAccount0w...0 00d0: 72 04 0c 75 73 65 72 70 61 73 73 77 6f 72 64 31 r..userpassword1 00e0: 62 04 60 7b 53 48 41 35 31 32 7d 43 78 44 30 42 b.`{SHA512}CxD0B 00f0: 38 55 45 62 72 4c 5a 4f 39 43 7a 64 58 77 4c 78 8UEbrLZO9CzdXwLx 0100: 79 2f 64 41 2b 58 68 42 39 30 6b 2b 36 4e 4a 59 y/dA+XhB90k+6NJY 0110: 4b 56 2f 6d 73 59 79 41 7a 63 32 45 6a 65 67 6b KV/msYyAzc2Ejegk 0120: 55 42 4b 6e 2b 48 62 50 2f 4a 76 6b 43 6a 76 30 UBKn+HbP/JvkCjv0 0130: 76 4a 68 61 4d 6e 46 48 45 2b 6e 30 57 50 67 6d vJhaMnFHE+n0WPgm 0140: 77 3d 3d 30 18 0a 01 02 30 13 04 09 75 69 64 6e w==0....0...uidn 0150: 75 6d 62 65 72 31 06 04 04 31 30 30 30 umber1...1000 conn=1002 op=5 do_modify: dn (uid=atuser,ou=people,dc=vailsys,dc=com) ber_scanf fmt ({e{m[W]}}) ber: ber_dump: buf=0x26c2380 ptr=0x26c23b3 end=0x26c24e0 len=301 0000: 30 18 0a 01 02 30 13 04 09 67 69 64 6e 75 6d 62 0....0...gidnumb 0010: 65 72 31 06 04 04 31 30 30 30 30 2b 0a 01 02 30 er1...10000+...0 0020: 26 04 0d 68 6f 6d 65 64 69 72 65 63 74 6f 72 79 &..homedirectory 0030: 31 15 04 13 2f 65 78 70 6f 72 74 2f 68 6f 6d 65 1.../export/home 0040: 2f 61 74 75 73 65 72 30 1e 0a 01 02 30 19 04 0a /atuser0....0... 0050: 6c 6f 67 69 6e 73 68 65 6c 6c 31 0b 04 09 2f 62 loginshell1.../b 0060: 69 6e 2f 62 61 73 68 30 31 0a 01 02 30 2c 04 0b in/bash01...0,.. 0070: 6f 62 6a 65 63 74 63 6c 61 73 73 31 1d 04 0d 69 objectclass1...i 0080: 6e 65 74 4f 72 67 50 65 72 73 6f 6e 04 0c 70 6f netOrgPerson..po 0090: 73 69 78 41 63 63 6f 75 6e 74 30 77 0a 01 02 30 sixAccount0w...0 00a0: 72 04 0c 75 73 65 72 70 61 73 73 77 6f 72 64 31 r..userpassword1 00b0: 62 04 60 7b 53 48 41 35 31 32 7d 43 78 44 30 42 b.`{SHA512}CxD0B 00c0: 38 55 45 62 72 4c 5a 4f 39 43 7a 64 58 77 4c 78 8UEbrLZO9CzdXwLx 00d0: 79 2f 64 41 2b 58 68 42 39 30 6b 2b 36 4e 4a 59 y/dA+XhB90k+6NJY 00e0: 4b 56 2f 6d 73 59 79 41 7a 63 32 45 6a 65 67 6b KV/msYyAzc2Ejegk 00f0: 55 42 4b 6e 2b 48 62 50 2f 4a 76 6b 43 6a 76 30 UBKn+HbP/JvkCjv0 0100: 76 4a 68 61 4d 6e 46 48 45 2b 6e 30 57 50 67 6d vJhaMnFHE+n0WPgm 0110: 77 3d 3d 30 18 0a 01 02 30 13 04 09 75 69 64 6e w==0....0...uidn 0120: 75 6d 62 65 72 31 06 04 04 31 30 30 30 umber1...1000 ber_scanf fmt ({e{m[W]}}) ber: ber_dump: buf=0x26c2380 ptr=0x26c23cd end=0x26c24e0 len=275 0000: 30 2b 0a 01 02 30 26 04 0d 68 6f 6d 65 64 69 72 0+...0&..homedir 0010: 65 63 74 6f 72 79 31 15 04 13 2f 65 78 70 6f 72 ectory1.../expor 0020: 74 2f 68 6f 6d 65 2f 61 74 75 73 65 72 30 1e 0a t/home/atuser0.. 0030: 01 02 30 19 04 0a 6c 6f 67 69 6e 73 68 65 6c 6c ..0...loginshell 0040: 31 0b 04 09 2f 62 69 6e 2f 62 61 73 68 30 31 0a 1.../bin/bash01. 0050: 01 02 30 2c 04 0b 6f 62 6a 65 63 74 63 6c 61 73 ..0,..objectclas 0060: 73 31 1d 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 s1...inetOrgPers 0070: 6f 6e 04 0c 70 6f 73 69 78 41 63 63 6f 75 6e 74 on..posixAccount 0080: 30 77 0a 01 02 30 72 04 0c 75 73 65 72 70 61 73 0w...0r..userpas 0090: 73 77 6f 72 64 31 62 04 60 7b 53 48 41 35 31 32 sword1b.`{SHA512 00a0: 7d 43 78 44 30 42 38 55 45 62 72 4c 5a 4f 39 43 }CxD0B8UEbrLZO9C 00b0: 7a 64 58 77 4c 78 79 2f 64 41 2b 58 68 42 39 30 zdXwLxy/dA+XhB90 00c0: 6b 2b 36 4e 4a 59 4b 56 2f 6d 73 59 79 41 7a 63 k+6NJYKV/msYyAzc 00d0: 32 45 6a 65 67 6b 55 42 4b 6e 2b 48 62 50 2f 4a 2EjegkUBKn+HbP/J 00e0: 76 6b 43 6a 76 30 76 4a 68 61 4d 6e 46 48 45 2b vkCjv0vJhaMnFHE+ 00f0: 6e 30 57 50 67 6d 77 3d 3d 30 18 0a 01 02 30 13 n0WPgmw==0....0. 0100: 04 09 75 69 64 6e 75 6d 62 65 72 31 06 04 04 31 ..uidnumber1...1 0110: 30 30 30 000 ber_scanf fmt ({e{m[W]}}) ber: ber_dump: buf=0x26c2380 ptr=0x26c23fa end=0x26c24e0 len=230 0000: 30 1e 0a 01 02 30 19 04 0a 6c 6f 67 69 6e 73 68 0....0...loginsh 0010: 65 6c 6c 31 0b 04 09 2f 62 69 6e 2f 62 61 73 68 ell1.../bin/bash 0020: 30 31 0a 01 02 30 2c 04 0b 6f 62 6a 65 63 74 63 01...0,..objectc 0030: 6c 61 73 73 31 1d 04 0d 69 6e 65 74 4f 72 67 50 lass1...inetOrgP 0040: 65 72 73 6f 6e 04 0c 70 6f 73 69 78 41 63 63 6f erson..posixAcco 0050: 75 6e 74 30 77 0a 01 02 30 72 04 0c 75 73 65 72 unt0w...0r..user 0060: 70 61 73 73 77 6f 72 64 31 62 04 60 7b 53 48 41 password1b.`{SHA 0070: 35 31 32 7d 43 78 44 30 42 38 55 45 62 72 4c 5a 512}CxD0B8UEbrLZ 0080: 4f 39 43 7a 64 58 77 4c 78 79 2f 64 41 2b 58 68 O9CzdXwLxy/dA+Xh 0090: 42 39 30 6b 2b 36 4e 4a 59 4b 56 2f 6d 73 59 79 B90k+6NJYKV/msYy 00a0: 41 7a 63 32 45 6a 65 67 6b 55 42 4b 6e 2b 48 62 Azc2EjegkUBKn+Hb 00b0: 50 2f 4a 76 6b 43 6a 76 30 76 4a 68 61 4d 6e 46 P/JvkCjv0vJhaMnF 00c0: 48 45 2b 6e 30 57 50 67 6d 77 3d 3d 30 18 0a 01 HE+n0WPgmw==0... 00d0: 02 30 13 04 09 75 69 64 6e 75 6d 62 65 72 31 06 .0...uidnumber1. 00e0: 04 04 31 30 30 30 ..1000 ber_scanf fmt ({e{m[W]}}) ber: ber_dump: buf=0x26c2380 ptr=0x26c241a end=0x26c24e0 len=198 0000: 30 31 0a 01 02 30 2c 04 0b 6f 62 6a 65 63 74 63 01...0,..objectc 0010: 6c 61 73 73 31 1d 04 0d 69 6e 65 74 4f 72 67 50 lass1...inetOrgP 0020: 65 72 73 6f 6e 04 0c 70 6f 73 69 78 41 63 63 6f erson..posixAcco 0030: 75 6e 74 30 77 0a 01 02 30 72 04 0c 75 73 65 72 unt0w...0r..user 0040: 70 61 73 73 77 6f 72 64 31 62 04 60 7b 53 48 41 password1b.`{SHA 0050: 35 31 32 7d 43 78 44 30 42 38 55 45 62 72 4c 5a 512}CxD0B8UEbrLZ 0060: 4f 39 43 7a 64 58 77 4c 78 79 2f 64 41 2b 58 68 O9CzdXwLxy/dA+Xh 0070: 42 39 30 6b 2b 36 4e 4a 59 4b 56 2f 6d 73 59 79 B90k+6NJYKV/msYy 0080: 41 7a 63 32 45 6a 65 67 6b 55 42 4b 6e 2b 48 62 Azc2EjegkUBKn+Hb 0090: 50 2f 4a 76 6b 43 6a 76 30 76 4a 68 61 4d 6e 46 P/JvkCjv0vJhaMnF 00a0: 48 45 2b 6e 30 57 50 67 6d 77 3d 3d 30 18 0a 01 HE+n0WPgmw==0... 00b0: 02 30 13 04 09 75 69 64 6e 75 6d 62 65 72 31 06 .0...uidnumber1. 00c0: 04 04 31 30 30 30 ..1000 ber_scanf fmt ({e{m[W]}}) ber: ber_dump: buf=0x26c2380 ptr=0x26c244d end=0x26c24e0 len=147 0000: 30 77 0a 01 02 30 72 04 0c 75 73 65 72 70 61 73 0w...0r..userpas 0010: 73 77 6f 72 64 31 62 04 60 7b 53 48 41 35 31 32 sword1b.`{SHA512 0020: 7d 43 78 44 30 42 38 55 45 62 72 4c 5a 4f 39 43 }CxD0B8UEbrLZO9C 0030: 7a 64 58 77 4c 78 79 2f 64 41 2b 58 68 42 39 30 zdXwLxy/dA+XhB90 0040: 6b 2b 36 4e 4a 59 4b 56 2f 6d 73 59 79 41 7a 63 k+6NJYKV/msYyAzc 0050: 32 45 6a 65 67 6b 55 42 4b 6e 2b 48 62 50 2f 4a 2EjegkUBKn+HbP/J 0060: 76 6b 43 6a 76 30 76 4a 68 61 4d 6e 46 48 45 2b vkCjv0vJhaMnFHE+ 0070: 6e 30 57 50 67 6d 77 3d 3d 30 18 0a 01 02 30 13 n0WPgmw==0....0. 0080: 04 09 75 69 64 6e 75 6d 62 65 72 31 06 04 04 31 ..uidnumber1...1 0090: 30 30 30 000 ber_scanf fmt ({e{m[W]}}) ber: ber_dump: buf=0x26c2380 ptr=0x26c24c6 end=0x26c24e0 len=26 0000: 30 18 0a 01 02 30 13 04 09 75 69 64 6e 75 6d 62 0....0...uidnumb 0010: 65 72 31 06 04 04 31 30 30 30 er1...1000 >>> dnPrettyNormal: <uid=atuser,ou=people,dc=vailsys,dc=com> => ldap_bv2dn(uid=atuser,ou=people,dc=vailsys,dc=com,0) <= ldap_bv2dn(uid=atuser,ou=people,dc=vailsys,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=atuser,ou=people,dc=vailsys,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=atuser,ou=people,dc=vailsys,dc=com)=0 <<< dnPrettyNormal: <uid=atuser,ou=people,dc=vailsys,dc=com>, <uid=atuser,ou=people,dc=vailsys,dc=com> conn=1002 op=5 modifications: replace: gidnumber one value, length 4 replace: homedirectory one value, length 19 replace: loginshell one value, length 9 replace: objectclass multiple values replace: userpassword one value, length 96 replace: uidnumber one value, length 4 conn=1002 op=5 MOD dn="uid=atuser,ou=people,dc=vailsys,dc=com" daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL conn=1002 op=5 MOD attr=gidnumber homedirectory loginshell objectclass userpassword uidnumber ndb_back_modify: uid=atuser,ou=people,dc=vailsys,dc=com slap_queue_csn: queing 0x7fe9b3e28c50 20110201224130.989215Z#000000#000#000000 conn=1002 op=4 SEARCH RESULT tag=101 err=0 nentries=0 text= >>> dnNormalize: <cn=admin,dc=vailsys,dc=com> => ldap_bv2dn(cn=admin,dc=vailsys,dc=com,0) <= ldap_bv2dn(cn=admin,dc=vailsys,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=admin,dc=vailsys,dc=com)=0 <<< dnNormalize: <cn=admin,dc=vailsys,dc=com> >>> dnNormalize: <cn=admin,dc=vailsys,dc=com> => ldap_bv2dn(cn=admin,dc=vailsys,dc=com,0) <= ldap_bv2dn(cn=admin,dc=vailsys,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=admin,dc=vailsys,dc=com)=0 <<< dnNormalize: <cn=admin,dc=vailsys,dc=com> ndb_modify_internal: 0x00006d61: uid=atuser,ou=people,dc=vailsys,dc=com <= acl_access_allowed: granted to database root ndb_modify_internal: replace gidNumber ndb_modify_internal: replace homeDirectory ndb_modify_internal: replace loginShell ndb_modify_internal: replace objectClass ndb_modify_internal: replace userPassword ndb_modify_internal: replace uidNumber ndb_modify_internal: replace entryCSN ndb_modify_internal: replace modifiersName ndb_modify_internal: replace modifyTimestamp oc_check_required entry (uid=atuser,ou=people,dc=vailsys,dc=com), objectClass "inetOrgPerson" oc_check_required entry (uid=atuser,ou=people,dc=vailsys,dc=com), objectClass "posixAccount" oc_check_allowed type "sn" oc_check_allowed type "cn" oc_check_allowed type "givenName" oc_check_allowed type "uid" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "gidNumber" oc_check_allowed type "homeDirectory" oc_check_allowed type "loginShell" oc_check_allowed type "objectClass" oc_check_allowed type "userPassword" oc_check_allowed type "uidNumber" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" Segmentation fault (core dumped)

1 0

Re: (ITS#6806) Invalid ldapadd crashes openldap with ndb backend
by anderson＠vailsys.com 01 Feb '11

01 Feb '11

I just ran the tests against a build from head, and we don't see the issue anymore. Thanks, Nathanael On Tue, 2011-02-01 at 12:25 -0800, Howard Chu wrote: > Nathanael Anderson wrote: > > I thought I had attached the backtrace when I opened this, sorry. Here > > is the backtrack from 2.4.23. > > > > Compile Options: ./configure --enable-ndb --enable-passwd > > --enable-modules --enable-slp --enable-crypt --enable-overlays > > --enable-dynamic --enable-syslog --enable-debug --enable-auditlog > > --disable-cleartext --enable-wrappers --enable-ppolicy > > > > mysql-cluster-gpl-7.1.9a binary distribution from oracle. > > > > Line 339 in NdbTransaction.cpp didn't refer to a file that I saw. Let me > > know if anything else is needed. > > Thanks, that helped. This is now fixed in HEAD. > > > > > > #0 NdbTransaction::execute (this=0x7fa1ae235659, > > aTypeOfExec=NdbTransaction::Rollback, > > abortOption=NdbOperation::DefaultAbortOption, forceSend=0) > > at NdbTransaction.cpp:339 > > 339 NdbTransaction.cpp: No such file or directory. > > in NdbTransaction.cpp > > (gdb) bt > > #0 NdbTransaction::execute (this=0x7fa1ae235659, > > aTypeOfExec=NdbTransaction::Rollback, > > abortOption=NdbOperation::DefaultAbortOption, forceSend=0) > > at NdbTransaction.cpp:339 > > #1 0x00000000004f8608 in ndb_back_add () > > #2 0x000000000043ce34 in fe_op_add () > > #3 0x000000000043d695 in do_add () > > #4 0x0000000000435dd9 in ?? () > > #5 0x000000000043662d in ?? () > > #6 0x00007fa1b0f43538 in ldap_int_thread_pool_wrapper (xpool=<value > > optimized out>) at tpool.c:685 > > #7 0x00007fa1af7729ca in start_thread () from /lib/libpthread.so.0 > > #8 0x00007fa1ae27a70d in clone () from /lib/libc.so.6 > > #9 0x0000000000000000 in ?? () > > > >> As always, when you get a core dump, post the gdb backtrace of the dump. Use > >> the most recent release version, and make sure you use a non-optimized debug > >> build with all debug symbols intact. All of these instructions are written on > >> the page where you submit new Issues. > >> > > > > > > > >

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by hyc＠symas.com 01 Feb '11

01 Feb '11

Timo Aaltonen wrote: > On Thu, 20 Jan 2011, Howard Chu wrote: > >> timo.aaltonen(a)aalto.fi wrote: >>> Hi >>> >>> Here's some information that Stephen asked would be of use. There is >>> one forest, one domain, but three sites in the layout. The functional >>> level of the forest and the domain is W2008, but the servers have 2008R2. >>> >>> And the full backtrace of the hung process: >> >>> #3 0x00007f8f652f3bcb in ldap_pvt_thread_mutex_lock >>> (mutex=0x7f8f6553fc80) >>> at /tmp/buildd/openldap-2.4.23/libraries/libldap_r/thr_posix.c:296 >>> No locals. >>> #4 0x00007f8f653010bf in ldap_sasl_interactive_bind_s (ld=0x2117c20, >>> dn=0x0, >>> mechs=0x210d530 "GSSAPI", serverControls=0x0, clientControls=0x0, >>> flags=2, >>> interact=0x7f8f61405120<sdap_sasl_interact>, defaults=0x2124a50) at >>> sasl.c:426 >>> rc = -1921681294 >>> smechs = 0x0 >> >> This particular mutex seems kind of bogus to me; the code is from rev 1.31 in >> June 2001. Perhaps back then it was unsafe to have multiple SASL operations >> outstanding at once; I would expect that was only an issue in the Cyrus 1.5 >> days and it should be safe now with Cyrus 2.x. We should probably just delete >> this mutex. > > Ok, so by doing this: > > --- openldap-2.4.23.orig/libraries/libldap/sasl.c > +++ openldap-2.4.23/libraries/libldap/sasl.c > @@ -421,10 +421,11 @@ > { > int rc; > char *smechs = NULL; > - > +/* > #if defined( LDAP_R_COMPILE )&& defined( HAVE_CYRUS_SASL ) > ldap_pvt_thread_mutex_lock(&ldap_int_sasl_mutex ); > #endif > +*/ > #ifdef LDAP_CONNECTIONLESS > if( LDAP_IS_UDP(ld) ) { > /* Just force it to simple bind, silly to make the user > > -- > > .. the process doesn't hang anymore. But it still doesn't do what it's > supposed to, but that could be a bug in SSSD. I'll investigate further. > > Thanks! > As I noted in a previous followup, it's not clear to me that the Cyrus SASL library is actually safe to use without that mutex. Also, going through your provided backtraces, I see the real issue is that two different requests were active at the same time. I.e., there was an active request that triggered a referral, and an unrelated request. You would also have avoided this issue if you waited for the request that triggered the referrals to complete before issuing any other requests. -- -- 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#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by hyc＠symas.com 01 Feb '11

01 Feb '11

Kartik Subbarao wrote: > On 01/28/2011 08:27 PM, Howard Chu wrote: >>> I'm running into multiple problems here. The core problem seems to be >>> that enabling ppolicy_forward_updates breaks the chaining overlay such that >>> it binds anonymously instead of with SASL EXTERNAL. >> >> That's because your authz-regexp is wrong. You mapped "cn=localhost" but >> when using SASL EXTERNAL, the user's DN is the complete certificate DN. >> In your case, "cn=localhost,o=OpenLDAP,st=Some-State,c=US" >> >> The reason this didn't break replication is because in this test, >> everything has anonymous read access so the consumer was able to pull >> what it needed. > > Hmm, I'm not quite seeing what you're saying here. For example, in > slapd.1.log, *before* ppolicy_forward_updates (olcPPolicyForwardUpdates) > is enabled, I can see the certificate being mapped exactly as I expect it: OK, that's probably a red herring. With your updated cert, I see two issues from the logs - 1) since ppolicy uses the database rootdn to perform the pwdFailuretime update, this is considered a privileged connection. Note from the slapd-ldap(5) manpage that acl-bind is used for root/privileged connections. Your idassert-bind directive had no effect here. The TLS session failed because the acl-bind context had no CA cert configured. Adding an appropriate olcDbACLBind directive got past this issue. 2) since pwdFailuretime is an operational attribute, you need to have manage privilege to update it. With (1) fixed the modify is correctly chained to the provider, but the provider rejects it with Insufficient Access. Changing the ACL in slapd-ppolicy.conf to grant "manage' instead of "write" access fixes that. With both of those corrections, your test script succeeds. Closing this ITS as user config error, there is no software bug here. > > ===== > ==> rewrite_context_apply [depth=1] res={0,'cn=localhost,dc=example,dc=com'} > [rw] authid: "cn=localhost,o=openldap,st=some-state,c=us" -> > "cn=localhost,dc=example,dc=com" > [...] > <==slap_sasl2dn: Converted SASL name to cn=localhost,dc=example,dc=com > slap_sasl_getdn: dn:id converted to cn=localhost,dc=example,dc=com > SASL Canonicalize [conn=1004]: slapAuthcDN="cn=localhost,dc=example,dc=com" > SASL proxy authorize [conn=1004]: > authcid="cn=localhost,o=openldap,st=some-state,c=us" > authzid="cn=localhost,o=openldap,st=some-state,c=us" > conn=1004 op=1 BIND authcid="cn=localhost,o=openldap,st=some-state,c=us" > authzid="cn=localhost,o=openldap,st=some-state,c=us" > SASL Authorize [conn=1004]: proxy authorization allowed authzDN="" > send_ldap_sasl: err=0 len=-1 > conn=1004 op=1 BIND dn="cn=localhost,dc=example,dc=com" mech=EXTERNAL > sasl_ssf=0 ssf=256 > do_bind: SASL/EXTERNAL bind: dn="cn=localhost,dc=example,dc=com" sasl_ssf=0 > ===== > > Based on this, I'm assuming that my authz-regexp is behaving as I'm > intending -- looking for a certificate with "cn=localhost" anywhere in > the subject DN, and mapping that to the DN > cn=localhost,dc=example,dc=com in the directory. > > It's only *after* olcPPolicyForwardUpdates is enabled that the SASL > EXTERNAL authentication stops working. > > Can you help me understand the disconnect between what I'm seeing and > what you're saying? > >> I didn't get this far because your test certificate is now expired. I >> guess I can substitute some other certs and look at it again, but I >> think the core issue is your misconfigured authz-regexp. > > I have updated the expiration date on the certificate and have attached > it to this message. > >> Better to rename your scripts when you modify one of our existing ones. >> E.g. test999-xxxxxx and just create new data files instead of modifying >> ours. > > Ok, will keep this in mind. > > Thanks, > > -Kartik > > > localhost.crt > > > -----BEGIN CERTIFICATE----- > MIICCTCCAXICCQC1gKCIQ2we4DANBgkqhkiG9w0BAQUFADBJMQswCQYDVQQGEwJV > UzETMBEGA1UECBMKU29tZS1TdGF0ZTERMA8GA1UEChMIT3BlbkxEQVAxEjAQBgNV > BAMTCWxvY2FsaG9zdDAeFw0xMTAxMzExNjE1NTdaFw0xMjAxMzExNjE1NTdaMEkx > CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpTb21lLVN0YXRlMREwDwYDVQQKEwhPcGVu > TERBUDESMBAGA1UEAxMJbG9jYWxob3N0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB > iQKBgQCqZU3fA/o/y5gHXxm0JpdMoV64LAOIPgcZTHv4+OkVjoW2gMHT8AMerJzk > Cr07y1JjfeqV1c7sZl6+aqC3H+HLs0cCtXFKPFY9FmoehO9KBksDaH5o2f7h104r > s/xg2cNTDy1dFFJUzMWQIc8TU7+GpjS3gP0/9gNlIyiLdio9LwIDAQABMA0GCSqG > SIb3DQEBBQUAA4GBAGFeVSjX4ZjLmrU7oob4CyoWO2ekeVyldWLjVOUCyeSMae3n > I1/kQ5AbGrJdtQQeLyRhIQKUM2a1AqjPLW1QKPXHnHnbsnzuWmC2C9fIw1C3o0yZ > UBsxlqoA7K486qeyAb6bUO5X2JD2rOng+HL/pgKlo9h8dW23tWj4CEUMepOh > -----END CERTIFICATE----- -- -- 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#6806) Invalid ldapadd crashes openldap with ndb backend
by hyc＠symas.com 01 Feb '11

01 Feb '11

Nathanael Anderson wrote: > I thought I had attached the backtrace when I opened this, sorry. Here > is the backtrack from 2.4.23. > > Compile Options: ./configure --enable-ndb --enable-passwd > --enable-modules --enable-slp --enable-crypt --enable-overlays > --enable-dynamic --enable-syslog --enable-debug --enable-auditlog > --disable-cleartext --enable-wrappers --enable-ppolicy > > mysql-cluster-gpl-7.1.9a binary distribution from oracle. > > Line 339 in NdbTransaction.cpp didn't refer to a file that I saw. Let me > know if anything else is needed. Thanks, that helped. This is now fixed in HEAD. > > > #0 NdbTransaction::execute (this=0x7fa1ae235659, > aTypeOfExec=NdbTransaction::Rollback, > abortOption=NdbOperation::DefaultAbortOption, forceSend=0) > at NdbTransaction.cpp:339 > 339 NdbTransaction.cpp: No such file or directory. > in NdbTransaction.cpp > (gdb) bt > #0 NdbTransaction::execute (this=0x7fa1ae235659, > aTypeOfExec=NdbTransaction::Rollback, > abortOption=NdbOperation::DefaultAbortOption, forceSend=0) > at NdbTransaction.cpp:339 > #1 0x00000000004f8608 in ndb_back_add () > #2 0x000000000043ce34 in fe_op_add () > #3 0x000000000043d695 in do_add () > #4 0x0000000000435dd9 in ?? () > #5 0x000000000043662d in ?? () > #6 0x00007fa1b0f43538 in ldap_int_thread_pool_wrapper (xpool=<value > optimized out>) at tpool.c:685 > #7 0x00007fa1af7729ca in start_thread () from /lib/libpthread.so.0 > #8 0x00007fa1ae27a70d in clone () from /lib/libc.so.6 > #9 0x0000000000000000 in ?? () > >> As always, when you get a core dump, post the gdb backtrace of the dump. Use >> the most recent release version, and make sure you use a non-optimized debug >> build with all debug symbols intact. All of these instructions are written on >> the page where you submit new Issues. >> > > > -- -- 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#6820) void functions with return's
by masarati＠aero.polimi.it 01 Feb '11

01 Feb '11

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: RE24 > OS: irrelevant > URL: > Submission from: (NULL) (128.6.31.135) > > > ITS # 6814 patch has a couple void functions with returns; that's not legal. > Patch below. > > I also note that it looks like some functions are missing prototypes in RE24. > That's only a warning to most compilers, but it might be nice to address that > too. > > --- servers/slapd/filter.c~ 2011-02-01 11:34:06.062872000 -0500 > +++ servers/slapd/filter.c 2011-02-01 11:34:16.721012000 -0500 > @@ -586,7 +586,7 @@ > void > filter2bv_x( Operation *op, Filter *f, struct berval *fstr ) > { > - return filter2bv_undef_x( op, f, 0, fstr ); > + filter2bv_undef_x( op, f, 0, fstr ); > } > > void > @@ -848,7 +848,7 @@ > void > filter2bv( Filter *f, struct berval *fstr ) > { > - return filter2bv_undef( f, 0, fstr ); > + filter2bv_undef( f, 0, fstr ); > } My fault, sorry. Thanks, p.

1 0

(ITS#6820) void functions with return's
by richton＠nbcs.rutgers.edu 01 Feb '11

01 Feb '11

Full_Name: Aaron Richton Version: RE24 OS: irrelevant URL: Submission from: (NULL) (128.6.31.135) ITS # 6814 patch has a couple void functions with returns; that's not legal. Patch below. I also note that it looks like some functions are missing prototypes in RE24. That's only a warning to most compilers, but it might be nice to address that too. --- servers/slapd/filter.c~ 2011-02-01 11:34:06.062872000 -0500 +++ servers/slapd/filter.c 2011-02-01 11:34:16.721012000 -0500 @@ -586,7 +586,7 @@ void filter2bv_x( Operation *op, Filter *f, struct berval *fstr ) { - return filter2bv_undef_x( op, f, 0, fstr ); + filter2bv_undef_x( op, f, 0, fstr ); } void @@ -848,7 +848,7 @@ void filter2bv( Filter *f, struct berval *fstr ) { - return filter2bv_undef( f, 0, fstr ); + filter2bv_undef( f, 0, fstr ); } void

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by marco.pizzoli＠gmail.com 01 Feb '11

01 Feb '11

--000e0cd29c8c81d269049b3a8b9d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok, I re-downloaded the source tree and now the accesslog.c file is updated= . I started the daemon and tomorrow I will re-try the drop/import. Thanks Marco Pizzoli On Tue, Feb 1, 2011 at 4:41 PM, Hallvard B Furuseth < h.b.furuseth(a)usit.uio.no> wrote: > marco.pizzoli(a)gmail.com writes: > > I downloaded the HEAD repository, compiled and tried the import. Same > > problem on the same line. > > (...) > > Had I downloaded the wrong repository? > > Probably not, but you can check CVS/Root - it should contain > :pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP > > However, try again now. The public CVS repository it is regularly > synced with the main repository, but you may have updated from it > before the patch reached it. > > > I went to see the version of the source accesslog.c and saw this line o= n > top > > of it: > > /* accesslog.c - log operations for audit/history purposes */ > > /* $OpenLDAP: pkg/ldap/servers/slapd/overlays/accesslog.c,v 1.37.2.34 * > > 2011/01/26* 23:23:34 quanah Exp $ */ > > That from the release branch, which has not merged this patch. > > HEAD is the main branch used for development, currently with accesslog > 1.115. > > -- > Hallvard > --=20 _________________________________________ Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison --000e0cd29c8c81d269049b3a8b9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok, I re-downloaded the source tree and now the accesslog.c file is updated= .<br><br>I started the daemon and tomorrow I will re-try the drop/import.<b= r><br>Thanks<br>=A0=A0=A0=A0=A0 Marco Pizzoli<br><br><div class=3D"gmail_qu= ote">On Tue, Feb 1, 2011 at 4:41 PM, Hallvard B Furuseth <span dir=3D"ltr">= <<a href=3D"mailto:h.b.furuseth@usit.uio.no">h.b.furuseth(a)usit.uio.no</a= >></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class=3D"im"= ><a href=3D"mailto:marco.pizzoli@gmail.com">marco.pizzoli(a)gmail.com</a> wri= tes:<br> > I downloaded the HEAD repository, compiled and tried the import. Same<= br> > problem on the same line.<br> </div>> (...)<br> <div class=3D"im">> Had I downloaded the wrong repository?<br> <br> </div>Probably not, but you can check CVS/Root - it should contain<br> =A0 =A0 =A0 =A0:pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP<br> <br> However, try again now. =A0The public CVS repository it is regularly<br> synced with the main repository, but you may have updated from it<br> before the patch reached it.<br> <div class=3D"im"><br> > I went to see the version of the source accesslog.c and saw this line = on top<br> > of it:<br> > /* accesslog.c - log operations for audit/history purposes */<br> > /* $OpenLDAP: pkg/ldap/servers/slapd/overlays/accesslog.c,v 1.37.2.34 = *<br> > 2011/01/26* 23:23:34 quanah Exp $ */<br> <br> </div>That from the release branch, which has not merged this patch.<br> <br> HEAD is the main branch used for development, currently with accesslog<br> 1.115.<br> <br> --<br> <font color=3D"#888888">Hallvard<br> </font></blockquote></div><br><br clear=3D"all"><br>-- <br>________________= _________________________<br>Non =E8 forte chi non cade, ma chi cadendo ha = la forza di rialzarsi.<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jim Morri= son<br> <div style=3D"visibility: hidden; left: -5000px; position: absolute; z-inde= x: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden;= word-wrap: break-word; color: black; font-size: 10px; text-align: left; li= ne-height: 130%;" id=3D"avg_ls_inline_popup"> </div> --000e0cd29c8c81d269049b3a8b9d--

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by h.b.furuseth＠usit.uio.no 01 Feb '11

01 Feb '11

masarati(a)aero.polimi.it writes: > Sorry, I overlooked part of your message. And I was too tired to read it right too:-) Need to get the right branch at least. I was thinking of the version at shown at cvsweb, which showed that one first. -- Hallvard

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by h.b.furuseth＠usit.uio.no 01 Feb '11

01 Feb '11

marco.pizzoli(a)gmail.com writes: > I downloaded the HEAD repository, compiled and tried the import. Same > problem on the same line. > (...) > Had I downloaded the wrong repository? Probably not, but you can check CVS/Root - it should contain :pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP However, try again now. The public CVS repository it is regularly synced with the main repository, but you may have updated from it before the patch reached it. > I went to see the version of the source accesslog.c and saw this line on top > of it: > /* accesslog.c - log operations for audit/history purposes */ > /* $OpenLDAP: pkg/ldap/servers/slapd/overlays/accesslog.c,v 1.37.2.34 * > 2011/01/26* 23:23:34 quanah Exp $ */ That from the release branch, which has not merged this patch. HEAD is the main branch used for development, currently with accesslog 1.115. -- Hallvard

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by masarati＠aero.polimi.it 01 Feb '11

01 Feb '11

Marco Pizzoli wrote: > Hi, > I downloaded the HEAD repository, compiled and tried the import. Same > problem on the same line. > > I went to see the version of the source accesslog.c and saw this line on top > of it: > /* accesslog.c - log operations for audit/history purposes */ > /* $OpenLDAP: pkg/ldap/servers/slapd/overlays/accesslog.c,v 1.37.2.34 * > 2011/01/26* 23:23:34 quanah Exp $ */ > > Had I downloaded the wrong repository? Sorry, I overlooked part of your message. Yes, you appear to be using the wrong repository. My commit resulted in accesslog.c 1.115. p.

1 0

Re: ITS#6815
by marco.pizzoli＠gmail.com 01 Feb '11

01 Feb '11

--001636e0a68c56af9b049b3a400d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, yes but not all my clients are so flexible. A helpful usage, in my deploy, would be in populating a database with only BIND operations. By now this is not possible. Thanks Marco Pizzoli On Sun, Jan 30, 2011 at 9:12 PM, <masarati(a)aero.polimi.it> wrote: > > This request is spotted by some ldap clients that I have that every > > 30seconds do a dummy ldap search only to keep alive their connection > > to the ldap server. These searches are frequent and I have many of > > these clients in my deploy, so my accesslog become full of not > > significant entries. > > For this specific purpose, your clients could perform an operation that i= s > not logged; for example, search the rootDSE. > > p. > > --=20 _________________________________________ Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison --001636e0a68c56af9b049b3a400d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, <br>yes but not all my clients are so flexible.<br><br>A helpful usage,= in my deploy, would be in populating a database with only BIND operations.= By now this is not possible.<br><br>Thanks<br>=A0=A0=A0=A0=A0 Marco Pizzol= i<br><br> <div class=3D"gmail_quote">On Sun, Jan 30, 2011 at 9:12 PM, <span dir=3D"l= tr"><<a href=3D"mailto:masarati@aero.polimi.it">masarati(a)aero.polimi.it<= /a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:= 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left= : 1ex;"> > This request is spotted by some ldap clients that I have that every<br= > > 30seconds do a dummy ldap search only to keep alive their connection<b= r> > to the ldap server. These searches are frequent and I have many of<br> > these clients in my deploy, so my accesslog become full of not<br> > significant entries.<br> <br> For this specific purpose, your clients could perform an operation that is<= br> not logged; for example, search the rootDSE.<br> <br> p.<br> <br> </blockquote></div><br><br clear=3D"all"><br>-- <br>_______________________= __________________<br>Non =E8 forte chi non cade, ma chi cadendo ha la forz= a di rialzarsi.<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jim Morrison<br> <div style=3D"visibility: hidden; left: -5000px; position: absolute; z-inde= x: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden;= word-wrap: break-word; color: black; font-size: 10px; text-align: left; li= ne-height: 130%;" id=3D"avg_ls_inline_popup"> </div> --001636e0a68c56af9b049b3a400d--

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by masarati＠aero.polimi.it 01 Feb '11

01 Feb '11

Marco Pizzoli wrote: > Hi, > I downloaded the HEAD repository, compiled and tried the import. Same > problem on the same line. The fix in HEAD fixes the writing of the accesslog entry; you need to try it with a new search on a fresh database, then a slapcat, then a slapadd. Old databases and LDIFs are corrupted and need to be fixed otherwise (e.g. ldapmodify->replace of the reqAttr without the empty value, which is invalid per LDAPString syntax. p.

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by marco.pizzoli＠gmail.com 01 Feb '11

01 Feb '11

--000e0cd29c8c87a456049b38f23c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I downloaded the HEAD repository, compiled and tried the import. Same problem on the same line. I went to see the version of the source accesslog.c and saw this line on to= p of it: /* accesslog.c - log operations for audit/history purposes */ /* $OpenLDAP: pkg/ldap/servers/slapd/overlays/accesslog.c,v 1.37.2.34 * 2011/01/26* 23:23:34 quanah Exp $ */ Had I downloaded the wrong repository? Thanks Marco Pizzoli On Tue, Feb 1, 2011 at 1:10 PM, Pierangelo Masarati <masarati(a)aero.polimi.i= t > wrote: > Marco Pizzoli wrote: > >> Hi, >> the (same?) problem arises again. >> >> I downloaded the upgraded source, created a new accesslog and today trie= d >> to >> slapcat/drop/slapadd. >> This is the error that I'm encountering: >> >> [ldap@ldap03 db_log]$ time /usr/local/openldap/sbin/slapadd -b >> "cn=3Dlog03,dc=3D >> mycorp.it" -l dump_ldap_dblog_20110201.ldif >> .### 17.14% eta 01h17m elapsed 15m56s spd 443= .0 >> k/s str2entry: invalid value for attributeType reqAttr #1 (syntax >> 1.3.6.1.4.1.1466.115.121.1.15) >> slapadd: could not parse entry (line=3D13502606) >> _### 17.14% eta 01h17m elapsed 15m56s spd 330= .0 >> k/s >> Closing DB... >> >> The corrupted entry is: >> >> dn: reqStart=3D20110128141509.000004Z,cn=3Dlog03,dc=3Dmycorp.it >> objectClass: auditSearch >> structuralObjectClass: auditSearch >> reqStart: 20110128141509.000004Z >> reqEnd: 20110128141510.000000Z >> reqType: search >> reqSession: 6521 >> reqAuthzID: cn=3DManager,dc=3Dmyregion,dc=3Dmycorp.it >> reqDN: uid=3Dpe1748,ou=3DPeople,dc=3Dmyregion,dc=3Dmycorp.it >> reqResult: 0 >> reqScope: base >> reqDerefAliases: never >> reqAttrsOnly: FALSE >> reqFilter: (&(objectClass=3D*)) >> reqAttr: * >> reqAttr: >> reqEntries: 1 >> reqTimeLimit: -1 >> reqSizeLimit: 500 >> entryUUID: c18cf535-bbbd-4a0c-b5bb-848da7e39dbf >> creatorsName: cn=3DManager,cn=3Dlog03,dc=3Dmycorp.it >> createTimestamp: 20110128141510Z >> entryCSN: 20110128141510.000116Z#000000#003#000000 >> modifiersName: cn=3DManager,cn=3Dlog03,dc=3Dmycorp.it >> modifyTimestamp: 20110128141510Z >> > > A fix is in HEAD (ITS#6819); more is coming. Please test. Thanks, p. > --=20 _________________________________________ Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison --000e0cd29c8c87a456049b38f23c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,<br>I downloaded the HEAD repository, compiled and tried the import. Sam= e problem on the same line.<br><br>I went to see the version of the source = accesslog.c and saw this line on top of it:<br>/* accesslog.c - log operati= ons for audit/history purposes */<br> /* $OpenLDAP: pkg/ldap/servers/slapd/overlays/accesslog.c,v 1.37.2.34 <b>20= 11/01/26</b> 23:23:34 quanah Exp $ */<br><br>Had I downloaded the wrong rep= ository?<br><br>Thanks<br>=A0=A0=A0=A0=A0 Marco Pizzoli<br><br><br><div cla= ss=3D"gmail_quote"> On Tue, Feb 1, 2011 at 1:10 PM, Pierangelo Masarati <span dir=3D"ltr"><<= a href=3D"mailto:masarati@aero.polimi.it">masarati(a)aero.polimi.it</a>></= span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt = 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div><div></div><div class=3D"h5">Marco Pizzoli wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Hi,<br> the (same?) problem arises again.<br> <br> I downloaded the upgraded source, created a new accesslog and today tried t= o<br> slapcat/drop/slapadd.<br> This is the error that I'm encountering:<br> <br> [ldap@ldap03 db_log]$ time /usr/local/openldap/sbin/slapadd -b "cn=3Dl= og03,dc=3D<br> <a href=3D"http://mycorp.it" target=3D"_blank">mycorp.it</a>" -l dump_= ldap_dblog_20110201.ldif<br> .### =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 17.14% eta 01h17m elapsed =A0 =A0 = =A0 =A0 =A015m56s spd 443.0<br> k/s str2entry: invalid value for attributeType reqAttr #1 (syntax<br> 1.3.6.1.4.1.1466.115.121.1.15)<br> slapadd: could not parse entry (line=3D13502606)<br> _### =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 17.14% eta 01h17m elapsed =A0 =A0 = =A0 =A0 =A015m56s spd 330.0<br> k/s<br> Closing DB...<br> <br> The corrupted entry is:<br> <br> dn: reqStart=3D20110128141509.000004Z,cn=3Dlog03,dc=3D<a href=3D"http://myc= orp.it" target=3D"_blank">mycorp.it</a><br> objectClass: auditSearch<br> structuralObjectClass: auditSearch<br> reqStart: 20110128141509.000004Z<br> reqEnd: 20110128141510.000000Z<br> reqType: search<br> reqSession: 6521<br> reqAuthzID: cn=3DManager,dc=3Dmyregion,dc=3D<a href=3D"http://mycorp.it" ta= rget=3D"_blank">mycorp.it</a><br> reqDN: uid=3Dpe1748,ou=3DPeople,dc=3Dmyregion,dc=3D<a href=3D"http://mycorp= .it" target=3D"_blank">mycorp.it</a><br> reqResult: 0<br> reqScope: base<br> reqDerefAliases: never<br> reqAttrsOnly: FALSE<br> reqFilter: (&(objectClass=3D*))<br> reqAttr: *<br> reqAttr:<br> reqEntries: 1<br> reqTimeLimit: -1<br> reqSizeLimit: 500<br> entryUUID: c18cf535-bbbd-4a0c-b5bb-848da7e39dbf<br> creatorsName: cn=3DManager,cn=3Dlog03,dc=3D<a href=3D"http://mycorp.it" tar= get=3D"_blank">mycorp.it</a><br> createTimestamp: 20110128141510Z<br> entryCSN: 20110128141510.000116Z#000000#003#000000<br> modifiersName: cn=3DManager,cn=3Dlog03,dc=3D<a href=3D"http://mycorp.it" ta= rget=3D"_blank">mycorp.it</a><br> modifyTimestamp: 20110128141510Z<br> </blockquote> <br></div></div> A fix is in HEAD (ITS#6819); more is coming. =A0Please test. =A0Thanks, p.<= br> </blockquote></div><br><br clear=3D"all"><br>-- <br>_______________________= __________________<br>Non =E8 forte chi non cade, ma chi cadendo ha la forz= a di rialzarsi.<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jim Morrison<br> <div style=3D"visibility: hidden; left: -5000px; position: absolute; z-inde= x: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden;= word-wrap: break-word; color: black; font-size: 10px; text-align: left; li= ne-height: 130%;" id=3D"avg_ls_inline_popup"> </div> --000e0cd29c8c87a456049b38f23c--

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by masarati＠aero.polimi.it 01 Feb '11

01 Feb '11

Marco Pizzoli wrote: > Hi, > the (same?) problem arises again. > > I downloaded the upgraded source, created a new accesslog and today tried to > slapcat/drop/slapadd. > This is the error that I'm encountering: > > [ldap@ldap03 db_log]$ time /usr/local/openldap/sbin/slapadd -b "cn=log03,dc= > mycorp.it" -l dump_ldap_dblog_20110201.ldif > .### 17.14% eta 01h17m elapsed 15m56s spd 443.0 > k/s str2entry: invalid value for attributeType reqAttr #1 (syntax > 1.3.6.1.4.1.1466.115.121.1.15) > slapadd: could not parse entry (line=13502606) > _### 17.14% eta 01h17m elapsed 15m56s spd 330.0 > k/s > Closing DB... > > The corrupted entry is: > > dn: reqStart=20110128141509.000004Z,cn=log03,dc=mycorp.it > objectClass: auditSearch > structuralObjectClass: auditSearch > reqStart: 20110128141509.000004Z > reqEnd: 20110128141510.000000Z > reqType: search > reqSession: 6521 > reqAuthzID: cn=Manager,dc=myregion,dc=mycorp.it > reqDN: uid=pe1748,ou=People,dc=myregion,dc=mycorp.it > reqResult: 0 > reqScope: base > reqDerefAliases: never > reqAttrsOnly: FALSE > reqFilter: (&(objectClass=*)) > reqAttr: * > reqAttr: > reqEntries: 1 > reqTimeLimit: -1 > reqSizeLimit: 500 > entryUUID: c18cf535-bbbd-4a0c-b5bb-848da7e39dbf > creatorsName: cn=Manager,cn=log03,dc=mycorp.it > createTimestamp: 20110128141510Z > entryCSN: 20110128141510.000116Z#000000#003#000000 > modifiersName: cn=Manager,cn=log03,dc=mycorp.it > modifyTimestamp: 20110128141510Z A fix is in HEAD (ITS#6819); more is coming. Please test. Thanks, p.

1 0

(ITS#6819) invalid attributes in search request
by masarati＠aero.polimi.it 01 Feb '11

01 Feb '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.200) Submitted by: ando As per RFC4511 we ignore unknown attributes in search requests, and we handle special attributes according to RFC 3673 and RFC 4529; however we probably should ignore and discard invalid attributes (i.e. attributes not conforming to section 2.5. of RFC4512). A noteworthy example is that right now slapd accepts "" (the empty string). Although there is no strong motivation for discarding non conforming requests (and, as per RFC 3673 and RFC 4529, the production attributeSelector of Section 4.5.1.8. of RFC 4511 had to be extended, so this code should be updated whenever that production is modified further), I think this change would be in the spirit of OpenLDAP's slapd (i.e. liberal in accepting requests with invalid productions, but strict in not letting them proceed further). One case where an invalid production is causing problems downstream is in accesslog, where the empty string is written as the value of a reqAttr, which is invalid per the syntax of reqAttr which is an LDAPString. As a consequence, a slapcat of such an accesslog entry cannot be reloaded. I am fixing accesslog otherwise, but probably invalid attributeselectors should be filtered out when parsing search requests. p.

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by masarati＠aero.polimi.it 01 Feb '11

01 Feb '11

Marco Pizzoli wrote: > Hi, > the (same?) problem arises again. > > I downloaded the upgraded source, created a new accesslog and today tried to > slapcat/drop/slapadd. > This is the error that I'm encountering: > > [ldap@ldap03 db_log]$ time /usr/local/openldap/sbin/slapadd -b "cn=log03,dc= > mycorp.it" -l dump_ldap_dblog_20110201.ldif > .### 17.14% eta 01h17m elapsed 15m56s spd 443.0 > k/s str2entry: invalid value for attributeType reqAttr #1 (syntax > 1.3.6.1.4.1.1466.115.121.1.15) > slapadd: could not parse entry (line=13502606) > _### 17.14% eta 01h17m elapsed 15m56s spd 330.0 > k/s > Closing DB... > > The corrupted entry is: > > dn: reqStart=20110128141509.000004Z,cn=log03,dc=mycorp.it > objectClass: auditSearch > structuralObjectClass: auditSearch > reqStart: 20110128141509.000004Z > reqEnd: 20110128141510.000000Z > reqType: search > reqSession: 6521 > reqAuthzID: cn=Manager,dc=myregion,dc=mycorp.it > reqDN: uid=pe1748,ou=People,dc=myregion,dc=mycorp.it > reqResult: 0 > reqScope: base > reqDerefAliases: never > reqAttrsOnly: FALSE > reqFilter: (&(objectClass=*)) > reqAttr: * > reqAttr: > reqEntries: 1 > reqTimeLimit: -1 > reqSizeLimit: 500 > entryUUID: c18cf535-bbbd-4a0c-b5bb-848da7e39dbf > creatorsName: cn=Manager,cn=log03,dc=mycorp.it > createTimestamp: 20110128141510Z > entryCSN: 20110128141510.000116Z#000000#003#000000 > modifiersName: cn=Manager,cn=log03,dc=mycorp.it > modifyTimestamp: 20110128141510Z I've found that a search for '*' does generate a log with only one reqAttr value, reqAttr: * However a search for '*' '' (the empty string) actually generates a log like the one you posted. I'll fix this, but in the meanwhile you should fix your client. p.

1 0

Re: (ITS#6818) back-meta: do not denormalize attrs without equality rule
by masarati＠aero.polimi.it 01 Feb '11

01 Feb '11

h.b.furuseth(a)usit.uio.no wrote: > masarati(a)aero.polimi.it writes: >> Subject: (ITS#6818) back-meta: do not denormalize attrs without equality rule > > Is this denormalizion a user-visible or internal matter? AFAIK it's about generating a printable form of some normal forms, e.g. UUIDs. It's used very seldom, but for some reasons that bit of code assumed an EQUALITY rule was present, and I ran into that after enabling undefined attr filters to be saved in Filter structures for logging purposes (ava.c 1.53 -> 1.54). I don't think the user needs to be aware of that. p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs