incorrect dn index when spaces between parts in dn (ITS#189)

[patrick.timmons@courriel.polymtl.ca]

Full_Name: Patrick Timmons
Version: 1.2.1
OS: AIX 4.2
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (132.207.22.40)


DN that contains spaces between parts are not entered correctly in the dn index
for
ldbm databases. For example, 'dn: cn=Patrick Timmons,ou=personnel,o=polymtl.ca'
will
be entered correctly but 'dn: cn=Patrick timmons, ou=personnel, o=polymtl.ca'
will
not.

A search like 'ldapsearch -b "ou=personnel,o=polymtl.ca" "uid=*" dn uid' will
not find
anything when in fact it should return all records in the ou=personnel branch.

This is caused by an error in the calculation of the lenght of the value to
enter in the dn index when there is/are space/s between parts.

In file servers/slapd/back-ldbm/index.c subroutine index_add_values(), the
lenght of
the value to index is computed before the call to subroutine value_normalize().

If the normalization process removes spaces from the value, the length will
change. 
Since the lenght is not recomputed after the call to value_normalize(), values 
with spaces between items will not be entered in the index file correctly.

Example:
dn: cn=Patrick Timmons, ou=personnel, o=polymtl.ca
with a lenght of 46 characters for cn=Patr ... polymtl.ca
will be normalized to:
dn:cn=PATRICK TIMMONS,ou=PERSONNEL,o=POLYMTL.CA
which is 2 characters less than unnormalized.


The code to create the substring index looks like this:

   create entry for '*'+'^'+<first two characters>   // string must start with
'cn'
   create entry for '*'+<last two characters>+'$'    // string must end with
'CA'
   for each 3 letter substrings
      create entry for '*'+substring

The <last two characters>'s position is obtained from the lenght computed before

normalization: p = val + len - SUBLEN + 1;

In the case of the previous example it gives:

   p = Address_of_var_val + 46 - 3 + 1    ==  Address_of_var_val + 44

which is good because we need val[44]+val[45]+'$'
but after normalization, the value has only 44 characters ([0..43],
val[44]=='\0')
and subroutine add_value() will be asked to create an index value for 
'*'+'\0'+?+'$'+'\0' instead of '*'+'C'+'A'+'$'+'\0'.

If you change the code to recompute the lenght after the call to
value_normalize(),
the index is created correctly.

I uploaded a patch to ftp.openldap.org as patrick-timmons-990601.patch

PT.