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

[Andrew Bartlett]

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

My plugin in attached.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com

[Rich 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@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.

[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@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