- openldap-bugs - openldap.org

Re: (ITS#8015) memcpy() overlapping in many places
by kurt＠OpenLDAP.org 03 Jan '15

03 Jan '15

AC_MEMCPY is generally memove(3). It would only be memcpy(3) if both = memmove(3) or bcopy(3) were not available. So at most your patch will = cause link errors. =E2=80=94 Kurt > On Jan 3, 2015, at 11:21 AM, leo(a)yuriev.ru wrote: >=20 > This is a multi-part message in MIME format. > --------------090408030902080204080503 > Content-Type: text/plain; charset=3Dwindows-1251; format=3Dflowed > Content-Transfer-Encoding: 7bit >=20 > Please review and merge. >=20 > Leonid. >=20 >=20 > --------------090408030902080204080503 > Content-Type: text/x-patch; > name=3D"its8015.patch" > Content-Transfer-Encoding: 7bit > Content-Disposition: attachment; > filename=3D"its8015.patch" >=20 > commit 8d55a7c88c6655879ffc677e5a9873f29bb7a802 > Author: Leo Yuriev <leo(a)yuriev.ru> > Date: 2015-01-01 16:00:58 +0300 >=20 > ITS#8015 replace memcpy() by memmove() for overlapped src & dst. >=20 > http://lwn.net/Articles/414467/ >=20 > Initially a few cases have been detected using Valgrind. > After that I manually reviewed all calls memcpy() and AC_MEMCPY() > it the 2.4 branch. >=20 > Unfortunately, we can not expect that all of these mistakes > corrected, but it is much more than nothing. >=20 > diff --git a/libraries/liblber/encode.c b/libraries/liblber/encode.c > index e39fa07..3eb15c6 100644 > --- a/libraries/liblber/encode.c > +++ b/libraries/liblber/encode.c > @@ -398,7 +398,7 @@ ber_start_seqorset( > return -1; > } > dest =3D *p; > - AC_MEMCPY( dest, headptr, headlen ); > + memmove( dest, headptr, headlen ); > ber->ber_sos_ptr =3D dest + headlen; >=20 > ber->ber_sos_inner =3D dest + taglen - ber->ber_buf; > @@ -467,7 +467,7 @@ ber_put_seqorset( BerElement *ber ) > if ( unused !=3D 0 ) { > /* length(length) < the reserved SOS_LENLEN = bytes */ > xlen -=3D unused; > - AC_MEMCPY( lenptr, p, xlen ); > + memmove( lenptr, p, xlen ); > ber->ber_sos_ptr =3D (char *) lenptr + xlen; > } > } > diff --git a/libraries/libldap/sasl.c b/libraries/libldap/sasl.c > index 8878d1f..4ad605f 100644 > --- a/libraries/libldap/sasl.c > +++ b/libraries/libldap/sasl.c > @@ -628,7 +628,7 @@ sb_sasl_generic_drop_packet ( >=20 > len =3D p->sec_buf_in.buf_ptr - p->sec_buf_in.buf_end; > if ( len > 0 ) > - AC_MEMCPY( p->sec_buf_in.buf_base, = p->sec_buf_in.buf_base + > + memmove( p->sec_buf_in.buf_base, p->sec_buf_in.buf_base = + > p->sec_buf_in.buf_end, len ); >=20 > if ( len >=3D 4 ) { > diff --git a/libraries/liblutil/utils.c b/libraries/liblutil/utils.c > index 310380b..a783167 100644 > --- a/libraries/liblutil/utils.c > +++ b/libraries/liblutil/utils.c > @@ -841,7 +841,7 @@ lutil_str2bin( struct berval *in, struct berval = *out, void *ctx ) > num.buf[num.beg] =3D neg; > } > if ( num.beg ) > - AC_MEMCPY( num.buf, num.buf+num.beg, num.len ); > + memmove( num.buf, num.buf+num.beg, num.len ); > out->bv_len =3D num.len; > decfail: > if ( tmp !=3D tmpbuf ) { > diff --git a/servers/slapd/aclparse.c b/servers/slapd/aclparse.c > index f5c244c..f935efc 100644 > --- a/servers/slapd/aclparse.c > +++ b/servers/slapd/aclparse.c > @@ -2317,7 +2317,7 @@ acl_regex_normalized_dn( > for ( q =3D &p[2]; q[0] =3D=3D ' '; q++ ) { > /* DO NOTHING */ ; > } > - AC_MEMCPY( p+1, q, len-(q-str)+1); > + memmove( p+1, q, len-(q-str)+1); > } > } > pattern->bv_val =3D str; > diff --git a/servers/slapd/ad.c b/servers/slapd/ad.c > index 6f6cb2f..2357452 100644 > --- a/servers/slapd/ad.c > +++ b/servers/slapd/ad.c > @@ -277,7 +277,7 @@ int slap_bv2ad( > } else if ( rc > 0 || > ( rc =3D=3D 0 && = (unsigned)optlen > tags[i].bv_len )) > { > - AC_MEMCPY( &tags[i+2], = &tags[i+1], > + memmove( &tags[i+2], &tags[i+1], > = (ntags-i-1)*sizeof(struct berval) ); > tags[i+1].bv_val =3D opt; > tags[i+1].bv_len =3D optlen; > @@ -286,7 +286,7 @@ int slap_bv2ad( > } >=20 > if( ntags ) { > - AC_MEMCPY( &tags[1], &tags[0], > + memmove( &tags[1], &tags[0], > ntags*sizeof(struct berval) ); > } > tags[0].bv_val =3D opt; > diff --git a/servers/slapd/back-bdb/attr.c = b/servers/slapd/back-bdb/attr.c > index 2f183b3..e4ab16f 100644 > --- a/servers/slapd/back-bdb/attr.c > +++ b/servers/slapd/back-bdb/attr.c > @@ -71,7 +71,7 @@ ainfo_insert( struct bdb_info *bdb, AttrInfo *a ) > bdb->bi_attrs =3D ch_realloc( bdb->bi_attrs, ( bdb->bi_nattrs+1 = ) *=20 > sizeof( AttrInfo * )); > if ( x < bdb->bi_nattrs ) > - AC_MEMCPY( &bdb->bi_attrs[x+1], &bdb->bi_attrs[x], > + memmove( &bdb->bi_attrs[x+1], &bdb->bi_attrs[x], > ( bdb->bi_nattrs - x ) * sizeof( AttrInfo *)); > bdb->bi_attrs[x] =3D a; > bdb->bi_nattrs++; > diff --git a/servers/slapd/back-bdb/idl.c = b/servers/slapd/back-bdb/idl.c > index c6bc9f3..f024245 100644 > --- a/servers/slapd/back-bdb/idl.c > +++ b/servers/slapd/back-bdb/idl.c > @@ -204,7 +204,7 @@ int bdb_idl_insert( ID *ids, ID id ) > =09 > } else { > /* insert id */ > - AC_MEMCPY( &ids[x+1], &ids[x], (ids[0]-x) * sizeof(ID) = ); > + memmove( &ids[x+1], &ids[x], (ids[0]-x) * sizeof(ID) ); > ids[x] =3D id; > } >=20 > @@ -262,7 +262,7 @@ int bdb_idl_delete( ID *ids, ID id ) > } >=20 > } else { > - AC_MEMCPY( &ids[x], &ids[x+1], (1+ids[0]-x) * sizeof(ID) = ); > + memmove( &ids[x], &ids[x+1], (1+ids[0]-x) * sizeof(ID) = ); > } >=20 > #if IDL_DEBUG > 1 > diff --git a/servers/slapd/back-ldap/config.c = b/servers/slapd/back-ldap/config.c > index 11a4ac4..4b5c394 100644 > --- a/servers/slapd/back-ldap/config.c > +++ b/servers/slapd/back-ldap/config.c > @@ -1047,7 +1047,7 @@ ldap_back_cf_gen( ConfigArgs *c ) >=20 > if ( i ) { > bv.bv_len -=3D i; > - AC_MEMCPY( bv.bv_val, &bv.bv_val[ i ], > + memmove( bv.bv_val, &bv.bv_val[ i ], > bv.bv_len + 1 ); > } >=20 > @@ -1239,7 +1239,7 @@ ldap_back_cf_gen( ConfigArgs *c ) >=20 > if ( i ) { > bc.bv_len -=3D i; > - AC_MEMCPY( bc.bv_val, = &bc.bv_val[ i ], bc.bv_len + 1 ); > + memmove( bc.bv_val, &bc.bv_val[ = i ], bc.bv_len + 1 ); > } >=20 > bv =3D bc; > @@ -1298,7 +1298,7 @@ ldap_back_cf_gen( ConfigArgs *c ) >=20 > if ( i ) { > bv.bv_len -=3D i; > - AC_MEMCPY( bv.bv_val, &bv.bv_val[ i ], > + memmove( bv.bv_val, &bv.bv_val[ i ], > bv.bv_len + 1 ); > } >=20 > diff --git a/servers/slapd/back-ldap/search.c = b/servers/slapd/back-ldap/search.c > index eeab466..b100510 100644 > --- a/servers/slapd/back-ldap/search.c > +++ b/servers/slapd/back-ldap/search.c > @@ -109,7 +109,7 @@ ldap_back_munge_filter( >=20 > ptr =3D filter->bv_val + ( ptr - oldfilter.bv_val ); >=20 > - AC_MEMCPY( &ptr[ newbv->bv_len ], > + memmove( &ptr[ newbv->bv_len ], > &ptr[ oldbv->bv_len ],=20 > oldfilter.bv_len - ( ptr - = filter->bv_val ) - oldbv->bv_len + 1 ); > AC_MEMCPY( ptr, newbv->bv_val, newbv->bv_len ); > diff --git a/servers/slapd/back-mdb/attr.c = b/servers/slapd/back-mdb/attr.c > index 5da9da9..38e513e 100644 > --- a/servers/slapd/back-mdb/attr.c > +++ b/servers/slapd/back-mdb/attr.c > @@ -71,7 +71,7 @@ ainfo_insert( struct mdb_info *mdb, AttrInfo *a ) > mdb->mi_attrs =3D ch_realloc( mdb->mi_attrs, ( mdb->mi_nattrs+1 = ) *=20 > sizeof( AttrInfo * )); > if ( x < mdb->mi_nattrs ) > - AC_MEMCPY( &mdb->mi_attrs[x+1], &mdb->mi_attrs[x], > + memmove( &mdb->mi_attrs[x+1], &mdb->mi_attrs[x], > ( mdb->mi_nattrs - x ) * sizeof( AttrInfo *)); > mdb->mi_attrs[x] =3D a; > mdb->mi_nattrs++; > diff --git a/servers/slapd/back-mdb/idl.c = b/servers/slapd/back-mdb/idl.c > index 3c2f986..c03f7c3 100644 > --- a/servers/slapd/back-mdb/idl.c > +++ b/servers/slapd/back-mdb/idl.c > @@ -173,7 +173,7 @@ int mdb_idl_insert( ID *ids, ID id ) > =09 > } else { > /* insert id */ > - AC_MEMCPY( &ids[x+1], &ids[x], (ids[0]-x) * sizeof(ID) = ); > + memmove( &ids[x+1], &ids[x], (ids[0]-x) * sizeof(ID) ); > ids[x] =3D id; > } >=20 > @@ -231,7 +231,7 @@ static int mdb_idl_delete( ID *ids, ID id ) > } >=20 > } else { > - AC_MEMCPY( &ids[x], &ids[x+1], (1+ids[0]-x) * sizeof(ID) = ); > + memmove( &ids[x], &ids[x+1], (1+ids[0]-x) * sizeof(ID) = ); > } >=20 > #if IDL_DEBUG > 1 > diff --git a/servers/slapd/back-meta/config.c = b/servers/slapd/back-meta/config.c > index e3164b0..daa5e8b 100644 > --- a/servers/slapd/back-meta/config.c > +++ b/servers/slapd/back-meta/config.c > @@ -1340,7 +1340,7 @@ meta_back_cf_gen( ConfigArgs *c ) >=20 > if ( i ) { > bv.bv_len -=3D i; > - AC_MEMCPY( bv.bv_val, &bv.bv_val[ i ], > + memmove( bv.bv_val, &bv.bv_val[ i ], > bv.bv_len + 1 ); > } >=20 > @@ -1597,7 +1597,7 @@ meta_back_cf_gen( ConfigArgs *c ) >=20 > if ( i ) { > bc.bv_len -=3D i; > - AC_MEMCPY( bc.bv_val, = &bc.bv_val[ i ], bc.bv_len + 1 ); > + memmove( bc.bv_val, &bc.bv_val[ = i ], bc.bv_len + 1 ); > } >=20 > bv =3D bc; > @@ -2720,7 +2720,7 @@ idassert-authzFrom "dn:<rootdn>" > int len =3D strlen( argv[ 0 ] ); >=20 > ber_str2bv( line, 0, 0, &bv ); > - AC_MEMCPY( &bv.bv_val[ len ], &bv.bv_val[ len + = 1 ], > + memmove( &bv.bv_val[ len ], &bv.bv_val[ len + 1 = ], > bv.bv_len - ( len + 1 )); > bv.bv_val[ bv.bv_len - 1] =3D '"'; > ber_bvarray_add( &mt->mt_rwmap.rwm_bva_rewrite, = &bv ); > diff --git a/servers/slapd/back-sql/util.c = b/servers/slapd/back-sql/util.c > index 3564527..7c77964 100644 > --- a/servers/slapd/back-sql/util.c > +++ b/servers/slapd/back-sql/util.c > @@ -411,7 +411,7 @@ backsql_split_pattern( >=20 > } else if ( real_end[ 1 ] =3D=3D SPLIT_CHAR ) { > expected++; > - AC_MEMCPY( real_end, real_end + 1, strlen( = real_end ) ); > + memmove( real_end, real_end + 1, strlen( = real_end ) ); > end =3D strchr( real_end + 1, SPLIT_CHAR ); > continue; > } > diff --git a/servers/slapd/bconfig.c b/servers/slapd/bconfig.c > index 2214334..9655629 100644 > --- a/servers/slapd/bconfig.c > +++ b/servers/slapd/bconfig.c > @@ -2353,7 +2353,7 @@ sortval_reject: > s =3D ber_bvchr( &bv, '"' ); > assert( s !=3D NULL ); > /* move the trailing quote of = argv[0] to the end */ > - AC_MEMCPY( s, s + 1, bv.bv_len - = ( s - bv.bv_val ) ); > + memmove( s, s + 1, bv.bv_len - ( = s - bv.bv_val ) ); > bv.bv_val[ bv.bv_len - 1 ] =3D = '"'; >=20 > } else { > diff --git a/servers/slapd/config.c b/servers/slapd/config.c > index cdc17d9..5c0dd55 100644 > --- a/servers/slapd/config.c > +++ b/servers/slapd/config.c > @@ -2159,12 +2159,12 @@ strtok_quote( char *line, char *sep, char = **quote_ptr ) > } else { > inquote =3D 1; > } > - AC_MEMCPY( next, next + 1, strlen( next + 1 ) + = 1 ); > + memmove( next, next + 1, strlen( next + 1 ) + 1 = ); > break; >=20 > case '\\': > if ( next[1] ) > - AC_MEMCPY( next, > + memmove( next, > next + 1, strlen( next + 1 ) = + 1 ); > next++; /* dont parse the escaped = character */ > break; > diff --git a/servers/slapd/controls.c b/servers/slapd/controls.c > index 9b51f95..6b1f1d7 100644 > --- a/servers/slapd/controls.c > +++ b/servers/slapd/controls.c > @@ -1005,7 +1005,7 @@ slap_remove_control( > op->o_tmpfree( op->o_ctrls[ j ], op->o_tmpmemctx ); >=20 > if ( i > 1 ) { > - AC_MEMCPY( &op->o_ctrls[ j ], &op->o_ctrls[ j + = 1 ], > + memmove( &op->o_ctrls[ j ], &op->o_ctrls[ j + 1 = ], > ( i - j ) * sizeof( LDAPControl * ) ); >=20 > } else { > diff --git a/servers/slapd/overlays/constraint.c = b/servers/slapd/overlays/constraint.c > index 096f32a..99844a5 100644 > --- a/servers/slapd/overlays/constraint.c > +++ b/servers/slapd/overlays/constraint.c > @@ -401,7 +401,7 @@ constraint_cf_gen( ConfigArgs *c ) > rc =3D ARG_BAD_CONF; > goto done; > } > - AC_MEMCPY( = &ap.lud->lud_filter[0], &ap.lud->lud_filter[1], len - 2 ); > + memmove( &ap.lud->lud_filter[0], = &ap.lud->lud_filter[1], len - 2 ); > ap.lud->lud_filter[len - 2] =3D = '\0'; > } >=20 > diff --git a/servers/slapd/overlays/memberof.c = b/servers/slapd/overlays/memberof.c > index 17cbae7..dcfb047 100644 > --- a/servers/slapd/overlays/memberof.c > +++ b/servers/slapd/overlays/memberof.c > @@ -616,10 +616,10 @@ memberof_op_add( Operation *op, SlapReply *rs ) > break; > } > =09 > - AC_MEMCPY( &a->a_vals[ i ], = &a->a_vals[ i + 1 ], > + memmove( &a->a_vals[ i ], = &a->a_vals[ i + 1 ], > sizeof( struct berval ) = * ( j - i ) ); > if ( a->a_nvals !=3D a->a_vals ) = { > - AC_MEMCPY( &a->a_nvals[ = i ], &a->a_nvals[ i + 1 ], > + memmove( &a->a_nvals[ i = ], &a->a_nvals[ i + 1 ], > sizeof( struct = berval ) * ( j - i ) ); > } > i--; > @@ -698,10 +698,10 @@ memberof_op_add( Operation *op, SlapReply *rs ) > break; > } > =09 > - AC_MEMCPY( &a->a_vals[ i ], = &a->a_vals[ i + 1 ], > + memmove( &a->a_vals[ i ], = &a->a_vals[ i + 1 ], > sizeof( struct berval ) = * ( j - i ) ); > if ( a->a_nvals !=3D a->a_vals ) = { > - AC_MEMCPY( &a->a_nvals[ = i ], &a->a_nvals[ i + 1 ], > + memmove( &a->a_nvals[ i = ], &a->a_nvals[ i + 1 ], > sizeof( struct = berval ) * ( j - i ) ); > } > i--; > @@ -922,9 +922,9 @@ memberof_op_modify( Operation *op, SlapReply *rs ) > break; > } > =09 > - AC_MEMCPY( = &ml->sml_values[ i ], &ml->sml_values[ i + 1 ], > + memmove( = &ml->sml_values[ i ], &ml->sml_values[ i + 1 ], > sizeof( = struct berval ) * ( j - i ) ); > - AC_MEMCPY( = &ml->sml_nvalues[ i ], &ml->sml_nvalues[ i + 1 ], > + memmove( = &ml->sml_nvalues[ i ], &ml->sml_nvalues[ i + 1 ], > sizeof( = struct berval ) * ( j - i ) ); > i--; > } > @@ -1022,10 +1022,10 @@ memberof_op_modify( Operation *op, SlapReply = *rs ) > break; > } > =09 > - AC_MEMCPY( = &ml->sml_values[ i ], &ml->sml_values[ i + 1 ], > + memmove( = &ml->sml_values[ i ], &ml->sml_values[ i + 1 ], > sizeof( = struct berval ) * ( j - i ) ); > if ( = ml->sml_nvalues !=3D ml->sml_values ) { > - = AC_MEMCPY( &ml->sml_nvalues[ i ], &ml->sml_nvalues[ i + 1 ], > + memmove( = &ml->sml_nvalues[ i ], &ml->sml_nvalues[ i + 1 ], > = sizeof( struct berval ) * ( j - i ) ); > } > i--; > @@ -1140,10 +1140,10 @@ memberof_op_modify( Operation *op, SlapReply = *rs ) > break; > } > =09 > - AC_MEMCPY( = &ml->sml_values[ i ], &ml->sml_values[ i + 1 ], > + memmove( = &ml->sml_values[ i ], &ml->sml_values[ i + 1 ], > sizeof( struct = berval ) * ( j - i ) ); > if ( ml->sml_nvalues !=3D = ml->sml_values ) { > - AC_MEMCPY( = &ml->sml_nvalues[ i ], &ml->sml_nvalues[ i + 1 ], > + memmove( = &ml->sml_nvalues[ i ], &ml->sml_nvalues[ i + 1 ], > sizeof( = struct berval ) * ( j - i ) ); > } > i--; > diff --git a/servers/slapd/overlays/rwm.c = b/servers/slapd/overlays/rwm.c > index 1fbfac3..22a536a 100644 > --- a/servers/slapd/overlays/rwm.c > +++ b/servers/slapd/overlays/rwm.c > @@ -2014,7 +2014,7 @@ rwm_bva_add( > int len =3D strlen( argv[ 0 ] ); >=20 > ber_str2bv( line, 0, 0, &bv ); > - AC_MEMCPY( &bv.bv_val[ len ], &bv.bv_val[ len + 1 ], > + memmove( &bv.bv_val[ len ], &bv.bv_val[ len + 1 ], > bv.bv_len - ( len + 1 ) ); > bv.bv_val[ bv.bv_len - 1 ] =3D '"'; >=20 > diff --git a/servers/slapd/sasl.c b/servers/slapd/sasl.c > index b47a528..7436614 100644 > --- a/servers/slapd/sasl.c > +++ b/servers/slapd/sasl.c > @@ -1342,7 +1342,7 @@ slap_sasl_peer2ipport( struct berval *peer ) > *p =3D ';'; > if ( isv6 ) { > assert( p[-1] =3D=3D ']' ); > - AC_MEMCPY( &p[-1], p, plen - ( p - ipport ) + 1 = ); > + memmove( &p[-1], p, plen - ( p - ipport ) + 1 ); > } >=20 > } else if ( isv6 ) { > diff --git a/servers/slapd/saslauthz.c b/servers/slapd/saslauthz.c > index 5e0ebbe..5449603 100644 > --- a/servers/slapd/saslauthz.c > +++ b/servers/slapd/saslauthz.c > @@ -182,14 +182,14 @@ int slap_parse_user( struct berval *id, struct = berval *user, > if ( !BER_BVISNULL( mech ) ) { > assert( mech->bv_val =3D=3D id->bv_val + 2 ); >=20 > - AC_MEMCPY( mech->bv_val - 2, mech->bv_val, mech->bv_len = + 1 ); > + memmove( mech->bv_val - 2, mech->bv_val, mech->bv_len + = 1 ); > mech->bv_val -=3D 2; > } >=20 > if ( !BER_BVISNULL( realm ) ) { > assert( realm->bv_val >=3D id->bv_val + 2 ); >=20 > - AC_MEMCPY( realm->bv_val - 2, realm->bv_val, = realm->bv_len + 1 ); > + memmove( realm->bv_val - 2, realm->bv_val, realm->bv_len = + 1 ); > realm->bv_val -=3D 2; > } >=20 >=20 > --------------090408030902080204080503-- >=20 >=20 >=20

1 0

Re: (ITS#8015) memcpy() overlapping in many places
by leo＠yuriev.ru 03 Jan '15

03 Jan '15

This is a multi-part message in MIME format. --------------090408030902080204080503 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Please review and merge. Leonid. --------------090408030902080204080503 Content-Type: text/x-patch; name="its8015.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="its8015.patch" commit 8d55a7c88c6655879ffc677e5a9873f29bb7a802 Author: Leo Yuriev <leo(a)yuriev.ru> Date: 2015-01-01 16:00:58 +0300 ITS#8015 replace memcpy() by memmove() for overlapped src & dst. http://lwn.net/Articles/414467/ Initially a few cases have been detected using Valgrind. After that I manually reviewed all calls memcpy() and AC_MEMCPY() it the 2.4 branch. Unfortunately, we can not expect that all of these mistakes corrected, but it is much more than nothing. diff --git a/libraries/liblber/encode.c b/libraries/liblber/encode.c index e39fa07..3eb15c6 100644 --- a/libraries/liblber/encode.c +++ b/libraries/liblber/encode.c @@ -398,7 +398,7 @@ ber_start_seqorset( return -1; } dest = *p; - AC_MEMCPY( dest, headptr, headlen ); + memmove( dest, headptr, headlen ); ber->ber_sos_ptr = dest + headlen; ber->ber_sos_inner = dest + taglen - ber->ber_buf; @@ -467,7 +467,7 @@ ber_put_seqorset( BerElement *ber ) if ( unused != 0 ) { /* length(length) < the reserved SOS_LENLEN bytes */ xlen -= unused; - AC_MEMCPY( lenptr, p, xlen ); + memmove( lenptr, p, xlen ); ber->ber_sos_ptr = (char *) lenptr + xlen; } } diff --git a/libraries/libldap/sasl.c b/libraries/libldap/sasl.c index 8878d1f..4ad605f 100644 --- a/libraries/libldap/sasl.c +++ b/libraries/libldap/sasl.c @@ -628,7 +628,7 @@ sb_sasl_generic_drop_packet ( len = p->sec_buf_in.buf_ptr - p->sec_buf_in.buf_end; if ( len > 0 ) - AC_MEMCPY( p->sec_buf_in.buf_base, p->sec_buf_in.buf_base + + memmove( p->sec_buf_in.buf_base, p->sec_buf_in.buf_base + p->sec_buf_in.buf_end, len ); if ( len >= 4 ) { diff --git a/libraries/liblutil/utils.c b/libraries/liblutil/utils.c index 310380b..a783167 100644 --- a/libraries/liblutil/utils.c +++ b/libraries/liblutil/utils.c @@ -841,7 +841,7 @@ lutil_str2bin( struct berval *in, struct berval *out, void *ctx ) num.buf[num.beg] = neg; } if ( num.beg ) - AC_MEMCPY( num.buf, num.buf+num.beg, num.len ); + memmove( num.buf, num.buf+num.beg, num.len ); out->bv_len = num.len; decfail: if ( tmp != tmpbuf ) { diff --git a/servers/slapd/aclparse.c b/servers/slapd/aclparse.c index f5c244c..f935efc 100644 --- a/servers/slapd/aclparse.c +++ b/servers/slapd/aclparse.c @@ -2317,7 +2317,7 @@ acl_regex_normalized_dn( for ( q = &p[2]; q[0] == ' '; q++ ) { /* DO NOTHING */ ; } - AC_MEMCPY( p+1, q, len-(q-str)+1); + memmove( p+1, q, len-(q-str)+1); } } pattern->bv_val = str; diff --git a/servers/slapd/ad.c b/servers/slapd/ad.c index 6f6cb2f..2357452 100644 --- a/servers/slapd/ad.c +++ b/servers/slapd/ad.c @@ -277,7 +277,7 @@ int slap_bv2ad( } else if ( rc > 0 || ( rc == 0 && (unsigned)optlen > tags[i].bv_len )) { - AC_MEMCPY( &tags[i+2], &tags[i+1], + memmove( &tags[i+2], &tags[i+1], (ntags-i-1)*sizeof(struct berval) ); tags[i+1].bv_val = opt; tags[i+1].bv_len = optlen; @@ -286,7 +286,7 @@ int slap_bv2ad( } if( ntags ) { - AC_MEMCPY( &tags[1], &tags[0], + memmove( &tags[1], &tags[0], ntags*sizeof(struct berval) ); } tags[0].bv_val = opt; diff --git a/servers/slapd/back-bdb/attr.c b/servers/slapd/back-bdb/attr.c index 2f183b3..e4ab16f 100644 --- a/servers/slapd/back-bdb/attr.c +++ b/servers/slapd/back-bdb/attr.c @@ -71,7 +71,7 @@ ainfo_insert( struct bdb_info *bdb, AttrInfo *a ) bdb->bi_attrs = ch_realloc( bdb->bi_attrs, ( bdb->bi_nattrs+1 ) * sizeof( AttrInfo * )); if ( x < bdb->bi_nattrs ) - AC_MEMCPY( &bdb->bi_attrs[x+1], &bdb->bi_attrs[x], + memmove( &bdb->bi_attrs[x+1], &bdb->bi_attrs[x], ( bdb->bi_nattrs - x ) * sizeof( AttrInfo *)); bdb->bi_attrs[x] = a; bdb->bi_nattrs++; diff --git a/servers/slapd/back-bdb/idl.c b/servers/slapd/back-bdb/idl.c index c6bc9f3..f024245 100644 --- a/servers/slapd/back-bdb/idl.c +++ b/servers/slapd/back-bdb/idl.c @@ -204,7 +204,7 @@ int bdb_idl_insert( ID *ids, ID id ) } else { /* insert id */ - AC_MEMCPY( &ids[x+1], &ids[x], (ids[0]-x) * sizeof(ID) ); + memmove( &ids[x+1], &ids[x], (ids[0]-x) * sizeof(ID) ); ids[x] = id; } @@ -262,7 +262,7 @@ int bdb_idl_delete( ID *ids, ID id ) } } else { - AC_MEMCPY( &ids[x], &ids[x+1], (1+ids[0]-x) * sizeof(ID) ); + memmove( &ids[x], &ids[x+1], (1+ids[0]-x) * sizeof(ID) ); } #if IDL_DEBUG > 1 diff --git a/servers/slapd/back-ldap/config.c b/servers/slapd/back-ldap/config.c index 11a4ac4..4b5c394 100644 --- a/servers/slapd/back-ldap/config.c +++ b/servers/slapd/back-ldap/config.c @@ -1047,7 +1047,7 @@ ldap_back_cf_gen( ConfigArgs *c ) if ( i ) { bv.bv_len -= i; - AC_MEMCPY( bv.bv_val, &bv.bv_val[ i ], + memmove( bv.bv_val, &bv.bv_val[ i ], bv.bv_len + 1 ); } @@ -1239,7 +1239,7 @@ ldap_back_cf_gen( ConfigArgs *c ) if ( i ) { bc.bv_len -= i; - AC_MEMCPY( bc.bv_val, &bc.bv_val[ i ], bc.bv_len + 1 ); + memmove( bc.bv_val, &bc.bv_val[ i ], bc.bv_len + 1 ); } bv = bc; @@ -1298,7 +1298,7 @@ ldap_back_cf_gen( ConfigArgs *c ) if ( i ) { bv.bv_len -= i; - AC_MEMCPY( bv.bv_val, &bv.bv_val[ i ], + memmove( bv.bv_val, &bv.bv_val[ i ], bv.bv_len + 1 ); } diff --git a/servers/slapd/back-ldap/search.c b/servers/slapd/back-ldap/search.c index eeab466..b100510 100644 --- a/servers/slapd/back-ldap/search.c +++ b/servers/slapd/back-ldap/search.c @@ -109,7 +109,7 @@ ldap_back_munge_filter( ptr = filter->bv_val + ( ptr - oldfilter.bv_val ); - AC_MEMCPY( &ptr[ newbv->bv_len ], + memmove( &ptr[ newbv->bv_len ], &ptr[ oldbv->bv_len ], oldfilter.bv_len - ( ptr - filter->bv_val ) - oldbv->bv_len + 1 ); AC_MEMCPY( ptr, newbv->bv_val, newbv->bv_len ); diff --git a/servers/slapd/back-mdb/attr.c b/servers/slapd/back-mdb/attr.c index 5da9da9..38e513e 100644 --- a/servers/slapd/back-mdb/attr.c +++ b/servers/slapd/back-mdb/attr.c @@ -71,7 +71,7 @@ ainfo_insert( struct mdb_info *mdb, AttrInfo *a ) mdb->mi_attrs = ch_realloc( mdb->mi_attrs, ( mdb->mi_nattrs+1 ) * sizeof( AttrInfo * )); if ( x < mdb->mi_nattrs ) - AC_MEMCPY( &mdb->mi_attrs[x+1], &mdb->mi_attrs[x], + memmove( &mdb->mi_attrs[x+1], &mdb->mi_attrs[x], ( mdb->mi_nattrs - x ) * sizeof( AttrInfo *)); mdb->mi_attrs[x] = a; mdb->mi_nattrs++; diff --git a/servers/slapd/back-mdb/idl.c b/servers/slapd/back-mdb/idl.c index 3c2f986..c03f7c3 100644 --- a/servers/slapd/back-mdb/idl.c +++ b/servers/slapd/back-mdb/idl.c @@ -173,7 +173,7 @@ int mdb_idl_insert( ID *ids, ID id ) } else { /* insert id */ - AC_MEMCPY( &ids[x+1], &ids[x], (ids[0]-x) * sizeof(ID) ); + memmove( &ids[x+1], &ids[x], (ids[0]-x) * sizeof(ID) ); ids[x] = id; } @@ -231,7 +231,7 @@ static int mdb_idl_delete( ID *ids, ID id ) } } else { - AC_MEMCPY( &ids[x], &ids[x+1], (1+ids[0]-x) * sizeof(ID) ); + memmove( &ids[x], &ids[x+1], (1+ids[0]-x) * sizeof(ID) ); } #if IDL_DEBUG > 1 diff --git a/servers/slapd/back-meta/config.c b/servers/slapd/back-meta/config.c index e3164b0..daa5e8b 100644 --- a/servers/slapd/back-meta/config.c +++ b/servers/slapd/back-meta/config.c @@ -1340,7 +1340,7 @@ meta_back_cf_gen( ConfigArgs *c ) if ( i ) { bv.bv_len -= i; - AC_MEMCPY( bv.bv_val, &bv.bv_val[ i ], + memmove( bv.bv_val, &bv.bv_val[ i ], bv.bv_len + 1 ); } @@ -1597,7 +1597,7 @@ meta_back_cf_gen( ConfigArgs *c ) if ( i ) { bc.bv_len -= i; - AC_MEMCPY( bc.bv_val, &bc.bv_val[ i ], bc.bv_len + 1 ); + memmove( bc.bv_val, &bc.bv_val[ i ], bc.bv_len + 1 ); } bv = bc; @@ -2720,7 +2720,7 @@ idassert-authzFrom "dn:<rootdn>" int len = strlen( argv[ 0 ] ); ber_str2bv( line, 0, 0, &bv ); - AC_MEMCPY( &bv.bv_val[ len ], &bv.bv_val[ len + 1 ], + memmove( &bv.bv_val[ len ], &bv.bv_val[ len + 1 ], bv.bv_len - ( len + 1 )); bv.bv_val[ bv.bv_len - 1] = '"'; ber_bvarray_add( &mt->mt_rwmap.rwm_bva_rewrite, &bv ); diff --git a/servers/slapd/back-sql/util.c b/servers/slapd/back-sql/util.c index 3564527..7c77964 100644 --- a/servers/slapd/back-sql/util.c +++ b/servers/slapd/back-sql/util.c @@ -411,7 +411,7 @@ backsql_split_pattern( } else if ( real_end[ 1 ] == SPLIT_CHAR ) { expected++; - AC_MEMCPY( real_end, real_end + 1, strlen( real_end ) ); + memmove( real_end, real_end + 1, strlen( real_end ) ); end = strchr( real_end + 1, SPLIT_CHAR ); continue; } diff --git a/servers/slapd/bconfig.c b/servers/slapd/bconfig.c index 2214334..9655629 100644 --- a/servers/slapd/bconfig.c +++ b/servers/slapd/bconfig.c @@ -2353,7 +2353,7 @@ sortval_reject: s = ber_bvchr( &bv, '"' ); assert( s != NULL ); /* move the trailing quote of argv[0] to the end */ - AC_MEMCPY( s, s + 1, bv.bv_len - ( s - bv.bv_val ) ); + memmove( s, s + 1, bv.bv_len - ( s - bv.bv_val ) ); bv.bv_val[ bv.bv_len - 1 ] = '"'; } else { diff --git a/servers/slapd/config.c b/servers/slapd/config.c index cdc17d9..5c0dd55 100644 --- a/servers/slapd/config.c +++ b/servers/slapd/config.c @@ -2159,12 +2159,12 @@ strtok_quote( char *line, char *sep, char **quote_ptr ) } else { inquote = 1; } - AC_MEMCPY( next, next + 1, strlen( next + 1 ) + 1 ); + memmove( next, next + 1, strlen( next + 1 ) + 1 ); break; case '\\': if ( next[1] ) - AC_MEMCPY( next, + memmove( next, next + 1, strlen( next + 1 ) + 1 ); next++; /* dont parse the escaped character */ break; diff --git a/servers/slapd/controls.c b/servers/slapd/controls.c index 9b51f95..6b1f1d7 100644 --- a/servers/slapd/controls.c +++ b/servers/slapd/controls.c @@ -1005,7 +1005,7 @@ slap_remove_control( op->o_tmpfree( op->o_ctrls[ j ], op->o_tmpmemctx ); if ( i > 1 ) { - AC_MEMCPY( &op->o_ctrls[ j ], &op->o_ctrls[ j + 1 ], + memmove( &op->o_ctrls[ j ], &op->o_ctrls[ j + 1 ], ( i - j ) * sizeof( LDAPControl * ) ); } else { diff --git a/servers/slapd/overlays/constraint.c b/servers/slapd/overlays/constraint.c index 096f32a..99844a5 100644 --- a/servers/slapd/overlays/constraint.c +++ b/servers/slapd/overlays/constraint.c @@ -401,7 +401,7 @@ constraint_cf_gen( ConfigArgs *c ) rc = ARG_BAD_CONF; goto done; } - AC_MEMCPY( &ap.lud->lud_filter[0], &ap.lud->lud_filter[1], len - 2 ); + memmove( &ap.lud->lud_filter[0], &ap.lud->lud_filter[1], len - 2 ); ap.lud->lud_filter[len - 2] = '\0'; } diff --git a/servers/slapd/overlays/memberof.c b/servers/slapd/overlays/memberof.c index 17cbae7..dcfb047 100644 --- a/servers/slapd/overlays/memberof.c +++ b/servers/slapd/overlays/memberof.c @@ -616,10 +616,10 @@ memberof_op_add( Operation *op, SlapReply *rs ) break; } - AC_MEMCPY( &a->a_vals[ i ], &a->a_vals[ i + 1 ], + memmove( &a->a_vals[ i ], &a->a_vals[ i + 1 ], sizeof( struct berval ) * ( j - i ) ); if ( a->a_nvals != a->a_vals ) { - AC_MEMCPY( &a->a_nvals[ i ], &a->a_nvals[ i + 1 ], + memmove( &a->a_nvals[ i ], &a->a_nvals[ i + 1 ], sizeof( struct berval ) * ( j - i ) ); } i--; @@ -698,10 +698,10 @@ memberof_op_add( Operation *op, SlapReply *rs ) break; } - AC_MEMCPY( &a->a_vals[ i ], &a->a_vals[ i + 1 ], + memmove( &a->a_vals[ i ], &a->a_vals[ i + 1 ], sizeof( struct berval ) * ( j - i ) ); if ( a->a_nvals != a->a_vals ) { - AC_MEMCPY( &a->a_nvals[ i ], &a->a_nvals[ i + 1 ], + memmove( &a->a_nvals[ i ], &a->a_nvals[ i + 1 ], sizeof( struct berval ) * ( j - i ) ); } i--; @@ -922,9 +922,9 @@ memberof_op_modify( Operation *op, SlapReply *rs ) break; } - AC_MEMCPY( &ml->sml_values[ i ], &ml->sml_values[ i + 1 ], + memmove( &ml->sml_values[ i ], &ml->sml_values[ i + 1 ], sizeof( struct berval ) * ( j - i ) ); - AC_MEMCPY( &ml->sml_nvalues[ i ], &ml->sml_nvalues[ i + 1 ], + memmove( &ml->sml_nvalues[ i ], &ml->sml_nvalues[ i + 1 ], sizeof( struct berval ) * ( j - i ) ); i--; } @@ -1022,10 +1022,10 @@ memberof_op_modify( Operation *op, SlapReply *rs ) break; } - AC_MEMCPY( &ml->sml_values[ i ], &ml->sml_values[ i + 1 ], + memmove( &ml->sml_values[ i ], &ml->sml_values[ i + 1 ], sizeof( struct berval ) * ( j - i ) ); if ( ml->sml_nvalues != ml->sml_values ) { - AC_MEMCPY( &ml->sml_nvalues[ i ], &ml->sml_nvalues[ i + 1 ], + memmove( &ml->sml_nvalues[ i ], &ml->sml_nvalues[ i + 1 ], sizeof( struct berval ) * ( j - i ) ); } i--; @@ -1140,10 +1140,10 @@ memberof_op_modify( Operation *op, SlapReply *rs ) break; } - AC_MEMCPY( &ml->sml_values[ i ], &ml->sml_values[ i + 1 ], + memmove( &ml->sml_values[ i ], &ml->sml_values[ i + 1 ], sizeof( struct berval ) * ( j - i ) ); if ( ml->sml_nvalues != ml->sml_values ) { - AC_MEMCPY( &ml->sml_nvalues[ i ], &ml->sml_nvalues[ i + 1 ], + memmove( &ml->sml_nvalues[ i ], &ml->sml_nvalues[ i + 1 ], sizeof( struct berval ) * ( j - i ) ); } i--; diff --git a/servers/slapd/overlays/rwm.c b/servers/slapd/overlays/rwm.c index 1fbfac3..22a536a 100644 --- a/servers/slapd/overlays/rwm.c +++ b/servers/slapd/overlays/rwm.c @@ -2014,7 +2014,7 @@ rwm_bva_add( int len = strlen( argv[ 0 ] ); ber_str2bv( line, 0, 0, &bv ); - AC_MEMCPY( &bv.bv_val[ len ], &bv.bv_val[ len + 1 ], + memmove( &bv.bv_val[ len ], &bv.bv_val[ len + 1 ], bv.bv_len - ( len + 1 ) ); bv.bv_val[ bv.bv_len - 1 ] = '"'; diff --git a/servers/slapd/sasl.c b/servers/slapd/sasl.c index b47a528..7436614 100644 --- a/servers/slapd/sasl.c +++ b/servers/slapd/sasl.c @@ -1342,7 +1342,7 @@ slap_sasl_peer2ipport( struct berval *peer ) *p = ';'; if ( isv6 ) { assert( p[-1] == ']' ); - AC_MEMCPY( &p[-1], p, plen - ( p - ipport ) + 1 ); + memmove( &p[-1], p, plen - ( p - ipport ) + 1 ); } } else if ( isv6 ) { diff --git a/servers/slapd/saslauthz.c b/servers/slapd/saslauthz.c index 5e0ebbe..5449603 100644 --- a/servers/slapd/saslauthz.c +++ b/servers/slapd/saslauthz.c @@ -182,14 +182,14 @@ int slap_parse_user( struct berval *id, struct berval *user, if ( !BER_BVISNULL( mech ) ) { assert( mech->bv_val == id->bv_val + 2 ); - AC_MEMCPY( mech->bv_val - 2, mech->bv_val, mech->bv_len + 1 ); + memmove( mech->bv_val - 2, mech->bv_val, mech->bv_len + 1 ); mech->bv_val -= 2; } if ( !BER_BVISNULL( realm ) ) { assert( realm->bv_val >= id->bv_val + 2 ); - AC_MEMCPY( realm->bv_val - 2, realm->bv_val, realm->bv_len + 1 ); + memmove( realm->bv_val - 2, realm->bv_val, realm->bv_len + 1 ); realm->bv_val -= 2; } --------------090408030902080204080503--

1 0

(ITS#8015) memcpy() overlapping in many places
by leo＠yuriev.ru 03 Jan '15

03 Jan '15

Full_Name: Leonid Yuriev Version: 2.4-HEAD OS: RHEL7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (31.130.36.33) A lot of places where memcpy() is called with overlapping source and destination, or such is possible in some cases. Explanation of why this is a problem, see. Http://lwn.net/Articles/414467/ Patch will be available shortly. Leonid.

1 0

Re: (ITS#8014) minor memleak in slapadd
by leo＠yuriev.ru 03 Jan '15

03 Jan '15

This is a multi-part message in MIME format. --------------020803010305090509060904 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Please review attached patch and merge. Leonid. --- The attached files is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Peter-Service LLC, Moscow, Russia. Peter-Service LLC has not assigned rights and/or interest in this work to any party. I, Leonid Yuriev am authorized by Peter-Service LLC, my employer, to release this work under the following terms. Peter-Service LLC hereby places 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. --------------020803010305090509060904 Content-Type: text/x-patch; name="its8014.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="its8014.patch" commit 39ffdbe0abda49189d52432a4c950589a288a9c0 Author: Leo Yuriev <leo(a)yuriev.ru> Date: 2015-01-01 23:52:14 +0300 ITS#8014: minor CSN memleak in slapadd. diff --git a/servers/slapd/slapcommon.c b/servers/slapd/slapcommon.c index 01a4955..73c6579 100644 --- a/servers/slapd/slapcommon.c +++ b/servers/slapd/slapcommon.c @@ -975,7 +975,7 @@ slap_tool_update_ctxcsn( { struct berval ctxdn; ID ctxcsn_id; - Entry *ctxcsn_e; + Entry *ctxcsn_e = NULL; int rc = EXIT_SUCCESS; if ( !(update_ctxcsn && !dryrun && sid != SLAP_SYNC_SID_MAX + 1) ) { @@ -1093,6 +1093,11 @@ slap_tool_update_ctxcsn( } } + if (ctxcsn_e) { + Operation op = {0}; + op.o_bd = be; + be_entry_release_w(&op, ctxcsn_e); + } return rc; } --------------020803010305090509060904--

1 0

(ITS#8014) minor memleak in slapadd
by leo＠yuriev.ru 03 Jan '15

03 Jan '15

Full_Name: Leonid Yuriev Version: 2.4-HEAD OS: RHEL7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (31.130.36.33) Minor memleak was found by valgrind tool. Patch will be available shortly. Leonid.

1 0

Re: (ITS#8013) SIGSEGV in test_filter()
by leo＠yuriev.ru 03 Jan '15

03 Jan '15

This is a multi-part message in MIME format. --------------070304060303090304060107 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Please review attached patch and merge. Leonid. --- The attached files is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Peter-Service LLC, Moscow, Russia. Peter-Service LLC has not assigned rights and/or interest in this work to any party. I, Leonid Yuriev am authorized by Peter-Service LLC, my employer, to release this work under the following terms. Peter-Service LLC hereby places 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. --------------070304060303090304060107 Content-Type: text/x-patch; name="its8013.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="its8013.patch" commit 51051e4142a43e37bc622775e4f816d38d2e269c Author: Leo Yuriev <leo(a)yuriev.ru> Date: 2015-01-01 16:44:50 +0300 ITS#8013 fix rare SIGSEGV in test_filter(). Clear PS_FIX_FILTER while alter the filter in syncprov_matchops(). diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c index 2eeda4c..53432b0 100644 --- a/servers/slapd/overlays/syncprov.c +++ b/servers/slapd/overlays/syncprov.c @@ -1308,7 +1308,9 @@ syncprov_matchops( Operation *op, opcookie *opc, int saveit ) /* Skip the AND/GE clause that we stuck on in front. We would lose deletes/mods that happen during the refresh phase otherwise (ITS#6555) */ - op2.ors_filter = ss->s_op->ors_filter->f_and->f_next; + assert(ss->s_op->ors_filter->f_choice == LDAP_FILTER_AND); + op2.ors_filter = op2.ors_filter->f_and->f_next; + ss->s_flags ^= PS_FIX_FILTER; } ldap_pvt_thread_mutex_unlock( &ss->s_mutex ); rc = test_filter( &op2, e, op2.ors_filter ); @@ -2241,6 +2243,7 @@ syncprov_detach_op( Operation *op, syncops *so, slap_overinst *on ) /* Skip the AND/GE clause that we stuck on in front */ if ( so->s_flags & PS_FIX_FILTER ) { + assert(op2->ors_filter->f_choice == LDAP_FILTER_AND); op2->ors_filter = op->ors_filter->f_and->f_next; so->s_flags ^= PS_FIX_FILTER; } else { @@ -2394,7 +2397,6 @@ syncprov_search_response( Operation *op, SlapReply *rs ) ldap_pvt_thread_mutex_unlock( &op->o_conn->c_mutex ); /* syncprov_ab_cleanup will free this syncop */ return SLAPD_ABANDON; - } else { ldap_pvt_thread_mutex_lock( &ss->ss_so->s_mutex ); /* Turn off the refreshing flag */ --------------070304060303090304060107--

1 0

(ITS#8013) SIGSEGV in test_filter()
by leo＠yuriev.ru 03 Jan '15

03 Jan '15

Full_Name: Leonid Yuriev Version: 2.4-HEAD OS: RHEL7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (31.130.36.33) I have previously reported on the two SIGSEGV backtraces (see a copy below). This bug was reproduced again during our replication test. I think that now I have found the reason - the PS_FIX_FILTER flag not cleared after update the filter. Patch will be available shortly. Please review and merge. Leonid. === *** Signal 11 (Segmentation fault), address is 0xb from 0x442f07 (0) /opt/openldap.devel/libexec/slapd() [0x442f07]: test_filter /home/ly/Projects/openldap.git/servers/slapd/filterentry.c:69 (1) /opt/openldap.devel/libexec/slapd() [0x514721]: syncprov_matchops /home/ly/Projects/openldap.git/servers/slapd/overlays/syncprov.c:1316 (2) /opt/openldap.devel/libexec/slapd() [0x514b83]: syncprov_op_mod /home/ly/Projects/openldap.git/servers/slapd/overlays/syncprov.c:2145 (3) /opt/openldap.devel/libexec/slapd() [0x48b31a]: overlay_op_walk /home/ly/Projects/openldap.git/servers/slapd/backover.c:662 (4) /opt/openldap.devel/libexec/slapd() [0x48b4c1]: over_op_func /home/ly/Projects/openldap.git/servers/slapd/backover.c:724 (5) /opt/openldap.devel/libexec/slapd() [0x4811a6]: syncrepl_entry /home/ly/Projects/openldap.git/servers/slapd/syncrepl.c:3177 do_syncrep2 /home/ly/Projects/openldap.git/servers/slapd/syncrepl.c:10%0 (6) /opt/openldap.devel/libexec/slapd() [0x4844b2]: do_syncrepl /home/ly/Projects/openldap.git/servers/slapd/syncrepl.c:1539 === Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f9762ffe700 (LWP 29507)]D%D test_filter (op=0x7f9762ffc210, e=0x7f96f19c37d8, f=0x20) at filterentry.c:69 69 if ( f->f_choice & SLAPD_FILTER_UNDEFINED ) { (0) /opt/openldap.devel/libexec/slapd() [0x4430b7]: test_filter /home/ly/Projects/openldap.git/servers/slapd/filterentry.c:69 (1) /opt/openldap.devel/libexec/slapd() [0x515081]: syncprov_matchops /home/ly/Projects/openldap.git/servers/slapd/overlays/syncprov.c:1317 (2) /opt/openldap.devel/libexec/slapd() [0x515f43]: syncprov_op_response /home/ly/Projects/openldap.git/servers/slapd/overlays/syncprov.c:1941 (3) /opt/openldap.devel/libexec/slapd() [0x434163]: slap_response_play /home/ly/Projects/openldap.git/servers/slapd/result.c:509 (4) /opt/openldap.devel/libexec/slapd() [0x4346ca]: send_ldap_response /home/ly/Projects/openldap.git/servers/slapd/result.c:584 (5) /opt/openldap.devel/libexec/slapd() [0x435062]: slap_send_ldap_result /home/ly/Projects/openldap.git/servers/slapd/result.c:861 (6) /opt/openldap.devel/libexec/slapd() [0x4cb2e9]: mdb_add /home/ly/Projects/openldap.git/servers/slapd/back-mdb/add.c:434 (7) /opt/openldap.devel/libexec/slapd() [0x48b506]: overlay_op_walk /home/ly/Projects/openldap.git/servers/slapd/backover.c:674 (8) /opt/openldap.devel/libexec/slapd() [0x48b671]: over_op_func /home/ly%Projojects/openldap.git/servers/slapd/backover.c:724

1 0

Re: (ITS#8012) SIGSEGV while disconnect/abandon
by leo＠yuriev.ru 29 Dec '14

29 Dec '14

This is a multi-part message in MIME format. --------------090802040703090609040601 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Patch update: Detaching a syncops record from op-list CONDITIONALLY, only when it was freed by syncprov_free_syncop. The syncprov_drop_psearch() and syncprov_drop_psearch() now returns a flag, which is nonzero if the given syncops was freed. Leonid. 29.12.2014 13:50, Leonid Yuriev ïèøåò: > Please review attached patch and merge-in. > > Leonid. > > --- > > The attached files is derived from OpenLDAP Software. All of the > modifications > to OpenLDAP Software represented in the following patch(es) were > developed by > Peter-Service LLC, Moscow, Russia. Peter-Service LLC has not assigned > rights > and/or interest in this work to any party. I, Leonid Yuriev am > authorized by > Peter-Service LLC, my employer, to release this work under the > following terms. > > Peter-Service LLC hereby places 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. > --------------090802040703090609040601 Content-Type: text/x-patch; name="its8012.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="its8012.patch" commit 34d36d685ccb372dfd43a33730b480610ab369a0 Author: Leo Yuriev <leo(a)yuriev.ru> Date: 2014-12-29 13:40:59 +0300 ITS#5452, ITS#8012: fix syncops list iteration and detaching on freed; Detaching a syncops record from op-list conditionally, only when it was freed by syncprov_free_syncop. The syncprov_drop_psearch() and syncprov_drop_psearch() now returns a flag, which is nonzero if the given syncops was freed. diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c index 5ef2eaa..2eeda4c 100644 --- a/servers/slapd/overlays/syncprov.c +++ b/servers/slapd/overlays/syncprov.c @@ -790,7 +790,7 @@ static int dec_mutexint( mutexint *mi ) return i; } -static void +static int syncprov_free_syncop( syncops *so ) { syncres *sr, *srnext; @@ -800,7 +800,7 @@ syncprov_free_syncop( syncops *so ) /* already being freed, or still in use */ if ( !so->s_inuse || --so->s_inuse > 0 ) { ldap_pvt_thread_mutex_unlock( &so->s_mutex ); - return; + return 0; } ldap_pvt_thread_mutex_unlock( &so->s_mutex ); if ( so->s_flags & PS_IS_DETACHED ) { @@ -824,6 +824,7 @@ syncprov_free_syncop( syncops *so ) } ldap_pvt_thread_mutex_destroy( &so->s_mutex ); ch_free( so ); + return 1; } /* Send a persistent search response */ @@ -1104,9 +1105,7 @@ syncprov_drop_psearch( syncops *so, int lock ) if ( lock ) ldap_pvt_thread_mutex_unlock( &so->s_op->o_conn->c_mutex ); } - syncprov_free_syncop( so ); - - return 0; + return syncprov_free_syncop( so ); } static int @@ -1166,10 +1165,10 @@ syncprov_matchops( Operation *op, opcookie *opc, int saveit ) syncprov_info_t *si = on->on_bi.bi_private; fbase_cookie fc; - syncops *ss, *sprev, *snext; + syncops **pss; Entry *e = NULL; Attribute *a; - int rc; + int rc, gonext; struct berval newdn; int freefdn = 0; BackendDB *b0 = op->o_bd, db; @@ -1229,15 +1228,15 @@ syncprov_matchops( Operation *op, opcookie *opc, int saveit ) } ldap_pvt_thread_mutex_lock( &si->si_ops_mutex ); - for (ss = si->si_ops, sprev = (syncops *)&si->si_ops; ss; - sprev = ss, ss=snext) + for (pss = &si->si_ops; *pss; pss = gonext ? &(*pss)->s_next : pss) { Operation op2; Opheader oh; syncmatches *sm; int found = 0; + syncops *snext, *ss = *pss; - snext = ss->s_next; + gonext = 1; if ( ss->s_op->o_abandon ) continue; @@ -1266,9 +1265,10 @@ syncprov_matchops( Operation *op, opcookie *opc, int saveit ) SlapReply rs = {REP_RESULT}; send_ldap_error( ss->s_op, &rs, LDAP_SYNC_REFRESH_REQUIRED, "search base has changed" ); - sprev->s_next = snext; - syncprov_drop_psearch( ss, 1 ); - ss = sprev; + snext = ss->s_next; + if ( syncprov_drop_psearch( ss, 1 ) ) + *pss = snext; + gonext = 0; continue; } @@ -1342,7 +1342,11 @@ syncprov_matchops( Operation *op, opcookie *opc, int saveit ) /* Decrement s_inuse, was incremented when called * with saveit == TRUE */ - syncprov_free_syncop( ss ); + snext = ss->s_next; + if ( syncprov_free_syncop( ss ) ) { + *pss = snext; + gonext = 0; + } } } ldap_pvt_thread_mutex_unlock( &si->si_ops_mutex ); --------------090802040703090609040601--

1 0

Re: (ITS#5452) seg fault in syncprov_op abandon on master
by leo＠yuriev.ru 29 Dec '14

29 Dec '14

ITS#8012 is a duplicate of this bug. Please see ones and review/apply the patch. http://www.openldap.org/its/index.cgi/Incoming?id=8012 Leonid.

1 0

Re: (ITS#8012) SIGSEGV while disconnect/abandon
by leo＠yuriev.ru 29 Dec '14

29 Dec '14

I think this is duplicate of ITS#5452. Happy New Year! Leonid.

1 0

Re: (ITS#8012) SIGSEGV while disconnect/abandon
by leo＠yuriev.ru 29 Dec '14

29 Dec '14

This is a multi-part message in MIME format. --------------010303050205060701030601 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Please review attached patch and merge-in. Leonid. --- The attached files is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Peter-Service LLC, Moscow, Russia. Peter-Service LLC has not assigned rights and/or interest in this work to any party. I, Leonid Yuriev am authorized by Peter-Service LLC, my employer, to release this work under the following terms. Peter-Service LLC hereby places 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. --------------010303050205060701030601 Content-Type: text/x-patch; name="its8012.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="its8012.patch" commit decf38f5c4ca7bc90edc2def3e14ba146d786f5b Author: Leo Yuriev <leo(a)yuriev.ru> Date: 2014-12-29 13:40:59 +0300 ITS#8012: fix syncops list iteration; diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c index 5ef2eaa..eff9e1c 100644 --- a/servers/slapd/overlays/syncprov.c +++ b/servers/slapd/overlays/syncprov.c @@ -1166,10 +1166,10 @@ syncprov_matchops( Operation *op, opcookie *opc, int saveit ) syncprov_info_t *si = on->on_bi.bi_private; fbase_cookie fc; - syncops *ss, *sprev, *snext; + syncops **pss; Entry *e = NULL; Attribute *a; - int rc; + int rc, gonext; struct berval newdn; int freefdn = 0; BackendDB *b0 = op->o_bd, db; @@ -1229,15 +1229,15 @@ syncprov_matchops( Operation *op, opcookie *opc, int saveit ) } ldap_pvt_thread_mutex_lock( &si->si_ops_mutex ); - for (ss = si->si_ops, sprev = (syncops *)&si->si_ops; ss; - sprev = ss, ss=snext) + for (pss = &si->si_ops; *pss; pss = gonext ? &(*pss)->s_next : pss) { Operation op2; Opheader oh; syncmatches *sm; int found = 0; + syncops *ss = *pss; - snext = ss->s_next; + gonext = 1; if ( ss->s_op->o_abandon ) continue; @@ -1266,9 +1266,9 @@ syncprov_matchops( Operation *op, opcookie *opc, int saveit ) SlapReply rs = {REP_RESULT}; send_ldap_error( ss->s_op, &rs, LDAP_SYNC_REFRESH_REQUIRED, "search base has changed" ); - sprev->s_next = snext; + *pss = ss->s_next; + gonext = 0; syncprov_drop_psearch( ss, 1 ); - ss = sprev; continue; } @@ -1342,6 +1342,8 @@ syncprov_matchops( Operation *op, opcookie *opc, int saveit ) /* Decrement s_inuse, was incremented when called * with saveit == TRUE */ + *pss = ss->s_next; + gonext = 0; syncprov_free_syncop( ss ); } } --------------010303050205060701030601--

1 0

Re: (ITS#6104) race condition with cancel operation
by ddh3eaa＠gmail.com 29 Dec '14

29 Dec '14

Sent from my iPhone

1 0

Re: (ITS#8012) SIGSEGV while disconnect/abandon
by leo＠yuriev.ru 29 Dec '14

29 Dec '14

Let see to syncprov_matchops() in syncprov.c: lines 1233-1235 (begin of the loop): ldap_pvt_thread_mutex_lock( &si->si_ops_mutex ); for (ss = si->si_ops, sprev = (syncops *)&si->si_ops; ss; sprev = ss, ss=snext) lines 1273-1275: ss = sprev; continue; } and 1347 (near from end of the loop): syncprov_free_syncop( ss ); Seems that syncops which is freed on 1347 could be referenced by 1273 on a next iteration of the loop. Leonid.

1 0

Re: (ITS#8012) SIGSEGV while disconnect/abandon
by leo＠yuriev.ru 29 Dec '14

29 Dec '14

(gdb) info local on = <optimised out> si = 0x23b33f0 so = 0x7f14b444cd30 soprev = 0x7f14e02dc9b0 (gdb) p *so->s_op->o_hdr Cannot access memory at address 0x3932323134313032 (gdb) p *si $1 = {si_ops = 0x7f14e949ed60, si_contextdn = {bv_len = 7, bv_val = 0x2389e10 "dc=ldap"}, si_ctxcsn = 0x2640e60, si_sids = 0x243a6c0, si_numcsns = 4, si_chkops = 1, si_chktime = 60, si_numops = 0, si_nopres = 0, si_usehint = 1, si_active = 2, si_dirty = 0, si_chklast = 1419822205, si_mods = 0x7f14bcead650, si_logs = 0x0, si_csn_rwlock = {__data = {__lock = 0, __nr_readers = 0, __readers_wakeup = 5312, __writer_wakeup = 9078, __nr_readers_queued = 0, __nr_writers_queued = 0, __writer = 0, __shared = 0, __pad1 = 0, __pad2 = 0, __flags = 0}, __size = "\000\000\000\000\000\000\000\000\300\024\000\000v#", '\000' <repeats 41 times>, __align = 0}, si_ops_mutex = {__data = {__lock = 1, __count = 0, __owner = 30051, __nusers = 1, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\001\000\000\000\000\000\000\000cu\000\000\001", '\000' <repeats 26 times>, __align = 1}, si_mods_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, si_resp_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}} (gdb) p *so $2 = {s_next = 0x0, s_base = {bv_len = 15, bv_val = 0x7f14b4964180 "dc=ngdr,dc=ldap"}, s_eid = 4, s_op = 0x7f14b0a12d30, s_rid = 4, s_sid = 1, s_filterstr = {bv_len = 15, bv_val = 0x7f14b4000b18 "\300\f"}, s_flags = 17, s_inuse = 1, s_res = 0x7f14d19ff780, s_restail = 0x7f14c818b090, s_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}} (gdb) p *so->s_op $3 = {o_hdr = 0x3932323134313032, o_tag = 25385731496096560, o_time = 8029759185026510703, o_tincr = 37, o_bd = 0x3932323134313032, o_req_dn = {bv_len = 25385731496096560, bv_val = 0x20 <Address 0x20 out of bounds>}, o_req_ndn = {bv_len = 37, bv_val = 0x7061646c3d6364 <Address 0x7061646c3d6364 out of bounds>}, o_request = {oq_add = {rs_modlist = 0x6f6f6f6f6f6f6f6f, rs_e = 0x6f6f6f6f6f6f6f6f}, oq_bind = {rb_method = 1869573999, rb_cred = {bv_len = 8029759185026510703, bv_val = 0x25 <Address 0x25 out of bounds>}, rb_edn = {bv_len = 4121411795907850290, bv_val = 0x5a303034303330 <Address 0x5a303034303330 out of bounds>}, rb_ssf = 32, rb_mech = {bv_len = 53, bv_val = 0x6 <Address 0x6 out of bounds>}}, oq_compare = {rs_ava = 0x6f6f6f6f6f6f6f6f}, oq_modify = {rs_mods = {rs_modlist = 0x6f6f6f6f6f6f6f6f, rs_no_opattrs = 111 'o'}, rs_increment = 37}, oq_modrdn = {rs_mods = {rs_modlist = 0x6f6f6f6f6f6f6f6f, rs_no_opattrs = 111 'o'}, rs_deleteoldrdn = 37, rs_newrdn = {bv_len = 4121411795907850290, bv_val = 0x5a303034303330 <Address 0x5a303034303330 out of bounds>}, rs_nnewrdn = {bv_len = 32, bv_val = 0x35 <Address 0x35 out of bounds>}, rs_newSup = 0x6, rs_nnewSup = 0x7f14b01bc820}, oq_search = {rs_scope = 1869573999, rs_deref = 1869573999, rs_slimit = 1869573999, rs_tlimit = 1869573999, rs_limit = 0x25, rs_attrsonly = 875638834, rs_attrs = 0x5a303034303330, rs_filter = 0x20, rs_filterstr = {bv_len = 53, bv_val = 0x6 <Address 0x6 out of bounds>}}, oq_abandon = {rs_msgid = 1869573999}, oq_cancel = {rs_msgid = 1869573999}, oq_extended = {rs_reqoid = {bv_len = 8029759185026510703, bv_val = 0x6f6f6f6f6f6f6f6f <Address 0x6f6f6f6f6f6f6f6f out of bounds>}, rs_flags = 37, rs_reqdata = 0x3932323134313032}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 8029759185026510703, bv_val = 0x6f6f6f6f6f6f6f6f <Address 0x6f6f6f6f6f6f6f6f out of bounds>}, rs_flags = 37, rs_reqdata = 0x3932323134313032}, rs_old = {bv_len = 25385731496096560, bv_val = 0x20 <Address 0x20 out of bounds>}, rs_new = {bv_len = 53, bv_val = 0x6 <Address 0x6 out of bounds>}, rs_mods = 0x7f14b01bc820, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x6f6f6f6f6f6f6f6f, o_do_not_cache = 53 '5', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 36 '$', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = "\000\000\000\000ã\033\260\024\177", '\000' <repeats 18 times>, "oooo", o_controls = 0x25, o_authz = { sai_method = 3751589900465327636, sai_mech = {bv_len = 1617057180469906565, bv_val = 0x0}, sai_dn = {bv_len = 53, bv_val = 0xf <Address 0xf out of bounds>}, sai_ndn = {bv_len = 139726839426656, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 48, sai_sasl_ssf = 0}, o_ber = 0x25, o_res_ber = 0x3932323134313032, o_callback = 0x5a303034303330, o_ctrls = 0x6f6f6f6f6f007972, o_csn = {bv_len = 37, bv_val = 0x3932323134313032 <Address 0x3932323134313032 out of bounds>}, o_private = 0x5a303034303330, o_extra = {slh_first = 0x7972}, o_next = {stqe_next = 0x35}} (gdb) p *op $4 = {o_hdr = 0x7f14efffe820, o_tag = 80, o_time = 0, o_tincr = 0, o_bd = 0x7f14efffe5d0, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = { rs_modlist = 0x3, rs_e = 0x0}, oq_bind = {rb_method = 3, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = { rs_ava = 0x3}, oq_modify = {rs_mods = {rs_modlist = 0x3, rs_no_opattrs = 0 '\000'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x3, rs_no_opattrs = 0 '\000'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 3, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 3}, oq_cancel = {rs_msgid = 3}, oq_extended = {rs_reqoid = { bv_len = 3, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 3, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x0, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x7f14efffe5a0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} (gdb) p *soprev $5 = {s_next = 0x7f14b444cd30, s_base = {bv_len = 15, bv_val = 0x7f14e063fb20 "dc=ngdr,dc=ldap"}, s_eid = 4, s_op = 0x7f14e0260c70, s_rid = 4, s_sid = 2, s_filterstr = {bv_len = 15, bv_val = 0x7f14e0000b18 "\300\f"}, s_flags = 2, s_inuse = 1, s_res = 0x0, s_restail = 0x0, s_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}} (gdb) p op->o_hdr $6 = (Opheader *) 0x7f14efffe820 (gdb) p *op->o_hdr $7 = {oh_opid = 0, oh_connid = 15472, oh_conn = 0x7f15178fe390, oh_msgid = 0, oh_protocol = 0, oh_tid = 0, oh_threadctx = 0x0, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x0, oh_counters = 0x0, oh_log_prefix = '\000' <repeats 255 times>} (gdb) p *op->o_hdr->oh_conn $8 = {c_struct_state = SLAP_C_USED, c_conn_state = SLAP_C_CLOSING, c_conn_idx = 298, c_sd = 298, c_close_reason = 0x538d20 <conn_lost_str> "connection lost", c_mutex = {__data = {__lock = 1, __count = 0, __owner = 30051, __nusers = 1, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\001\000\000\000\000\000\000\000cu\000\000\001", '\000' <repeats 26 times>, __align = 1}, c_sb = 0x7f14d43369e0, c_starttime = 1419822255, c_activitytime = 1419822255, c_connid = 15472, c_peer_domain = {bv_len = 7, bv_val = 0x7f14d495fdc0 "unknown"}, c_peer_name = { bv_len = 18, bv_val = 0x7f14d495be10 "IP=127.0.0.1:52784"}, c_listener = 0x231d210, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = { bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x2388eb0, c_authz_cookie = 0x0, c_authz = {sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 7, bv_val = 0x7f14a8adeef0 "dc=ldap"}, sai_ndn = {bv_len = 7, bv_val = 0x7f14a8c3e860 "dc=ldap"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 3, c_ops = { stqh_first = 0x7f14c13dfa50, stqh_last = 0x7f14c13dfbb8}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x7f15178fe4b8}, c_write1_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__data = { __lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 3, c_n_ops_executing = 1, c_n_ops_pending = 0, c_n_ops_completed = 2, c_n_get = 3, c_n_read = 3, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0x0, c_clientarg = 0x0, c_send_ldap_result = 0x435340 <slap_send_ldap_result>, c_send_search_entry = 0x435d80 <slap_send_search_entry>, c_send_search_reference = 0x437270 <slap_send_search_reference>, c_send_ldap_extended = 0x435a50 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x435bf0 <slap_send_ldap_intermediate>}

1 0

(ITS#8012) SIGSEGV while disconnect/abandon
by leo＠yuriev.ru 29 Dec '14

29 Dec '14

Full_Name: Leonid Yuriev Version: 2.4-HEAD OS: Ubuntu 14.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (31.130.36.33) with addition into main(): + mallopt(M_CHECK_ACTION, 7); + mallopt(M_PERTURB, 111); Core was generated by `/opt/openldap.devel/libexec/slapd -l LOCAL5 -d 32768 -s 0 -4 -h ldap://10.4.0.1'. Program terminated with signal 11, Segmentation fault. #0 0x000000000051025d in syncprov_op_abandon (op=0x7f14efffe970, rs=0x7f14efffe7b0) at syncprov.c:1134 1134 if ( so->s_op->o_connid == op->o_connid && (gdb) bt #0 0x000000000051025d in syncprov_op_abandon (op=7x7f14efffe970, rs=0x7f14efffe7b0) at syncprov.c:1134 #1 0x000000000048ae3a in overlay_op_walk (op=op@entry=0x7f14efffe970, rs=0x7f14efffe7b0, which=op_abandon, oi=0x23b3030, on=0x23b3210) at backover.c:661 #2 0x000000000048afd1 in over_op_func (op=0x7f14efffe970, rs=<optimised out>, which=<optimised out>) at backover.c:730 #3 0x0000000000442ea7 in fe_op_abandon (op=0x7f14efffe970, rs=0x7f14efffe7b0) at abandon.c:136 #4 0x0000000000422d3c in connection_abandon (c=c@entry=0x7f15178fe390) at connection.c:747 #5 0x0000000000424a09 in connection_closing (c=0x7f15178fe390, why=0x538d20 <conn_lost_str> "connection lost") at connection.c:820 #6 0x00000000004255ef in connection_read (cri=<optimised out>, s=<optimised out>) at connection.c:1476 #7 connection_read_thread (ctx=0x7f14efffebd0, argv=0x12a) at connection.c:1284 #8 0x00007f1517613cf2 in ldap_int_thread_pool_wrapper (xpool=0x233d090) at tpool.c:688 #9 0x00007f1516c930a5 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 coredump is available and additional info could be provided.

1 0

Re: (ITS#8011) few mistakes in lmdb-backend
by leo＠yuriev.ru 29 Dec '14

29 Dec '14

--e89a8f8389d11704db050b564d2b Content-Type: multipart/alternative; boundary=e89a8f8389d11704d5050b564d29 --e89a8f8389d11704d5050b564d29 Content-Type: text/plain; charset=UTF-8 Updated. Please pickup. Leonid. 2014-12-29 1:13 GMT+03:00 Howard Chu <hyc(a)symas.com>: > leo(a)yuriev.ru wrote: > >> @@ -1265,8 +1264,10 @@ static void *search_stack( Operation *op ) >> } >> >> if ( !ret ) { >> - ret = ch_malloc( mdb->mi_search_stack_depth * >> MDB_IDL_UM_SIZE >> - * sizeof( ID ) ); >> + size_t case_stack = mdb->mi_search_stack_depth * >> MDB_IDL_UM_SIZE * sizeof( ID ); >> + size_t case_sctmp = MDB_IDL_UM_SIZE * sizeof( ID2 ); >> + size_t size = (case_stack > case_sctmp) ? case_stack : >> case_sctmp; >> + ret = ch_malloc( size ); >> if ( op->o_threadctx ) { >> ldap_pvt_thread_pool_setkey( op->o_threadctx, >> (void *)search_stack, >> ret, search_stack_free, NULL, NULL ); >> >> > Unnecessary. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --e89a8f8389d11704d5050b564d29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Updated.<div>Please pickup.<div><br></div><div>Leonid.<br>= <div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2014-12-29 1:13 G= MT+03:00 Howard Chu <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" = target=3D"_blank">hyc(a)symas.com</a>></span>:<br><blockquote class=3D"gma= il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef= t:1ex"><a href=3D"mailto:leo@yuriev.ru" target=3D"_blank">leo(a)yuriev.ru</a>= wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> @@ -1265,8 +1264,10 @@ static void *search_stack( Operation *op )<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( !ret ) {<br> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ret =3D ch_malloc( = mdb->mi_search_stack_depth * MDB_IDL_UM_SIZE<br> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0* sizeof( ID ) );<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0size_t case_stack = =3D mdb->mi_search_stack_depth * MDB_IDL_UM_SIZE * sizeof( ID );<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0size_t case_sctmp = =3D MDB_IDL_UM_SIZE * sizeof( ID2 );<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0size_t size =3D (ca= se_stack > case_sctmp) ? case_stack : case_sctmp;<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ret =3D ch_malloc( = size );<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( op->o_threa= dctx ) {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ldap_pvt_thread_pool_setkey( op->o_threadctx, (void *)search_= stack,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ret, search_stack_free, NULL, NULL )= ;<br> <br> </blockquote> <br> Unnecessary.<span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" target=3D"_blank">http://www.symas.com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/<u></u>project/</a><br> </font></span></blockquote></div><br></div></div></div></div> --e89a8f8389d11704d5050b564d29-- --e89a8f8389d11704db050b564d2b Content-Type: text/x-patch; charset=US-ASCII; name="its8011.patch" Content-Disposition: attachment; filename="its8011.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i49k3q0m0 Y29tbWl0IDA1ODdiOTA0YWVhOWNkMmVjNjc2YWFjNzM2MDM0ODNiODA1ODE2ZTAKQXV0aG9yOiBM ZW8gWXVyaWV2IDxsZW9AeXVyaWV2LnJ1PgpEYXRlOiAgIDIwMTQtMTItMjggMjM6MTQ6NTIgKzAz MDAKCiAgICBJVFMjODAxMTogZmV3IGNvcnJlY3Rpb25zIGZvciBsbWRiLWJhY2tlbmQ7CiAgICAK ICAgICBkbjJpZC5jOgogICAgICAgKyBhc3NlcnRpb24gZm9yIG1kYl9pZDJsX2luc2VydCgpIHJl c3VsdDsKICAgICAgIC0gdW5uZWNlc3NhcnkgYXNzaWdubWVudDsKICAgIAogICAgIHNlYXJjaC5j OgogICAgICAgLSB1bnVzZWQgdmFyaWFibGUgJ2ZpcnN0JzsKICAgICAgICsgcmFuZ2UtY2hlY2sg Zm9yIG1kYl9pZGxfc2VhcmNoKCkgcmVzdWx0OwoKZGlmZiAtLWdpdCBhL3NlcnZlcnMvc2xhcGQv YmFjay1tZGIvZG4yaWQuYyBiL3NlcnZlcnMvc2xhcGQvYmFjay1tZGIvZG4yaWQuYwppbmRleCA0 MWM0NzU4Li4wODkwYmNlIDEwMDY0NAotLS0gYS9zZXJ2ZXJzL3NsYXBkL2JhY2stbWRiL2RuMmlk LmMKKysrIGIvc2VydmVycy9zbGFwZC9iYWNrLW1kYi9kbjJpZC5jCkBAIC03NDYsNyArNzQ2LDgg QEAgbWRiX2lkc2NvcGVzKAogCQkJLyogcmVtZW1iZXIgb3VyIGNoYWluIG9mIHBhcmVudHMgKi8K IAkJCWlkMi5taWQgPSBpZDsKIAkJCWlkMi5tdmFsID0gZGF0YTsKLQkJCW1kYl9pZDJsX2luc2Vy dCggaXNjLT5zY3RtcCwgJmlkMiApOworCQkJcmMgPSBtZGJfaWQybF9pbnNlcnQoIGlzYy0+c2N0 bXAsICZpZDIgKTsKKwkJCWFzc2VydChyYyA9PSAwKTsKIAkJfQogCQlwdHIgPSBkYXRhLm12X2Rh dGE7CiAJCXB0ciArPSBkYXRhLm12X3NpemUgLSBzaXplb2YoSUQpOwpAQCAtNzYwLDkgKzc2MSwx MSBAQCBtZGJfaWRzY29wZXMoCiAJCWlmICggeCA8PSBpc2MtPnNjb3Blc1swXS5taWQgJiYgaXNj LT5zY29wZXNbeF0ubWlkID09IGlkICkgewogCQkJaWYgKCAhaXNjLT5zY29wZXNbeF0ubXZhbC5t dl9kYXRhICkgewogCQkJCS8qIFRoaXMgbm9kZSBpcyBpbiBzY29wZSwgYWRkIHBhcmVudCBjaGFp biB0byBzY29wZSAqLwotCQkJCWludCBpID0gaXNjLT5zY3RtcFswXS5taWQ7Ci0JCQkJZm9yICgg aSA9IDE7IGkgPD0gaXNjLT5zY3RtcFswXS5taWQ7IGkrKyApCi0JCQkJCW1kYl9pZDJsX2luc2Vy dCggaXNjLT5zY29wZXMsICZpc2MtPnNjdG1wW2ldICk7CisJCQkJaW50IGk7CisJCQkJZm9yICgg aSA9IDE7IGkgPD0gaXNjLT5zY3RtcFswXS5taWQ7IGkrKyApIHsKKwkJCQkJcmMgPSBtZGJfaWQy bF9pbnNlcnQoIGlzYy0+c2NvcGVzLCAmaXNjLT5zY3RtcFtpXSApOworCQkJCQlhc3NlcnQocmMg PT0gMCk7CisJCQkJfQogCQkJCS8qIGNoZWNrIGlkIGFnYWluIHNpbmNlIGluc2VydHMgbWF5IGhh dmUgY2hhbmdlZCBpdHMgcG9zaXRpb24gKi8KIAkJCQlpZiAoIGlzYy0+c2NvcGVzW3hdLm1pZCAh PSBpZCApCiAJCQkJCXggPSBtZGJfaWQybF9zZWFyY2goIGlzYy0+c2NvcGVzLCBpZCApOwpkaWZm IC0tZ2l0IGEvc2VydmVycy9zbGFwZC9iYWNrLW1kYi9zZWFyY2guYyBiL3NlcnZlcnMvc2xhcGQv YmFjay1tZGIvc2VhcmNoLmMKaW5kZXggOTA4OTAxNi4uMTg1ZDlmMSAxMDA2NDQKLS0tIGEvc2Vy dmVycy9zbGFwZC9iYWNrLW1kYi9zZWFyY2guYworKysgYi9zZXJ2ZXJzL3NsYXBkL2JhY2stbWRi L3NlYXJjaC5jCkBAIC0xNDAsNyArMTQwLDYgQEAgc3RhdGljIGludCBzZWFyY2hfYWxpYXNlcygK IAlzdHJ1Y3QgYmVydmFsIGJ2X2FsaWFzID0gQkVSX0JWQyggImFsaWFzIiApOwogCUF0dHJpYnV0 ZUFzc2VydGlvbiBhYV9hbGlhcyA9IEFUVFJJQlVURUFTU0VSVElPTl9JTklUOwogCUZpbHRlcglh ZjsKLQlpbnQgZmlyc3QgPSAxOwogCiAJYWxpYXNlcyA9IHN0YWNrOwkvKiBJREwgb2YgYWxsIGFs aWFzZXMgaW4gdGhlIGRhdGFiYXNlICovCiAJY3Vyc2NvcCA9IGFsaWFzZXMgKyBNREJfSURMX0RC X1NJWkU7CS8qIEFsaWFzZXMgaW4gdGhlIGN1cnJlbnQgc2NvcGUgKi8KQEAgLTgwNyw3ICs4MDYs NyBAQCBsb29wX2JlZ2luOgogCQkJCQlzY29wZW9rID0gMTsKIAkJCX0gZWxzZSB7CiAJCQkJaSA9 IG1kYl9pZGxfc2VhcmNoKCBjYW5kaWRhdGVzLCBpZCApOwotCQkJCWlmICggY2FuZGlkYXRlc1tp XSA9PSBpZCApCisJCQkJaWYgKGkgPD0gY2FuZGlkYXRlc1swXSAmJiBjYW5kaWRhdGVzW2ldID09 IGlkICkKIAkJCQkJc2NvcGVvayA9IDE7CiAJCQl9CiAJCQlpZiAoIHNjb3Blb2sgKQo= --e89a8f8389d11704db050b564d2b--

1 0

Re: (ITS#8011) few mistakes in lmdb-backend
by hyc＠symas.com 28 Dec '14

28 Dec '14

leo(a)yuriev.ru wrote: > @@ -1265,8 +1264,10 @@ static void *search_stack( Operation *op ) > } > > if ( !ret ) { > - ret = ch_malloc( mdb->mi_search_stack_depth * MDB_IDL_UM_SIZE > - * sizeof( ID ) ); > + size_t case_stack = mdb->mi_search_stack_depth * MDB_IDL_UM_SIZE * sizeof( ID ); > + size_t case_sctmp = MDB_IDL_UM_SIZE * sizeof( ID2 ); > + size_t size = (case_stack > case_sctmp) ? case_stack : case_sctmp; > + ret = ch_malloc( size ); > if ( op->o_threadctx ) { > ldap_pvt_thread_pool_setkey( op->o_threadctx, (void *)search_stack, > ret, search_stack_free, NULL, NULL ); > Unnecessary. -- -- 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#8011) few mistakes in lmdb-backend
by leo＠yuriev.ru 28 Dec '14

28 Dec '14

This is a multi-part message in MIME format. --------------060206050400040309010905 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit The attached files is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Peter-Service LLC, Moscow, Russia. Peter-Service LLC has not assigned rights and/or interest in this work to any party. I, Leonid Yuriev am authorized by Peter-Service LLC, my employer, to release this work under the following terms. Peter-Service LLC hereby places 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. --------------060206050400040309010905 Content-Type: text/x-patch; name="ITS8011.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ITS8011.patch" commit 1bdae5a756d803961db4d2c7f6d13e975f89f1f8 Author: Leo Yuriev <leo(a)yuriev.ru> Date: 2014-12-28 23:14:52 +0300 ITS#8011: few corrections for lmdb-backend; dn2id.c: + assertion for mdb_id2l_insert() result; - unnecessary assignment; search.c: - unused variable 'first'; + range-check for mdb_idl_search() result; * fix sctmp/stack allocation size; diff --git a/servers/slapd/back-mdb/dn2id.c b/servers/slapd/back-mdb/dn2id.c index 41c4758..0890bce 100644 --- a/servers/slapd/back-mdb/dn2id.c +++ b/servers/slapd/back-mdb/dn2id.c @@ -746,7 +746,8 @@ mdb_idscopes( /* remember our chain of parents */ id2.mid = id; id2.mval = data; - mdb_id2l_insert( isc->sctmp, &id2 ); + rc = mdb_id2l_insert( isc->sctmp, &id2 ); + assert(rc == 0); } ptr = data.mv_data; ptr += data.mv_size - sizeof(ID); @@ -760,9 +761,11 @@ mdb_idscopes( if ( x <= isc->scopes[0].mid && isc->scopes[x].mid == id ) { if ( !isc->scopes[x].mval.mv_data ) { /* This node is in scope, add parent chain to scope */ - int i = isc->sctmp[0].mid; - for ( i = 1; i <= isc->sctmp[0].mid; i++ ) - mdb_id2l_insert( isc->scopes, &isc->sctmp[i] ); + int i; + for ( i = 1; i <= isc->sctmp[0].mid; i++ ) { + rc = mdb_id2l_insert( isc->scopes, &isc->sctmp[i] ); + assert(rc == 0); + } /* check id again since inserts may have changed its position */ if ( isc->scopes[x].mid != id ) x = mdb_id2l_search( isc->scopes, id ); diff --git a/servers/slapd/back-mdb/search.c b/servers/slapd/back-mdb/search.c index 9089016..8bcdc10 100644 --- a/servers/slapd/back-mdb/search.c +++ b/servers/slapd/back-mdb/search.c @@ -140,7 +140,6 @@ static int search_aliases( struct berval bv_alias = BER_BVC( "alias" ); AttributeAssertion aa_alias = ATTRIBUTEASSERTION_INIT; Filter af; - int first = 1; aliases = stack; /* IDL of all aliases in the database */ curscop = aliases + MDB_IDL_DB_SIZE; /* Aliases in the current scope */ @@ -807,7 +806,7 @@ loop_begin: scopeok = 1; } else { i = mdb_idl_search( candidates, id ); - if ( candidates[i] == id ) + if (i <= candidates[0] && candidates[i] == id ) scopeok = 1; } if ( scopeok ) @@ -1265,8 +1264,10 @@ static void *search_stack( Operation *op ) } if ( !ret ) { - ret = ch_malloc( mdb->mi_search_stack_depth * MDB_IDL_UM_SIZE - * sizeof( ID ) ); + size_t case_stack = mdb->mi_search_stack_depth * MDB_IDL_UM_SIZE * sizeof( ID ); + size_t case_sctmp = MDB_IDL_UM_SIZE * sizeof( ID2 ); + size_t size = (case_stack > case_sctmp) ? case_stack : case_sctmp; + ret = ch_malloc( size ); if ( op->o_threadctx ) { ldap_pvt_thread_pool_setkey( op->o_threadctx, (void *)search_stack, ret, search_stack_free, NULL, NULL ); --------------060206050400040309010905--

1 0

(ITS#8011) few mistakes in lmdb-backend
by leo＠yuriev.ru 28 Dec '14

28 Dec '14

Full_Name: Leonid Yuriev Version: master OS: RHEL7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (31.130.36.33) Please review the patch, which will be attached shortly. mdb_idscopes(): + assertion for mdb_id2l_insert() result; - unnecessary assignment; static search_aliases(): - unused variable 'first'; + range-check for mdb_idl_search() result; static search_stack(): * fix sctmp/stack allocation size;

1 0

(ITS#8010) LMDB: New mdb_txn_begin() flag to init as reset
by scott＠GameRanger.com 22 Dec '14

22 Dec '14

Full_Name: Scott Kevill Version: n/a OS: n/a URL: Submission from: (NULL) (101.166.148.57) Using a read-only txn with mdb_txn_reset() and mdb_txn_renew() is a little clumsy at the moment because the first use needs to be a mdb_txn_begin(). This means either an initial mdb_txn_begin() + mdb_txn_reset() to get it into the reset state, or else for every operation to do something like: if (txn) mdb_txn_renew() else mdb_txn_begin() ... do work ... mdb_txn_reset() An additional flag (eg. MDB_RESET?) for mdb_txn_begin() that only worked in conjunction with MDB_RDONLY could save that (minor) wasted work.

1 0

Re: (ITS#7780) constraint_attribute <attr> <size|count> 0 cause segfault
by michael＠stroeder.com 20 Dec '14

20 Dec '14

ondra(a)mistotebe.net wrote: > On Fri, Dec 19, 2014 at 02:41:55AM +0000, michael(a)stroeder.com wrote: >> Just because I'm curious: >> >> What's the use-case for setting size and count to zero? >> >> If one wants to forbid an attribute completely one should probably use >> NOT in a DIT content rule for the STRUCTURAL object class. >> (This does not mean that this shouldn't be fixed though.) > > I personally thought that OpenLDAP did not implement DIT content rules > at all. DIT *content* rules are implemented and I'm using NOT quite often to reject attributes I don't need in a deployment. Kind of a local profile for standard schema. DIT *structure* rules and name forms are not supported yet. Ciao, Michael.

1 0

Re: (ITS#7780) constraint_attribute <attr> <size|count> 0 cause segfault
by ondra＠mistotebe.net 20 Dec '14

20 Dec '14

On Fri, Dec 19, 2014 at 02:41:55AM +0000, michael(a)stroeder.com wrote: > Just because I'm curious: > > What's the use-case for setting size and count to zero? > > If one wants to forbid an attribute completely one should probably use > NOT in a DIT content rule for the STRUCTURAL object class. > (This does not mean that this shouldn't be fixed though.) I personally thought that OpenLDAP did not implement DIT content rules at all.

1 0

Re: (ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by michael＠stroeder.com 19 Dec '14

19 Dec '14

Michael Ströder wrote: > Quanah Gibson-Mount wrote: >> --On Friday, December 19, 2014 11:29 PM +0100 Michael Ströder >> <michael(a)stroeder.com> wrote: >> >>>> 2.4 is for bugfixes and regressions only. >> >> See above. > > Well, I consider it to be a serious defect that the old *Record attribute type > descriptions defined in obsoleted RFC 1274 are still in cosine.(ldif|schema) > even though they are not in RFC 4524. > > I also consider it to be a bug that aRecord and aAAARecord don't have the same > attribute type description. Hmm, this issue with cosine.(ldif|schema) is sitting in ITS since more than four years: ITS#6151 (slipped from my memory before filing this issue) Ciao, Michael.

1 0

Re: (ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by michael＠stroeder.com 19 Dec '14

19 Dec '14

Quanah Gibson-Mount wrote: > --On Friday, December 19, 2014 11:29 PM +0100 Michael Ströder > <michael(a)stroeder.com> wrote: > >>> 2.4 is for bugfixes and regressions only. > > See above. Well, I consider it to be a serious defect that the old *Record attribute type descriptions defined in obsoleted RFC 1274 are still in cosine.(ldif|schema) even though they are not in RFC 4524. I also consider it to be a bug that aRecord and aAAARecord don't have the same attribute type description. Ciao, Michael.

1 0

Re: (ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by quanah＠zimbra.com 19 Dec '14

19 Dec '14

--On Friday, December 19, 2014 11:29 PM +0100 Michael Str=C3=B6der=20 <michael(a)stroeder.com> wrote: >> 2.4 is for bugfixes and regressions only. See above. -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by michael＠stroeder.com 19 Dec '14

19 Dec '14

This is a cryptographically signed message in MIME format. --------------ms040409080506030800020107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable quanah(a)zimbra.com wrote: > --On Friday, December 19, 2014 8:25 PM +0000 michael(a)stroeder.com wrote= : >=20 >> There isn't a new version of the COSINE schema. >> >> But the attributes defined in RFC 1274, which were not added to RFC 45= 24 >> [1], are used in the usual DNS zone schema which defines object class >> 'dNSDomain2'. The DNS zone schema defines more attributes for DNS RRs = and >> all of them have a SUBSTR matching rule defined. >> >> If you reject this patch because you don't want to change a "standard"= >> schema the other possibility would be to completely hunk out these RFC= >> 1274 declarations from cosine.(schema|ldif) to avoid collision with >> separate DNS schema files adding them. >> >> [1] http://tools.ietf.org/html/rfc4524#appendix-A.4 >=20 > This sounds like a 2.5 feature request then. We can keep it in mind fo= r=20 > that. >=20 > 2.4 is for bugfixes and regressions only. My patch would be trivial and without causing any harm. Ciao, Michael. --------------ms040409080506030800020107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1 WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y 0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5 wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAB8HJ30IRnmli5Frde4TnF4mgikOiXbYDWYga 5GrFoEUi6aaYOhiv+1WAWh3/d69Ak75p3xPnCmihjjbYeQc3hrVQju6MIpxT8+tBLGa/bwAC yXgWj8idjWdIWMzLxjCPcQb4R2PVmkKTNNE0ZmMFrpSPtRjtRbvWRhxJ0IF7y9z1mLfo6cca RdE5YiKLfAEosMRmrGSfDQKP1NPLmXKWVjPIeS7hpcsM+GJitPOFaLCBibB5ou9b/KphWwdG lby53Oo6vrG9RVy5GZ8xMQ0ztFKVFlXDb7n4j7OfuOo6utQs7UU/sujlw+KWwylIw7Cgmc8t CA1m9c48U7pVoMI5ujGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwtNUDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNDEyMTkyMjI5NTlaMCMGCSqGSIb3DQEJBDEWBBR+22VvvmCp +A94Q+dBdVogbCCyDDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQIDC01QMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwDQYJKoZIhvcNAQEBBQAEggEAtSohllra XuuH1iDkuh5hnextf2Q78lXhr6Z6LW3jBy1O7lh0eT84ib/PGWMQSFtQzt6hWlJH9CChsS19 QQZNRgntzc557fBs023zIbvH3JR+Yr32jKTHvOvbTZOjWf4rU3B7hn4kcgKKvVd7dkx74eT9 gjNVYGSfQNagHdXCEuXkijvA0SwcBrmT9sU44CMUHS45a7kfza0Qihjxli8Cf3lJTty5ROy+ PdqW9XdFqKhP9Lf/dX1IdCIZ+32Eku7thoSuPs7vO2Di6KjQk5RVDx+EPqcnuBpHo9lFvKfi rAoxx5LoY0ZOGsxBOnDs3h4idzmCqdsBcTPjFp6SZH4glAAAAAAAAA== --------------ms040409080506030800020107--

1 0

Re: (ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by quanah＠zimbra.com 19 Dec '14

19 Dec '14

--On Friday, December 19, 2014 8:25 PM +0000 michael(a)stroeder.com wrote: > There isn't a new version of the COSINE schema. > > But the attributes defined in RFC 1274, which were not added to RFC 4524 > [1], are used in the usual DNS zone schema which defines object class > 'dNSDomain2'. The DNS zone schema defines more attributes for DNS RRs and > all of them have a SUBSTR matching rule defined. > > If you reject this patch because you don't want to change a "standard" > schema the other possibility would be to completely hunk out these RFC > 1274 declarations from cosine.(schema|ldif) to avoid collision with > separate DNS schema files adding them. > > Ciao, Michael. > > [1] http://tools.ietf.org/html/rfc4524#appendix-A.4 This sounds like a 2.5 feature request then. We can keep it in mind for that. 2.4 is for bugfixes and regressions only. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by michael＠stroeder.com 19 Dec '14

19 Dec '14

Howard Chu wrote: > I didn't know there was a new revision of the COSINE schema. Where was it > published? There isn't a new version of the COSINE schema. But the attributes defined in RFC 1274, which were not added to RFC 4524 [1], are used in the usual DNS zone schema which defines object class 'dNSDomain2'. The DNS zone schema defines more attributes for DNS RRs and all of them have a SUBSTR matching rule defined. If you reject this patch because you don't want to change a "standard" schema the other possibility would be to completely hunk out these RFC 1274 declarations from cosine.(schema|ldif) to avoid collision with separate DNS schema files adding them. Ciao, Michael. [1] http://tools.ietf.org/html/rfc4524#appendix-A.4

1 0

Re: (ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by hyc＠symas.com 19 Dec '14

19 Dec '14

michael(a)stroeder.com wrote: > Full_Name: > Version: HEAD > OS: > URL: > Submission from: (NULL) (79.219.126.25) > > > SUBSTR caseIgnoreIA5SubstringsMatch should be added to attributes *Record in > cosine schema files to be compatible to attributes defined in UNINETT's DNS > schema files. I didn't know there was a new revision of the COSINE schema. Where was it published? -- -- 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#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by michael＠stroeder.com 19 Dec '14

19 Dec '14

This is a cryptographically signed message in MIME format. --------------ms010702010502010600050002 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Another question in this context: Wouldn't it make sense to keep the matchingRuleUse descriptions in sync? Unfortunately they are in schema_prep.c. :-( Or maybe slapd should automagically update matchingRuleUse according to attribute type descriptions found in the subschema. One could argue that APPLIES in matchingRuleUse is not well designed beca= use it references attribute types and instead of LDAP syntaxes. Background: I was wondering whether I could work around missing SUBSTR matching rules= in web2ldap by looking at matchingRuleUse and auto-generate appropriate extensible filters=85 Ciao, Michael. --------------ms010702010502010600050002 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1 WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y 0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5 wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAB8HJ30IRnmli5Frde4TnF4mgikOiXbYDWYga 5GrFoEUi6aaYOhiv+1WAWh3/d69Ak75p3xPnCmihjjbYeQc3hrVQju6MIpxT8+tBLGa/bwAC yXgWj8idjWdIWMzLxjCPcQb4R2PVmkKTNNE0ZmMFrpSPtRjtRbvWRhxJ0IF7y9z1mLfo6cca RdE5YiKLfAEosMRmrGSfDQKP1NPLmXKWVjPIeS7hpcsM+GJitPOFaLCBibB5ou9b/KphWwdG lby53Oo6vrG9RVy5GZ8xMQ0ztFKVFlXDb7n4j7OfuOo6utQs7UU/sujlw+KWwylIw7Cgmc8t CA1m9c48U7pVoMI5ujGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwtNUDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNDEyMTkxMDUyMzZaMCMGCSqGSIb3DQEJBDEWBBSbfY9Fm0K6 dPiZuj/OvYAFG2tsVzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQIDC01QMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwDQYJKoZIhvcNAQEBBQAEggEAv4gHo1JQ 6MbHxiLVIx/M9XSeHMakWCgFoadXIQ5Ha32sZohORTmUWEJC/FtEXTvpLBAho4BRbCtIYfxd pSBmurQwZjyH7AknXTmtpCCyMzs5fOxJN+rGgnu102EHFAVKwgAFxY0/wkdWNDhYujHRmIUA ty+j0MjbcG7EWq4FP4vCEiz2lr6mfABL1Gg2tsPLqklQ+WQlR733awXUQ+8yf9rG7BSLOsGR qx9ZJNXTruaCE7/CrQSLsEeeX7HG9sSqb8LQ5gVvrL8p97zcBVJNJB4skWPbRPw9tnpw91sW Ivwvt67JQydZBEMs6MOpss2UMru0ZeN0pEHRlrj2gFVgWAAAAAAAAA== --------------ms010702010502010600050002--

1 0

Re: (ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by michael＠stroeder.com 19 Dec '14

19 Dec '14

Hmmpf! ITS destroys formatting. See also: http://www.stroeder.com/temp/openldap-its-8009.patch

1 0

Re: (ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by michael＠stroeder.com 19 Dec '14

19 Dec '14

This is a multi-part message in MIME format. --------------040505080606070501000304 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Find attached a patch file for this. I'd be glad if this could make it into 2.4.41. I, Michael Ströder, hereby place the attached 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. --------------040505080606070501000304 Content-Type: text/x-patch; name="openldap-its-8009.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="openldap-its-8009.patch" diff --git a/servers/slapd/schema/cosine.ldif b/servers/slapd/schema/cosi= ne.ldif index d207111..d37a988 100644 --- a/servers/slapd/schema/cosine.ldif +++ b/servers/slapd/schema/cosine.ldif @@ -80,18 +80,24 @@ olcAttributeTypes: ( 0.9.2342.19200300.100.1.21 NAME = 'secretary' DESC 'RFC 6.115.121.1.12 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.22 NAME 'otherMailbox' SYNT= AX 1.3.6.1.4.1.1466.115.121.1.39 ) -olcAttributeTypes: ( 0.9.2342.19200300.100.1.26 NAME 'aRecord' EQUALITY = ca - seIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) -olcAttributeTypes: ( 0.9.2342.19200300.100.1.27 NAME 'mDRecord' EQUALITY= c - aseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) -olcAttributeTypes: ( 0.9.2342.19200300.100.1.28 NAME 'mXRecord' EQUALITY= c - aseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) -olcAttributeTypes: ( 0.9.2342.19200300.100.1.29 NAME 'nSRecord' EQUALITY= c - aseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) -olcAttributeTypes: ( 0.9.2342.19200300.100.1.30 NAME 'sOARecord' EQUALIT= Y=20 - caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) -olcAttributeTypes: ( 0.9.2342.19200300.100.1.31 NAME 'cNAMERecord' EQUAL= IT - Y caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) +olcAttributeTypes: ( 0.9.2342.19200300.100.1.26 NAME 'aRecord'=20 + EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch=20 + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) +olcAttributeTypes: ( 0.9.2342.19200300.100.1.27 NAME 'mDRecord'=20 + EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch=20 + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) +olcAttributeTypes: ( 0.9.2342.19200300.100.1.28 NAME 'mXRecord'=20 + EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch=20 + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) +olcAttributeTypes: ( 0.9.2342.19200300.100.1.29 NAME 'nSRecord'=20 + EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch=20 + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) +olcAttributeTypes: ( 0.9.2342.19200300.100.1.30 NAME 'sOARecord'=20 + EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch=20 + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) +olcAttributeTypes: ( 0.9.2342.19200300.100.1.31 NAME 'cNAMERecord'=20 + EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch=20 + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.38 NAME 'associatedName' DE= SC 'RFC1274: DN of entry associated with domain' EQUALITY distinguishedNa= meMatc h SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) diff --git a/servers/slapd/schema/cosine.schema b/servers/slapd/schema/co= sine.schema index 8ea7090..6706525 100644 --- a/servers/slapd/schema/cosine.schema +++ b/servers/slapd/schema/cosine.schema @@ -477,12 +477,14 @@ attributetype ( 0.9.2342.19200300.100.1.22 NAME 'ot= herMailbox' ## incorrect syntax? attributetype ( 0.9.2342.19200300.100.1.26 NAME 'aRecord' EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) =20 ## missing from RFC1274 ## incorrect syntax? attributetype ( 0.9.2342.19200300.100.1.27 NAME 'mDRecord' EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) =20 # 9.3.23. MX Record @@ -498,6 +500,7 @@ attributetype ( 0.9.2342.19200300.100.1.27 NAME 'mDRe= cord' ## incorrect syntax!! attributetype ( 0.9.2342.19200300.100.1.28 NAME 'mXRecord' EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) =20 # 9.3.24. NS Record @@ -513,6 +516,7 @@ attributetype ( 0.9.2342.19200300.100.1.28 NAME 'mXRe= cord' ## incorrect syntax!! attributetype ( 0.9.2342.19200300.100.1.29 NAME 'nSRecord' EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) =20 # 9.3.25. SOA Record @@ -528,6 +532,7 @@ attributetype ( 0.9.2342.19200300.100.1.29 NAME 'nSRe= cord' ## incorrect syntax!! attributetype ( 0.9.2342.19200300.100.1.30 NAME 'sOARecord' EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) =20 # 9.3.26. CNAME Record @@ -543,6 +548,7 @@ attributetype ( 0.9.2342.19200300.100.1.30 NAME 'sOAR= ecord' ## incorrect syntax!! attributetype ( 0.9.2342.19200300.100.1.31 NAME 'cNAMERecord' EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) =20 # 9.3.27. Associated Domain --------------040505080606070501000304--

1 0

(ITS#8009) SUBSTR caseIgnoreIA5SubstringsMatch for *Record in cosine schema
by michael＠stroeder.com 19 Dec '14

19 Dec '14

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (79.219.126.25) SUBSTR caseIgnoreIA5SubstringsMatch should be added to attributes *Record in cosine schema files to be compatible to attributes defined in UNINETT's DNS schema files. Patch will follow.

1 0

Re: (ITS#7780) constraint_attribute <attr> <size|count> 0 cause segfault
by michael＠stroeder.com 18 Dec '14

18 Dec '14

hyc(a)symas.com wrote: > ondra(a)mistotebe.net wrote: >> On Wed, Dec 17, 2014 at 03:33:32PM +0000, hyc(a)symas.com wrote: >>> Hello Ondrej, >>> I tried your patch but it breaks test064-constraint. >> >> Hi Howard, >> there is useless code that caused it to read an unitialized variable. A >> fix removing that code is at >> ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20141218-ITS-7781.patch >> >> Thanks for identifying and fixing the problem in the meantime. >> > Ok. But looking at this patch, the lines in question actually are > needed, since they take care of errors in the cases for CONSTRAINT_COUNT > and CONSTRAINT_SET. Just because I'm curious: What's the use-case for setting size and count to zero? If one wants to forbid an attribute completely one should probably use NOT in a DIT content rule for the STRUCTURAL object class. (This does not mean that this shouldn't be fixed though.) Just my 2 cents. Ciao, Michael.

1 0

Re: (ITS#7780) constraint_attribute <attr> <size|count> 0 cause segfault
by hyc＠symas.com 18 Dec '14

18 Dec '14

ondra(a)mistotebe.net wrote: > On Wed, Dec 17, 2014 at 03:33:32PM +0000, hyc(a)symas.com wrote: >> Hello Ondrej, >> I tried your patch but it breaks test064-constraint. > > Hi Howard, > there is useless code that caused it to read an unitialized variable. A > fix removing that code is at > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20141218-ITS-7781.patch > > Thanks for identifying and fixing the problem in the meantime. > Ok. But looking at this patch, the lines in question actually are needed, since they take care of errors in the cases for CONSTRAINT_COUNT and CONSTRAINT_SET. -- -- 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#7780) constraint_attribute <attr> <size|count> 0 cause segfault
by ondra＠mistotebe.net 18 Dec '14

18 Dec '14

On Thu, Dec 18, 2014 at 09:42:18PM +0000, ondra(a)mistotebe.net wrote: > Hi Howard, > there is useless code that caused it to read an unitialized variable. A > fix removing that code is at > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20141218-ITS-7781.patch Nevermind that, that code is needed and I should be running static analysers more often when it's late.

1 0

Re: (ITS#7780) constraint_attribute <attr> <size|count> 0 cause segfault
by ondra＠mistotebe.net 18 Dec '14

18 Dec '14

On Wed, Dec 17, 2014 at 03:33:32PM +0000, hyc(a)symas.com wrote: > Hello Ondrej, > I tried your patch but it breaks test064-constraint. Hi Howard, there is useless code that caused it to read an unitialized variable. A fix removing that code is at ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20141218-ITS-7781.patch Thanks for identifying and fixing the problem in the meantime.

1 0

Re: (ITS#8005) crash when multiple olcDbURI are defined for chaining
by hyc＠symas.com 17 Dec '14

17 Dec '14

Khosrow Ebrahimpour wrote: > > On 12/17/2014 03:22 PM, Howard Chu wrote: >>>> Note that test032-chain in the test suite tests a config with two URIs >>>> and it passes successfully. >>> From what I see although test032 tests two URIs, it doesn't test two >>> URIs defined in the same olcDbURI field. The crash I've discovered only >>> occurs when two URIs are defined at the same time. And like I mentioned >>> in the issue report, this should be valid according to the man-page. No. slapo-chain(5) states explicitly: chain-uri <ldapuri> This directive instantiates a new underlying ldap database and instructs it about which URI to contact to chase referrals. As opposed to what stated in slapd-ldap(5), only one URI can appear after this directive; Closing this ITS. -- -- 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#8005) crash when multiple olcDbURI are defined for chaining
by khosrow.ebrahimpour＠ssc-spc.gc.ca 17 Dec '14

17 Dec '14

On 12/16/2014 04:47 PM, Howard Chu wrote: > Khosrow Ebrahimpour wrote: >> >> On 12/15/2014 01:20 PM, Howard Chu wrote: >>> khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: >>>> On 12/15/2014 12:09 PM, Howard Chu wrote: >>>>> khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: >>>>>> Full_Name: K. Ebrahimpour >>>>>> Version: RE24 (commit dbc6741750de79b852ec9f728abb8b1425b6f03f) >>>>>> OS: Ubuntu 14.04.1 >>>>>> URL: https://gist.github.com/khosrow/cc6640cad9275a2cd041 >>>>>> Submission from: (NULL) (205.211.133.128) >>>>> >>>>>> Finally, I'm running OpenLDAP 2.4.31 on Ubuntu Trusty, but was also >>>>>> able to >>>>>> replicate this same error on OpenLDAP 2.4.28 on Ubuntu Precise. >>>>> >>>>> The current release is 2.4.40. For such old releases you should >>>>> contact Ubuntu for support. >>>>> >>>> I may not have been clear enough on which versions I have tested. >>>> Please >>>> see the *VERSION* field in the ITS submission form for the correct >>>> version. >>>> >>>> To clarify, I have tested and reproduced the bug on the following >>>> versions: >>>> >>>> * 2.4.28 on Ubuntu 12.04 (official Ubuntu package) >>>> * 2.4.31 on Ubuntu 14.04 (official Ubuntu package) >>>> * RE24 commit #dbc6741750de79b852ec9f728abb8b1425b6f03f on Ubuntu >>>> 14.04 >>>> (from OpenLDAP git repo) >>>> >>>> I understand the two first instances are old releases, I simply tested >>>> the bug on progressively newer versions of the software. Are you >>>> saying >>>> that the third tested version is also old? >>> >>> That commit ID is a few months old, from before 2.4.40 was released. >>> We are currently preparing to release 2.4.41, so yes, it's old. >>> >> Bug confirmed and replicated against OPENLDAP_REL_ENG_2_4 branch on >> commit 87c3614bee6de3a29ff95e311b2870322f1e35f0. I have updated the gist >> (in the bug report) with a new crash log from the replica server. > > Note that test032-chain in the test suite tests a config with two URIs > and it passes successfully. From what I see although test032 tests two URIs, it doesn't test two URIs defined in the same olcDbURI field. The crash I've discovered only occurs when two URIs are defined at the same time. And like I mentioned in the issue report, this should be valid according to the man-page. > > 1) provide a gdb stack trace of your crash > 2) provide a complete config that reproduces your crash, including the > data and commands used. Crash data now available at http://khosrow.ca/its8005 > > It might be easiest for you to edit the test032 setup to match yours. > Thanks,

1 0

Re: (ITS#8008) proxyauth with saslmech EXTERNAL not working
by hyc＠symas.com 17 Dec '14

17 Dec '14

hyc(a)symas.com wrote: > Looks like you've compiled without DEBUG enabled, otherwise your 2.4.26 > build would have died with an assert() failure there. > > Send a complete config that reproduces the issue. Repeating myself: > Also give the complete > command you 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#8008) proxyauth with saslmech EXTERNAL not working
by hyc＠symas.com 17 Dec '14

17 Dec '14

Dirk Kastens wrote: > Hi, > > I have attached my config directory. For future reference - just use slapcat -n0. The slapd config database internal format will not always be a directory tree, but slapcat will always do the right thing. -- -- 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#7780) constraint_attribute <attr> <size|count> 0 cause segfault
by hyc＠symas.com 17 Dec '14

17 Dec '14

Hello Ondrej, I tried your patch but it breaks test064-constraint. -- -- 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#8005) crash when multiple olcDbURI are defined for chaining
by hyc＠symas.com 16 Dec '14

16 Dec '14

Khosrow Ebrahimpour wrote: > > On 12/15/2014 01:20 PM, Howard Chu wrote: >> khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: >>> On 12/15/2014 12:09 PM, Howard Chu wrote: >>>> khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: >>>>> Full_Name: K. Ebrahimpour >>>>> Version: RE24 (commit dbc6741750de79b852ec9f728abb8b1425b6f03f) >>>>> OS: Ubuntu 14.04.1 >>>>> URL: https://gist.github.com/khosrow/cc6640cad9275a2cd041 >>>>> Submission from: (NULL) (205.211.133.128) >>>> >>>>> Finally, I'm running OpenLDAP 2.4.31 on Ubuntu Trusty, but was also >>>>> able to >>>>> replicate this same error on OpenLDAP 2.4.28 on Ubuntu Precise. >>>> >>>> The current release is 2.4.40. For such old releases you should >>>> contact Ubuntu for support. >>>> >>> I may not have been clear enough on which versions I have tested. Please >>> see the *VERSION* field in the ITS submission form for the correct >>> version. >>> >>> To clarify, I have tested and reproduced the bug on the following >>> versions: >>> >>> * 2.4.28 on Ubuntu 12.04 (official Ubuntu package) >>> * 2.4.31 on Ubuntu 14.04 (official Ubuntu package) >>> * RE24 commit #dbc6741750de79b852ec9f728abb8b1425b6f03f on Ubuntu 14.04 >>> (from OpenLDAP git repo) >>> >>> I understand the two first instances are old releases, I simply tested >>> the bug on progressively newer versions of the software. Are you saying >>> that the third tested version is also old? >> >> That commit ID is a few months old, from before 2.4.40 was released. >> We are currently preparing to release 2.4.41, so yes, it's old. >> > Bug confirmed and replicated against OPENLDAP_REL_ENG_2_4 branch on > commit 87c3614bee6de3a29ff95e311b2870322f1e35f0. I have updated the gist > (in the bug report) with a new crash log from the replica server. Note that test032-chain in the test suite tests a config with two URIs and it passes successfully. 1) provide a gdb stack trace of your crash 2) provide a complete config that reproduces your crash, including the data and commands used. It might be easiest for you to edit the test032 setup to match yours. -- -- 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#8005) crash when multiple olcDbURI are defined for chaining
by khosrow.ebrahimpour＠ssc-spc.gc.ca 16 Dec '14

16 Dec '14

On 12/15/2014 01:20 PM, Howard Chu wrote: > khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: >> On 12/15/2014 12:09 PM, Howard Chu wrote: >>> khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: >>>> Full_Name: K. Ebrahimpour >>>> Version: RE24 (commit dbc6741750de79b852ec9f728abb8b1425b6f03f) >>>> OS: Ubuntu 14.04.1 >>>> URL: https://gist.github.com/khosrow/cc6640cad9275a2cd041 >>>> Submission from: (NULL) (205.211.133.128) >>> >>>> Finally, I'm running OpenLDAP 2.4.31 on Ubuntu Trusty, but was also >>>> able to >>>> replicate this same error on OpenLDAP 2.4.28 on Ubuntu Precise. >>> >>> The current release is 2.4.40. For such old releases you should >>> contact Ubuntu for support. >>> >> I may not have been clear enough on which versions I have tested. Please >> see the *VERSION* field in the ITS submission form for the correct >> version. >> >> To clarify, I have tested and reproduced the bug on the following >> versions: >> >> * 2.4.28 on Ubuntu 12.04 (official Ubuntu package) >> * 2.4.31 on Ubuntu 14.04 (official Ubuntu package) >> * RE24 commit #dbc6741750de79b852ec9f728abb8b1425b6f03f on Ubuntu 14.04 >> (from OpenLDAP git repo) >> >> I understand the two first instances are old releases, I simply tested >> the bug on progressively newer versions of the software. Are you saying >> that the third tested version is also old? > > That commit ID is a few months old, from before 2.4.40 was released. > We are currently preparing to release 2.4.41, so yes, it's old. > Bug confirmed and replicated against OPENLDAP_REL_ENG_2_4 branch on commit 87c3614bee6de3a29ff95e311b2870322f1e35f0. I have updated the gist (in the bug report) with a new crash log from the replica server. -- Khosrow

1 0

Re: (ITS#8008) proxyauth with saslmech EXTERNAL not working
by hyc＠symas.com 16 Dec '14

16 Dec '14

dkastens(a)uos.de wrote: > Full_Name: Dirk Kastens > Version: 2.4.40 > OS: RedHat SL 7.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:638:508:3d0:8d09:a681:a06e:29f0) > > > This is a duplicate of bug #7993 that has been closed. > > Meanwhile I compiled openldap myself. > > At first, I compiled openldap-2.4.40. I configured ldap as a replica server. It > connects with saslmech EXTERNAL to the master server. > When I configure idassert-bind with saslmech EXTERNAL and try to change an > entry, ldapmodify fails with > > ldap_modify: Other (e.g., implementation specific) error (80) > > slapd logs the message: > --------------------------- > send_ldap_result: referral="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de" > >>> dnPrettyNormal: > <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de> > <<< dnPrettyNormal: > <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de>, > <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de> > conn=1000 op=1 ldap_chain_op: > ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de" > -> "ldap://ldap-master.rz.uni-osnabrueck.de" > conn=1000 op=1 ldap_chain_op: > ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de": > URI="ldap://ldap-master.rz.uni-osnabrueck.de" found in cache > =>ldap_back_getconn: conn=1000 op=1: lc=0x7faca820bc70 inserted refcnt=1 > rc=0 > Error: ldap_back_is_proxy_authz returned 0, misconfigured URI? > send_ldap_result: conn=1000 op=1 p=3 > send_ldap_result: err=80 matched="" text="misconfigured URI?" > send_ldap_result: conn=1000 op=1 p=3 > send_ldap_result: err=80 matched="" text="" > send_ldap_response: msgid=2 tag=103 err=80 > --------------------------- > > Then I compiled openldap-2.4.26 and used the same configuration. The modify with > saslmech EXTERNAL succeeded: > > --------------------------- > send_ldap_result: conn=1001 op=1 p=3 > send_ldap_result: err=10 matched="" text="" > send_ldap_result: referral="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de" > >>> dnPrettyNormal: > <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de> > <<< dnPrettyNormal: > <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de>, > <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de> > conn=1001 op=1 ldap_chain_op: > ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de" > -> "ldap://ldap-master.rz.uni-osnabrueck.de" > conn=1001 op=1 ldap_chain_op: > ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de": > URI="ldap://ldap-master.rz.uni-osnabrueck.de" found in cache > =>ldap_back_getconn: conn=1001 op=1: lc=0x7f4f201fe6f0 inserted refcnt=1 > rc=0 > send_ldap_result: conn=1001 op=1 p=3 > send_ldap_result: err=0 matched="" text="" > send_ldap_response: msgid=2 tag=103 err=0 > --------------------------- > > With a quick look I found out, that the function ldap_back_dobind_int in > server/slapd/back-ldap/bind.c differs. In 2.4.26 you have: > > --------------------------- > if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { > if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY( > &bindcred ) ) { > /* if we got here, it shouldn't return result */ > rc = ldap_back_is_proxy_authz( op, rs, > LDAP_BACK_DONTSEND, &binddn, &bindcred );A A assert( rc == > 1 ); > } > rc = ldap_back_proxy_authz_bind( lc, op, rs, sendok, &binddn, > &bindcred ); > goto done; > } > --------------------------- > > while in 2.4.40 there is: > > --------------------------- > if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { > if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY( &bindcred ) ) > { > /* if we got here, it shouldn't return result */ > rc = ldap_back_is_proxy_authz( op, rs, > LDAP_BACK_DONTSEND, &binddn,2&bindcred ); > if ( rc != 1 ) { > Debug( LDAP_DEBUG_ANY, "Error: ldap_back_is_proxy_authz " > "returned %d, misconfigured URI?\n", rc, 0, 0 ); > rs->sr_err = LDAP_OTHER; > rs->sr_text = "misconfigured URI?"; > LP_P_BACK_CONN_ISBOUND_CLEAR( lc ); > if ( sendok & LDAP_BACK_SENDERR ) { > send_ldap_result( op, rs ); > } > goto done; > } > rc = ldap_back_proxy_authz_bind( lc, op, rs, sendok, &binddn, > &bindcred ); > goto done; > } > -------------------------- > > This is where the error message comes from ("misconfigured URI?") Looks like you've compiled without DEBUG enabled, otherwise your 2.4.26 build would have died with an assert() failure there. Send a complete config that reproduces the issue. Also give the complete command you used. So far this just looks like a misconfiguration to me. -- -- 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#8008) proxyauth with saslmech EXTERNAL not working
by dkastens＠uos.de 15 Dec '14

15 Dec '14

Full_Name: Dirk Kastens Version: 2.4.40 OS: RedHat SL 7.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:638:508:3d0:8d09:a681:a06e:29f0) This is a duplicate of bug #7993 that has been closed. Meanwhile I compiled openldap myself. At first, I compiled openldap-2.4.40. I configured ldap as a replica server. It connects with saslmech EXTERNAL to the master server. When I configure idassert-bind with saslmech EXTERNAL and try to change an entry, ldapmodify fails with ldap_modify: Other (e.g., implementation specific) error (80) slapd logs the message: --------------------------- send_ldap_result: referral="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de" >>> dnPrettyNormal: <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de> <<< dnPrettyNormal: <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de>, <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de> conn=1000 op=1 ldap_chain_op: ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de" -> "ldap://ldap-master.rz.uni-osnabrueck.de" conn=1000 op=1 ldap_chain_op: ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de": URI="ldap://ldap-master.rz.uni-osnabrueck.de" found in cache =>ldap_back_getconn: conn=1000 op=1: lc=0x7faca820bc70 inserted refcnt=1 rc=0 Error: ldap_back_is_proxy_authz returned 0, misconfigured URI? send_ldap_result: conn=1000 op=1 p=3 send_ldap_result: err=80 matched="" text="misconfigured URI?" send_ldap_result: conn=1000 op=1 p=3 send_ldap_result: err=80 matched="" text="" send_ldap_response: msgid=2 tag=103 err=80 --------------------------- Then I compiled openldap-2.4.26 and used the same configuration. The modify with saslmech EXTERNAL succeeded: --------------------------- send_ldap_result: conn=1001 op=1 p=3 send_ldap_result: err=10 matched="" text="" send_ldap_result: referral="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de" >>> dnPrettyNormal: <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de> <<< dnPrettyNormal: <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de>, <uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de> conn=1001 op=1 ldap_chain_op: ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de" -> "ldap://ldap-master.rz.uni-osnabrueck.de" conn=1001 op=1 ldap_chain_op: ref="ldap://ldap-master.rz.uni-osnabrueck.de/uid=xmuster,ou=people,dc=uni-osnabrueck,dc=de": URI="ldap://ldap-master.rz.uni-osnabrueck.de" found in cache =>ldap_back_getconn: conn=1001 op=1: lc=0x7f4f201fe6f0 inserted refcnt=1 rc=0 send_ldap_result: conn=1001 op=1 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=2 tag=103 err=0 --------------------------- With a quick look I found out, that the function ldap_back_dobind_int in server/slapd/back-ldap/bind.c differs. In 2.4.26 you have: --------------------------- if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY( &bindcred ) ) { /* if we got here, it shouldn't return result */ rc = ldap_back_is_proxy_authz( op, rs, LDAP_BACK_DONTSEND, &binddn, &bindcred );A A assert( rc == 1 ); } rc = ldap_back_proxy_authz_bind( lc, op, rs, sendok, &binddn, &bindcred ); goto done; } --------------------------- while in 2.4.40 there is: --------------------------- if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY( &bindcred ) ) { /* if we got here, it shouldn't return result */ rc = ldap_back_is_proxy_authz( op, rs, LDAP_BACK_DONTSEND, &binddn,2&bindcred ); if ( rc != 1 ) { Debug( LDAP_DEBUG_ANY, "Error: ldap_back_is_proxy_authz " "returned %d, misconfigured URI?\n", rc, 0, 0 ); rs->sr_err = LDAP_OTHER; rs->sr_text = "misconfigured URI?"; LP_P_BACK_CONN_ISBOUND_CLEAR( lc ); if ( sendok & LDAP_BACK_SENDERR ) { send_ldap_result( op, rs ); } goto done; } rc = ldap_back_proxy_authz_bind( lc, op, rs, sendok, &binddn, &bindcred ); goto done; } -------------------------- This is where the error message comes from ("misconfigured URI?")

1 0

(ITS#8007) Add option for restricting max entry size
by hyc＠openldap.org 15 Dec '14

15 Dec '14

Full_Name: Howard Chu Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc Sometimes it would be useful to control how large an entry may be stored.

1 0

(ITS#8006) Inconsistent autogroup results
by hyc＠openldap.org 15 Dec '14

15 Dec '14

Full_Name: Howard Chu Version: 2.4.39 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc It looks like autogroup runs all its internal modifications using the same identity as the original op that triggered it. It should be using the rootDN, since the original user may not have permissions to search or modify all of the affected entries.

1 0

Re: (ITS#8005) crash when multiple olcDbURI are defined for chaining
by hyc＠symas.com 15 Dec '14

15 Dec '14

khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: > On 12/15/2014 12:09 PM, Howard Chu wrote: >> khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: >>> Full_Name: K. Ebrahimpour >>> Version: RE24 (commit dbc6741750de79b852ec9f728abb8b1425b6f03f) >>> OS: Ubuntu 14.04.1 >>> URL: https://gist.github.com/khosrow/cc6640cad9275a2cd041 >>> Submission from: (NULL) (205.211.133.128) >> >>> Finally, I'm running OpenLDAP 2.4.31 on Ubuntu Trusty, but was also >>> able to >>> replicate this same error on OpenLDAP 2.4.28 on Ubuntu Precise. >> >> The current release is 2.4.40. For such old releases you should >> contact Ubuntu for support. >> > I may not have been clear enough on which versions I have tested. Please > see the *VERSION* field in the ITS submission form for the correct version. > > To clarify, I have tested and reproduced the bug on the following versions: > > * 2.4.28 on Ubuntu 12.04 (official Ubuntu package) > * 2.4.31 on Ubuntu 14.04 (official Ubuntu package) > * RE24 commit #dbc6741750de79b852ec9f728abb8b1425b6f03f on Ubuntu 14.04 > (from OpenLDAP git repo) > > I understand the two first instances are old releases, I simply tested > the bug on progressively newer versions of the software. Are you saying > that the third tested version is also old? That commit ID is a few months old, from before 2.4.40 was released. We are currently preparing to release 2.4.41, so yes, it's old. -- -- 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#8005) crash when multiple olcDbURI are defined for chaining
by quanah＠zimbra.com 15 Dec '14

15 Dec '14

--On Monday, December 15, 2014 6:07 PM +0000 khosrow.ebrahimpour(a)ssc-spc.gc.ca wrote: > * RE24 commit #dbc6741750de79b852ec9f728abb8b1425b6f03f on Ubuntu 14.04 > (from OpenLDAP git repo) That commit is from last September, and predates the 2.4.40 release. Again, please test against current RE24. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs