- openldap-bugs - openldap.org

Re: (ITS#6625) draft-zeilenga-ldap-c-api-concurrency support
by doug.leavitt＠oracle.com 06 Feb '11

06 Feb '11

For the record. slapd-mtread.c started as a copy of slapd-read.c from the same source directory, and then minor modifications were incorporated into slapd-mtread.c to allow the code to perform specific MT operations. This was done to preserve the integrity of the existing test suite and all the existing test cases that already use slapd-read.c. Technically the original author is also the original author of slapd-read.c Doug Leavitt Oracle Corporation

1 0

Re: (ITS#6826) Apache htpasswd MD5 support [patch]
by hyc＠symas.com 06 Feb '11

06 Feb '11

djpohly(a)gmail.com wrote: > Alright, I have created a file contrib/slapd-modules/passwd/apr1.c which > implements this hash: > > http://openldap.pastebin.com/r2GzfveB > > I have tested it and confirmed that it works on several passwords > converted from an htpasswd file using the atol.pl script above. Thanks, added to HEAD with additional changes. -- -- 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#6826) Apache htpasswd MD5 support [patch]
by djpohly＠gmail.com 06 Feb '11

06 Feb '11

Alright, I have created a file contrib/slapd-modules/passwd/apr1.c which implements this hash: http://openldap.pastebin.com/r2GzfveB I have tested it and confirmed that it works on several passwords converted from an htpasswd file using the atol.pl script above.

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by michael＠stroeder.com 05 Feb '11

05 Feb '11

This is a multi-part message in MIME format. --------------010407040507050306070700 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit hyc(a)symas.com wrote: > 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. Also in RE24. Thanks a lot! Any objections adding a slightly more complete Makefile (see attachment)? Ciao, Michael. --------------010407040507050306070700 Content-Type: text/plain; name="Makefile.lastbind" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Makefile.lastbind" # Copyright 2009 Jonathan Clarke <jonathan(a)phillipoux.net>. # 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>. PREFIX=/opt/openldap-RE24 CPPFLAGS+=-I../../../include -I../../../servers/slapd CPPFLAGS+=-DSLAPD_OVER_LASTBIND=SLAPD_MOD_DYNAMIC #LIBTOOL=libtool LIBTOOL=../../../libtool OPT=-g -O2 CC=gcc all: lastbind.la lastbind.lo: lastbind.c $(LIBTOOL) --mode=compile $(CC) $(CPPFLAGS) -Wall -c $? lastbind.la: lastbind.lo $(LIBTOOL) --mode=link $(CC) -version-info 0:0:0 \ -rpath $(PREFIX)/lib -module -o $@ $? clean: rm -rf lastbind.lo lastbind.la lastbind.o .libs/ install: lastbind.la mkdir -p $(PREFIX)/libexec/openldap $(LIBTOOL) --mode=install cp lastbind.la $(PREFIX)/libexec/openldap $(LIBTOOL) --finish $(PREFIX)/libexec/openldap --------------010407040507050306070700--

1 0

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

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

04 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, 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--

1 0

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

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

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

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

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

02 Feb '11

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

1 0

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

02 Feb '11

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

1 0

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

02 Feb '11

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

1 0

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

02 Feb '11

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

1 0

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

02 Feb '11

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

1 0

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

02 Feb '11

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

1 0

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

02 Feb '11

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

1 0

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs