[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#3406) MRA filter evaluation needs normalization of tested value?



Full_Name: Pierangelo Masarati
Version: HEAD/re22
OS: Linux (irrelevant)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.72.89.40)


In test_mra_filter(), when the requested mrule differs from that of the
attribute (if any), the a_vals are used instead of the a_nvals, as expected:

                       /* If ma_rule is not the same as the attribute's
                        * normal rule, then we can't use the a_nvals.
                        */
                       if (mra->ma_rule == a->a_desc->ad_type->sat_equality) {
                               bv = a->a_nvals;
                       } else {
                               bv = a->a_vals;
                       }

but then, I'd expect both the value and the assertion be normalized according to
the requested mrule, while this doesn't currently happen.

A working example: I'm trying to filter the monitor database entries based on
the "namingContexts" attribute.  This attribute has no equality rule, but its
value is distinguishedName, so I'd expect
"(namingContexts:distinguishedNameMatch:=<naming context>)" to work, but
inspecting the subsequent call of "dnMatch" with gdb shows that the
__NORMALIZED__ asserted value is compared with the __AS_IS__ value

dnMatch (matchp=0x412e36e8, flags=0, syntax=0x837baa0, mr=0x837e490,
   value=0x83d6cc8, assertedValue=0x412e5378) at dn.c:941
941             struct berval *asserted = (struct berval *) assertedValue;
(gdb) p value[0]
$9 = {bv_len = 14, bv_val = 0x83d5e10 "o=Example,c=US"}
(gdb) p asserted[0]
$10 = {bv_len = 14, bv_val = 0x412e534c "o=example,c=us"}

which obviously fails, while it works as expected if the namingContexts value
happens to be lowercase.

p.