[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#3406) MRA filter evaluation needs normalization of tested value?
I've uploaded my suggested patch to
ftp://ftp.openldap.org/incoming/test_mra_filter-2004-11-29.patch ,
please review. Analogous correction needs to be applied later on for
the case of no AttributeDescription specification in MRA filter.
I understand another solution to my specific problem would be to define
a new monitorNamingContext with appropriate equality rule; this is being
considered as well. Anyway I this this is an issue in current MRA
filter testing.
p.
ando@sys-net.it wrote:
>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.
>
>
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497