On Tue, 2007-04-03 at 11:44 -0600, Richard Megginson wrote:
Andrew Bartlett wrote:
> I've got my bitwise match plugin to load and run, but now I have an
> issue. it appears that my matching rule needs to limit what attributes
> it applies itself to.
>
> That is, when I step though to code, from this query:
>
> [abartlet@piglett source]$ bin/ldbsearch -H
> ldapi:///data/samba/samba4/svn/source/st/dc/ldap/ldapi -b
> "dc=samba,dc=example,dc=com" -s sub
>
'(|(&(!(groupType:1.2.840.113556.1.4.803:=1))(groupType:1.2.840.113556.1.4.803:=2147483648)(groupType:1.2.840.113556.1.4.804:=10)))'
sAMAccountName groupType
> # returned 0 records
>
> I seem to be walking all the attributes, not just the attributes in the
> search expression:
>
> 75 errno = 0;
> 76 a = strtoull((*vals)->bv_val, NULL, 10);
> 77 if (errno == ERANGE) {
> 78 ber_bvecfree( vals );
> 79 vals = NULL;
> 80 continue;
> 81 }
>
> (gdb) p (*vals)->bv_val
> $5 = 0x8411038 "(targetattr = \"*\") (version 3.0;acl \"full
access to
> all by all\";allow (all)(userdn = \"ldap:///anyone\");)\n"
>
> The collation plugin is again to opaque for me to quite get how I'm
> meant to handle this...
>
Well, if it makes you feel any better, after looking at the mr server
code, I don't understand it either :-)
:-)
This is what's really puzzling - the interface for the mr match
function
is this:
typedef int (*mrFilterMatchFn) (void* filter, Slapi_Entry*, Slapi_Attr*
vals);
void *filter is a mr plugin private object (set with slapi_pblock_set
(pb, SLAPI_PLUGIN_OBJECT, (void *)obj))
entry is the entry to be tested to see if this entry matches the
extensible search filter. You would assume attr is the attribute from
the search filter - but you would be wrong. Attr is really just
e->e_attrs - the attribute list from entry, beginning with the first
attribute in the list. The attribute type in question is not passed in
either, which means the mr match function must somehow know which
attribute type to look for. The collation plugin handles this by using
or_filter_t as the obj - one of the fields is or_type, the attribute
type. It also doesn't pass in the value from the filter ava, so the
match fn has to keep track of that also.
So it looks like the workaround is to do something similar in the
bitwise code - create a structure to use for the match function
callback. It looks like the type and value don't have to be a copy -
they are pointers into the pblock of the search operation which has a
lifetime of well after the match fn is used. The new code is attached.
It looks like the better solution would be to change the code in
test_extensible_filter() to pass in the type and value into the match
function - it seems stupid for the plugin to have to keep track of that,
but perhaps I'm missing something.
Yeah, i think the current interface sucks. But it's great to have this
working, and we now pass that portion of our tests.
So, the next blocker is needing something I can use for USN support.
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team
http://samba.org
Samba Developer, Red Hat Inc.
http://redhat.com