[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
test_mra_filter?
- To: openldap-devel@OpenLDAP.org
- Subject: test_mra_filter?
- From: Pierangelo Masarati <ando@sys-net.it>
- Date: Fri, 12 Nov 2004 10:22:29 +0100
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
In test_mra_filter, when the requested mrule differs from that of the
attribute, the a_vals are used instead of the a_nvals, of course:
/* 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 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.
Comments?
p.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497