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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-directory-devel mailing list Fedora-directory-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel