[Fedora-directory-devel] slapi extednded match plugin: How to limit attribute's to match on?

[Richard Megginson]

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 at 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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: bitwise.c
Type: text/x-csrc
Size: 7052 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/389-devel/attachments/20070403/4ffbf686/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/389-devel/attachments/20070403/4ffbf686/attachment-0001.bin