openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs