Resolves: bug 249366

Bug Description: rhds71 - search filters returns too many entries on integer attributes value greater than 2 to the power of 31
Reviewed by: nkinder, nhosoi (Thanks!)
Fix Description: The way >= and <= searches are supposed to work in LDAP is that you are supposed to define an ORDERING matching rule for the attribute you want to use in the search filter.  The way our code is written, most strings "just work" as a side effect of the way bdb sorts the keys by default - so you can do (uid>=jvedder) and get what you would expect, even though LDAP says this is illegal because the schema definition of the uid attribute does not have an ORDERING matching rule.  And INTEGER worked with the old binary format for the same reason.  The only attribute definitions we use with ORDERING are attributes that use Generalized Time syntax (e.g. createTimestamp, et. al.) and numSubordinates (which uses INTEGER, but this is a special case handled internally by the db code).
The way it works now is that the indexing code will honor the ORDERING matching rule specified in the schema definition.  Or, if ORDERING is not specified, the user can use the nsMatchingRule index configuration.  This will allow an existing customer that depends all integer syntax attributes (e.g. uidNumber) to allow range searches by default to enable range searches without editing the schema.  The syntax definition for the attribute must also specify a compare function.  This compare function will be used by the bdb bt_compare() function.
I also fixed a bug in the integer normalize code - a string of all zeros should normalize to a single "0".  In all other cases, the leading zeros should be removed.
Platforms tested: RHEL5 x86_64
Flag Day: Yes.  Integer indexes will need to be rebuilt (except for numsubordinates).
Doc impact: Yes - document slapi API additions
QA impact: Pay close attention to tests that use >= or <= search filters, both with and without index attributes.  Also, pay close attention to greater/less than searches using i18n collations.
New Tests integrated into TET: Forthcoming

1 files changed, 22 insertions, 1 deletions

diff --git a/ldap/servers/slapd/match.c b/ldap/servers/slapd/match.c
index d66f3c10..f89103f4 100644
--- a/ldap/servers/slapd/match.c
+++ b/ldap/servers/slapd/match.c
@@ -270,5 +270,26 @@ int slapi_matchingrule_unregister(char *oid)
     return(0);
 }
 
+/*
+  See if a matching rule for this name or OID
+  is registered and is an ORDERING matching rule that applies
+  to the given syntax.
+*/
+int slapi_matchingrule_is_ordering(const char *oid_or_name, const char *syntax_oid)
+{
+    struct matchingRuleList *mrl=NULL;
+    for (mrl = g_get_global_mrl(); mrl != NULL; mrl = mrl->mrl_next) {
+        if (mrl->mr_entry->mr_name && !strcasecmp(oid_or_name, mrl->mr_entry->mr_name)) {
+            return (mrl->mr_entry->mr_name &&
+                    PL_strcasestr(mrl->mr_entry->mr_name, "ordering") &&
+                    !strcmp(mrl->mr_entry->mr_syntax, syntax_oid));
+        }
+        if (mrl->mr_entry->mr_oid && !strcmp(oid_or_name, mrl->mr_entry->mr_oid)) {
+            return (mrl->mr_entry->mr_name &&
+                    PL_strcasestr(mrl->mr_entry->mr_name, "ordering") &&
+                    !strcmp(mrl->mr_entry->mr_syntax, syntax_oid));
+        }
+    }
 
-
+    return 0;
+}