[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: one-level search error? (ITS#1654)
wpeters@abz.nl wrote:
>
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
>
> ------_=_NextPart_001_01C1D4AF.B9FF82E0
> Content-Type: text/plain
>
> It's good to hear that v.2.1 will have tackled this problem, but can you say
> anything at this moment about when this version is due to come out?
>
> Also, are you willing to provide us with the information about which
> source-file contains the error? One of our programmers has offered to have a
> look himself to fix it in the 2.0.x version.
>
> Thank you.
> Wim Peters.
>
> > -----Oorspronkelijk bericht-----
> > Van: Pierangelo Masarati [SMTP:openldap-its@OpenLDAP.org]
> > Verzonden: maandag 25 maart 2002 9:57
> > Aan: wpeters@abz.nl
> > Onderwerp: Re: one-level search error? (ITS#1654)
> >
> > The problem has been definitely overcome in 2.1 (or HEAD) code, where
> > the DN normalization has been completely rewritten. The four backslashes
> > in the DN, which correspond to two escaped backslashes (e.g.
> >
> > dn: ou=\\\\
> >
> > implies
> >
> > ou: \\
> >
> > ) are incorrectly translated into three backslashes, so your base dn
> > doesn't result in any match. I'll see if it's worth fixing it before
> > 2.1 is released.
>
> ------_=_NextPart_001_01C1D4AF.B9FF82E0
> Content-Type: text/html
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> RE: one-level search error? (ITS#1654)
>
> It's good to hear = that v.2.1 will have tackled this problem, but can you say anything at = this moment about when this version is due to come out?
>
> Also, are you = willing to provide us with the information about which source-file = contains the error? One of our programmers has offered to have a look = himself to fix it in the 2.0.x version.
Sure. I have one quick fix: in servers/slapd/back-ldbm/search.c:286
(REL_ENG_2, at least) there's a call to (void) dn_normalize( dn );
it should be replaced with some code eating initial white space, if
any, say:
/* check scope */
if ( !scopeok && scope == LDAP_SCOPE_ONELEVEL )
{
if ( (dn = dn_parent( be, e->e_ndn )) !=
NULL ) {
- (void) dn_normalize( dn );
- scopeok = (dn == realbase)
- ? 1
- : (strcmp( dn, realbase
) ? 0 : 1 );
+ if ( dn == realbase ) {
+ scopeok = 1;
+ } else {
+ char *newdn = dn;
+ while ( isspace( newdn[ 0 ] ) ) newdn++;
+ scopeok = ( strcmp( newdn, realbase ) ? 0 : 1 );
+ }
free( dn );
but this is totally untested. The flaw is somewhere in the logic
of the dn normalization, which has been completely reworked in 2.1
(see 2.1 alpha or HEAD code); normalizing more than once a dn in
string representation that contains sequences of backslashes (e.g.
your '\\\\') results in incremental backslash elimination (e.g.
'\\\\' => '\\' => '\'). I don't think it worth trying to fix 2.0
code at this level.
Pierangelo.
--
Dr. Pierangelo Masarati | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale | fax: +39 02 2399 8334
Politecnico di Milano |
mailto:pierangelo.masarati@polimi.it
via La Masa 34, 20156 Milano, Italy |
http://www.aero.polimi.it/~masarati