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

[Andrew Bartlett]

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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/389-devel/attachments/20070404/104e60aa/attachment.bin