openldap-bugs February 2015

openldap-bugs@openldap.org

28 participants
71 discussions

Re: (ITS#8052) OpenLDAP not compiling on Ubuntu
by michael＠stroeder.com 04 Feb '15

04 Feb '15

jfha73(a)gmail.com wrote: > Because it is for libraries for PHP master (7) and I was told that PHP 7 > is not yet supporting 2.4.x I don't know "PHP master (7)" means. But php-ldap is linked to OpenLDAP 2.4 libs on my systems since years. BTW: The ITS is not for usage questions. Please follow-up on openldap-technical mailing list. Ciao, Michael.

1 0

Re: (ITS#8052) OpenLDAP not compiling on Ubuntu
by jfha73＠gmail.com 04 Feb '15

04 Feb '15

On 2/4/2015 1:01 PM, Michael Ströder wrote: > jfha73(a)gmail.com wrote: >> I'm trying to compile OpenLDAP 2.3.43 (can't use 2.4.x) on Ubuntu 14.04, but I'm >> getting this: > Why can't you use 2.4.x? > > It's *very* unlikely that you get any support for 2.3.43 which was abandoned > as historic years ago. > > Ciao, Michael. > Because it is for libraries for PHP master (7) and I was told that PHP 7 is not yet supporting 2.4.x Thanks.

1 0

Re: (ITS#8052) OpenLDAP not compiling on Ubuntu
by michael＠stroeder.com 04 Feb '15

04 Feb '15

jfha73(a)gmail.com wrote: > I'm trying to compile OpenLDAP 2.3.43 (can't use 2.4.x) on Ubuntu 14.04, but I'm > getting this: Why can't you use 2.4.x? It's *very* unlikely that you get any support for 2.3.43 which was abandoned as historic years ago. Ciao, Michael.

1 0

(ITS#8052) OpenLDAP not compiling on Ubuntu
by jfha73＠gmail.com 04 Feb '15

04 Feb '15

Full_Name: Jorge F. Hernandez Version: 2.3.43 OS: Ubuntu 14.04 URL: Submission from: (NULL) (74.8.80.62) Hey guys, I'm trying to compile OpenLDAP 2.3.43 (can't use 2.4.x) on Ubuntu 14.04, but I'm getting this: (cd .libs && rm -f libldap.la && ln -s ../libldap.la libldap.la) /bin/sh ../..//libtool --mode=link cc -static -fPIC -o apitest apitest.o libldap.la ../../libraries/liblber/liblber.la ../../libraries/liblutil/liblutil.a -lssl -lcrypto -lresolv cc -fPIC -o apitest apitest.o ./.libs/libldap.so /home/user/Downloads/openldap-2.3.43/libraries/liblber/.libs/liblber.so ../../libraries%2ibiblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a -lssl -lcrypto -lresolv -Wl,--rpath -Wl,/home/user/Downloads/openldap-2.3.43/libraries/libldap/.libs -Wl,--rpath -Wl,/home/user/Downloads/openldap-2.3.43/libraries/liblber/.libs ./.libs/libldap.so: undefined reference to `ssl3_send_alert' collect2: error: ld returned 1 exit status make[2]: *** [apitest] Error 1 make[2]: Leaving directory `/home/user/Downloads/openldap-2.3.43/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/user/Downloads/openldap-2.3.43/libraries' make: *** [all-common] Error 1 I have OpenSSL 1.2 on my Ubuntu, but I don't know what is happening. How can I solve this? Thanks.

1 0

Re: (ITS#8037) Modifying structural OC w/relax fails on delta-syncrepl consumers
by ian＠uns.ac.rs 04 Feb '15

04 Feb '15

This is a multi-part message in MIME format. --------------090909030002020203000209 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 31.01.2015. 14:09, hyc(a)symas.com wrote: > [...] Here's an updated patch for relax handling. The original code would fail to match a control with a value -- not a problem for the intended use case, but a bug nevertheless. -- Ivan Nejgebauer +381 21 485 2025 Glavni sistem inženjer ian(a)uns.ac.rs CIT-UNS/ARMUNS http://www.uns.ac.rs Univerzitet u Novom Sadu $ Dr Zorana Đinđića 1 $ 21000 Novi Sad $ Srbija --------------090909030002020203000209 Content-Type: text/x-patch; name="relax-control-delta-syncrepl-v2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="relax-control-delta-syncrepl-v2.patch" diff --git a/servers/slapd/syncrepl.c b/servers/slapd/syncrepl.c index 4e42a47..56ab4e1 100644 --- a/servers/slapd/syncrepl.c +++ b/servers/slapd/syncrepl.c @@ -165,6 +165,7 @@ typedef struct logschema { struct berval ls_newRdn; struct berval ls_delRdn; struct berval ls_newSup; + struct berval ls_controls; } logschema; static logschema changelog_sc = { @@ -173,7 +174,8 @@ static logschema changelog_sc = { BER_BVC("changes"), BER_BVC("newRDN"), BER_BVC("deleteOldRDN"), - BER_BVC("newSuperior") + BER_BVC("newSuperior"), + BER_BVC("controls"), }; static logschema accesslog_sc = { @@ -182,7 +184,8 @@ static logschema accesslog_sc = { BER_BVC("reqMod"), BER_BVC("reqNewRDN"), BER_BVC("reqDeleteOldRDN"), - BER_BVC("reqNewSuperior") + BER_BVC("reqNewSuperior"), + BER_BVC("reqControls") }; static const char * @@ -398,7 +401,7 @@ ldap_sync_search( int rc; int rhint; char *base; - char **attrs, *lattrs[8]; + char **attrs, *lattrs[9]; char *filter; int attrsonly; int scope; @@ -427,8 +430,9 @@ ldap_sync_search( lattrs[3] = ls->ls_newRdn.bv_val; lattrs[4] = ls->ls_delRdn.bv_val; lattrs[5] = ls->ls_newSup.bv_val; - lattrs[6] = slap_schema.si_ad_entryCSN->ad_cname.bv_val; - lattrs[7] = NULL; + lattrs[6] = ls->ls_controls.bv_val; + lattrs[7] = slap_schema.si_ad_entryCSN->ad_cname.bv_val; + lattrs[8] = NULL; rhint = 0; base = si->si_logbase.bv_val; @@ -2291,6 +2295,22 @@ syncrepl_message_to_op( } } else if ( !ber_bvstrcasecmp( &bv, &ls->ls_newSup ) ) { sup = bvals[0]; + } else if ( !ber_bvstrcasecmp( &bv, &ls->ls_controls ) ) { + int i; + struct berval rel_ctrl_bv; + + (void)ber_str2bv( "{" LDAP_CONTROL_RELAX, 0, 0, &rel_ctrl_bv ); + for ( i = 0; bvals[i].bv_val; i++ ) { + struct berval cbv, tmp; + + ber_bvchr_post( &cbv, &bvals[i], '}' ); + ber_bvchr_post( &tmp, &cbv, '{' ); + ber_bvchr_pre( &cbv, &tmp, ' ' ); + if ( cbv.bv_len == tmp.bv_len ) /* control w/o value */ + ber_bvchr_pre( &cbv, &tmp, '}' ); + if ( !ber_bvcmp( &cbv, &rel_ctrl_bv ) ) + op->o_relax = SLAP_CONTROL_CRITICAL; + } } else if ( !ber_bvstrcasecmp( &bv, &slap_schema.si_ad_entryCSN->ad_cname ) ) { --------------090909030002020203000209--

1 0

(ITS#8051) Enhancement: add DN qualifier to slapo-sock
by hyc＠openldap.org 03 Feb '15

03 Feb '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (110.49.207.42) Submitted by: hyc Add a config keyword to specify DN subtrees to be processed by the overlay (thus ignoring anything that doesn't match)

1 0

Re: (ITS#8050) [PATCH] test060 slapd-mtread concurrency issues
by hyc＠symas.com 03 Feb '15

03 Feb '15

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: RE24 > OS: Fedora 20 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > While performing RE24 testing observed an issue in slapd-mtread: > > ==28795== Process terminating with default action of signal 11 (SIGSEGV): > dumping core > ==28795== Access not within mapped region at address 0x2FE9F9D0 > ==28795== at 0x3A45E0A1%3: pthread_join (pthread_join.c:47) > ==28795== by 0x4A09005: ??? (in > /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) > ==28795== by 0x4A0BBA5: pthread_join (in > /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) > ==28795== by 0 0x409A2A: ldap_pvt_thread_join (thr_posix.c:197) > ==28795== by 0x405540: main (slapd-mtread.c:361) > > Hmm, not particularly helpful. Gave this a run through helgrind, report below. > So far as I can tell we had one thread in ldap_dup protected by ldcmutex: > > 542 LDAP_MUTEX_LOCK( &old->ld_ldcmutex ); > 543 ld->ldc = old->ldc; > 544 old->ld_ldcrefcnt++; > 545 LDAP_MUTEX_UNLOCK( &old->ld_ldcmutex ); > > while ldap_get_option(LDAP_OPT_SESSION_REFCNT) is protected by ldo_mutex only. > As a quick attempt: Thanks. I see your patch is this way to avoid lock ordering issues. The original code in libldap/unbind.c seems to hold ldcmutex for the entire duration of the function, without any good reason. I suspect we can just move the mutex lock/unlock to just around the actual option fetch. > --- a/libraries/libldap/options.c > +++ b/libraries/libldap/options.c > @@ -123,6 +123,10 @@ ldap_get_option( > return LDAP_OPT_ERROR; > } > > + if( option == LDAP_OPT_SESSION_REFCNT ) { > + LDAP_MUTEX_LOCK( &ld->ld_ldcmutex ); > + } > + > LDAP_MUTEX_LOCK( &lo->ldo_mutex ); > > switch(option) { > @@ -414,6 +418,11 @@ ldap_get_option( > } > > LDAP_MUTEX_UNLOCK( &lo->ldo_mutex ); > + > + if( option == LDAP_OPT_SESSION_REFCNT ) { > + LDAP_MUTEX_UNLOCK( &ld->ld_ldcmutex ); > + } > + > return ( rc ); > } > > helgrind looks happy with this. The if() is obviously optional but is hopefully > a small performance gain for ldap_get_option(others). > > helgrind report: > > ==28795== Lock at 0x4C393D0 was first observed > ==28795== at 0x4A0BCCF: pthread_mutex_init (in > /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) > ==28795== by 0x409B08: ldap_pvt_thread_mutex_init (thr_posix.c:383) > ==28795== by 0x40A25A: ldap_create (open.c:180) > ==28795== by 0x40A3E4: ldap_initialize (open.c:240) > ==28795== by 0x4062B7: do_conn (slapd-mtread.c:584) > ==28795== by 0x40530A: main (slapd-mtread.c:331) > ==28795== > ==28795== Lock at 0x4C393A8 was first observed > ==28795== at 0x4A0BCCF: pthread_mutex_init (in > /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) > ==28795== by 0x409B08: ldap_pvt_thread_mutex_init (thr_posix.c:283) > ==28795== by 0x409FBF: ldap_create (open.c:129) > ==28795%%3= by 0xA3A3E4: ldap_initialize (open.c:240) > ==28795== by 0x4062B7: do_conn (slapd-mtread.c:584) > ==28795== by 0x40530A: main (slapd-mtread.c:331) > ==28795== > ==28795== Possible data race during write of size 4 at 0x4C39238 by thread #%2 > ==28795== Locks held: 1, at address 0x4C393D0 > ==28795== at 0x412AC1: ldap_ld_free (unbind.c:87) > ==28795== by 0x4130EE: ldap_destroy (unbind.c:245) > ==28795== by 0x405BEF: do_onethread (slapd-mtread.c:455) > ==28795== by 0x4A0AECD: ??? (in > /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) > ==28795== by 0x3A45E07EE4: start_thread (pthread_create.c:309) > ==28795== by 0x3A45AF4B8C: clone (clone.S:111) > ==28795== > ==28795== This conflicts with a previous read of size 4 by thread #29 > ==28795%%3= Locks held: 1, at address 0x4C393A8 > ==28795== at 0x426957: ldap_get_option (options.c:374) > ==28795== by 0x405914: do_onethread (slapd-mtread.c:423) > ==28795== by 0x4A0AECD: ??? (in > /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) > ==28795== by 0x3A45E07EE4: start_thread (pthread_create.c:309) > ==28795== by 0x3A45AF4B8C: clone (clone.S:111) > ==28795== > ==28795== Address 0x4C39238 is 88 bytes inside a block of size 736 alloc'd > ==28795== at 0x4A083F4: calloc (in > /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) > ==28795== by 0x43E4B1: ber_memcalloc_x (memory.c:283) > ==28795== by 0x409F4B: ldap_create (open.c:119) > ==28795== by 0x40A3E4: ldap_initialize (open.c:240) > ==28795== by 0x4062B7: do_conn (slapd-mtread.c:584) > ==28795== by 0x40530A: main (slapd-mtread.c:331) > > > -- -- 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#8050) [PATCH] test060 slapd-mtread concurrency issues
by richton＠nbcs.rutgers.edu 03 Feb '15

03 Feb '15

Full_Name: Aaron Richton Version: RE24 OS: Fedora 20 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.135) While performing RE24 testing observed an issue in slapd-mtread: ==28795== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==28795== Access not within mapped region at address 0x2FE9F9D0 ==28795== at 0x3A45E0A1%3: pthread_join (pthread_join.c:47) ==28795== by 0x4A09005: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==28795== by 0x4A0BBA5: pthread_join (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==28795== by 0 0x409A2A: ldap_pvt_thread_join (thr_posix.c:197) ==28795== by 0x405540: main (slapd-mtread.c:361) Hmm, not particularly helpful. Gave this a run through helgrind, report below. So far as I can tell we had one thread in ldap_dup protected by ldcmutex: 542 LDAP_MUTEX_LOCK( &old->ld_ldcmutex ); 543 ld->ldc = old->ldc; 544 old->ld_ldcrefcnt++; 545 LDAP_MUTEX_UNLOCK( &old->ld_ldcmutex ); while ldap_get_option(LDAP_OPT_SESSION_REFCNT) is protected by ldo_mutex only. As a quick attempt: --- a/libraries/libldap/options.c +++ b/libraries/libldap/options.c @@ -123,6 +123,10 @@ ldap_get_option( return LDAP_OPT_ERROR; } + if( option == LDAP_OPT_SESSION_REFCNT ) { + LDAP_MUTEX_LOCK( &ld->ld_ldcmutex ); + } + LDAP_MUTEX_LOCK( &lo->ldo_mutex ); switch(option) { @@ -414,6 +418,11 @@ ldap_get_option( } LDAP_MUTEX_UNLOCK( &lo->ldo_mutex ); + + if( option == LDAP_OPT_SESSION_REFCNT ) { + LDAP_MUTEX_UNLOCK( &ld->ld_ldcmutex ); + } + return ( rc ); } helgrind looks happy with this. The if() is obviously optional but is hopefully a small performance gain for ldap_get_option(others). helgrind report: ==28795== Lock at 0x4C393D0 was first observed ==28795== at 0x4A0BCCF: pthread_mutex_init (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==28795== by 0x409B08: ldap_pvt_thread_mutex_init (thr_posix.c:383) ==28795== by 0x40A25A: ldap_create (open.c:180) ==28795== by 0x40A3E4: ldap_initialize (open.c:240) ==28795== by 0x4062B7: do_conn (slapd-mtread.c:584) ==28795== by 0x40530A: main (slapd-mtread.c:331) ==28795== ==28795== Lock at 0x4C393A8 was first observed ==28795== at 0x4A0BCCF: pthread_mutex_init (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==28795== by 0x409B08: ldap_pvt_thread_mutex_init (thr_posix.c:283) ==28795== by 0x409FBF: ldap_create (open.c:129) ==28795%%3= by 0xA3A3E4: ldap_initialize (open.c:240) ==28795== by 0x4062B7: do_conn (slapd-mtread.c:584) ==28795== by 0x40530A: main (slapd-mtread.c:331) ==28795== ==28795== Possible data race during write of size 4 at 0x4C39238 by thread #%2 ==28795== Locks held: 1, at address 0x4C393D0 ==28795== at 0x412AC1: ldap_ld_free (unbind.c:87) ==28795== by 0x4130EE: ldap_destroy (unbind.c:245) ==28795== by 0x405BEF: do_onethread (slapd-mtread.c:455) ==28795== by 0x4A0AECD: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==28795== by 0x3A45E07EE4: start_thread (pthread_create.c:309) ==28795== by 0x3A45AF4B8C: clone (clone.S:111) ==28795== ==28795== This conflicts with a previous read of size 4 by thread #29 ==28795%%3= Locks held: 1, at address 0x4C393A8 ==28795== at 0x426957: ldap_get_option (options.c:374) ==28795== by 0x405914: do_onethread (slapd-mtread.c:423) ==28795== by 0x4A0AECD: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==28795== by 0x3A45E07EE4: start_thread (pthread_create.c:309) ==28795== by 0x3A45AF4B8C: clone (clone.S:111) ==28795== ==28795== Address 0x4C39238 is 88 bytes inside a block of size 736 alloc'd ==28795== at 0x4A083F4: calloc (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==28795== by 0x43E4B1: ber_memcalloc_x (memory.c:283) ==28795== by 0x409F4B: ldap_create (open.c:119) ==28795== by 0x40A3E4: ldap_initialize (open.c:240) ==28795== by 0x4062B7: do_conn (slapd-mtread.c:584) ==28795== by 0x40530A: main (slapd-mtread.c:331)

1 0

(ITS#8049) Case typo on olcDbMaxSize in servers/slapd/back-mdb/config.c
by clem.oudot＠gmail.com 03 Feb '15

03 Feb '15

Full_Name: Cl.ment OUDOT Version: 2.4.40 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) This is a minor issue, but I post it anyway. clement@ader-xps:~/Projets/openldap$ grep -ri olcdbmaxsize servers/slapd/back-mdb/* servers/slapd/back-mdb/config.c: mdb_cf_ge2C2C "( OLcfgDbAt:12.2 NAME 'olcDbMaxSize' " servers/slapd/back-mdb/config.c: "olcDbNoSync $ olcDbIndex $ olcDbMaxReaders $ olcDbMaxsize $ " The first time we have a capital S, and not the second time.

1 0

Re: (ITS#8037) Modifying structural OC w/relax fails on delta-syncrepl consumers
by ian＠uns.ac.rs 03 Feb '15

03 Feb '15

This is a multi-part message in MIME format. --------------030107090007020809070602 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 31.01.2015. 14:09, hyc(a)symas.com wrote: >> A real fix would involve modifying the persistent search to include reqControls >> in its attribute list and activating Relax Rules on the consumer only if it had >> been active on the provider when the modification occurred. > > Right. This is also important for a few other controls. E.g. LDAP > Transactions. Attached is a patch implementing the outlined approach. Notes: - I've invented the attribute name for the CHANGELOG format, for symmetry. - I've structured the check so it shouldn't be difficult to handle other controls. Other approaches are certainly possible. - The patch has been generated against OPENLDAP_REL_ENG_2_4, not HEAD. If an IPR statement is needed, I'm including it here. The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Ivan Nejgebauer <ian(a)uns.ac.rs>. I have not assigned rights and/or interest in this work to any party. I, Ivan Nejgebauer, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- Ivan Nejgebauer +381 21 485 2025 Glavni sistem inženjer ian(a)uns.ac.rs CIT-UNS/ARMUNS http://www.uns.ac.rs Univerzitet u Novom Sadu $ Dr Zorana Đinđića 1 $ 21000 Novi Sad $ Srbija --------------030107090007020809070602 Content-Type: text/x-patch; name="0001-Add-relax-control-handling-for-delta-syncrepl.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Add-relax-control-handling-for-delta-syncrepl.patch" >From 52e08a1c2c63d527b8e2b65d3a63d9a12e2b6edc Mon Sep 17 00:00:00 2001 From: Ivan Nejgebauer <ian(a)uns.ac.rs> Date: Tue, 3 Feb 2015 13:35:38 +0100 Subject: [PATCH] Add relax control handling for delta-syncrepl --- servers/slapd/syncrepl.c | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/servers/slapd/syncrepl.c b/servers/slapd/syncrepl.c index 4e42a47..93b2723 100644 --- a/servers/slapd/syncrepl.c +++ b/servers/slapd/syncrepl.c @@ -165,6 +165,7 @@ typedef struct logschema { struct berval ls_newRdn; struct berval ls_delRdn; struct berval ls_newSup; + struct berval ls_controls; } logschema; static logschema changelog_sc = { @@ -173,7 +174,8 @@ static logschema changelog_sc = { BER_BVC("changes"), BER_BVC("newRDN"), BER_BVC("deleteOldRDN"), - BER_BVC("newSuperior") + BER_BVC("newSuperior"), + BER_BVC("controls"), }; static logschema accesslog_sc = { @@ -182,7 +184,8 @@ static logschema accesslog_sc = { BER_BVC("reqMod"), BER_BVC("reqNewRDN"), BER_BVC("reqDeleteOldRDN"), - BER_BVC("reqNewSuperior") + BER_BVC("reqNewSuperior"), + BER_BVC("reqControls") }; static const char * @@ -398,7 +401,7 @@ ldap_sync_search( int rc; int rhint; char *base; - char **attrs, *lattrs[8]; + char **attrs, *lattrs[9]; char *filter; int attrsonly; int scope; @@ -427,8 +430,9 @@ ldap_sync_search( lattrs[3] = ls->ls_newRdn.bv_val; lattrs[4] = ls->ls_delRdn.bv_val; lattrs[5] = ls->ls_newSup.bv_val; - lattrs[6] = slap_schema.si_ad_entryCSN->ad_cname.bv_val; - lattrs[7] = NULL; + lattrs[6] = ls->ls_controls.bv_val; + lattrs[7] = slap_schema.si_ad_entryCSN->ad_cname.bv_val; + lattrs[8] = NULL; rhint = 0; base = si->si_logbase.bv_val; @@ -2291,6 +2295,20 @@ syncrepl_message_to_op( } } else if ( !ber_bvstrcasecmp( &bv, &ls->ls_newSup ) ) { sup = bvals[0]; + } else if ( !ber_bvstrcasecmp( &bv, &ls->ls_controls ) ) { + int i; + struct berval rel_ctrl_bv; + + (void)ber_str2bv( "{" LDAP_CONTROL_RELAX, 0, 0, &rel_ctrl_bv ); + for ( i = 0; bvals[i].bv_val; i++ ) { + struct berval cbv, tmp; + + ber_bvchr_post( &cbv, &bvals[i], '}' ); + ber_bvchr_post( &tmp, &cbv, '{' ); + ber_bvchr_pre( &cbv, &tmp, '}' ); + if ( !ber_bvcmp( &cbv, &rel_ctrl_bv ) ) + op->o_relax = SLAP_CONTROL_CRITICAL; + } } else if ( !ber_bvstrcasecmp( &bv, &slap_schema.si_ad_entryCSN->ad_cname ) ) { -- 1.8.1.2 --------------030107090007020809070602--

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2015