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, 11 insertions, 1 deletions

diff --git a/ldap/servers/slapd/slapi-plugin.h b/ldap/servers/slapd/slapi-plugin.h
index 30f581b6..b6b350d1 100644
--- a/ldap/servers/slapd/slapi-plugin.h
+++ b/ldap/servers/slapd/slapi-plugin.h
@@ -140,7 +140,6 @@ typedef struct slapi_attr		Slapi_Attr;
 typedef struct slapi_value  		Slapi_Value;
 typedef struct slapi_value_set  	Slapi_ValueSet;
 typedef struct slapi_filter		Slapi_Filter;
-typedef struct slapi_matchingRuleEntry	Slapi_MatchingRuleEntry;
 typedef struct backend			Slapi_Backend;
 typedef struct _guid_t			Slapi_UniqueID;
 typedef struct op			Slapi_Operation;
@@ -645,6 +644,16 @@ int slapi_berval_cmp(const struct berval* L, const struct berval* R);
 #define SLAPI_BERVAL_EQ(L,R) ((L)->bv_len == (R)->bv_len && \
         ! memcmp ((L)->bv_val, (R)->bv_val, (L)->bv_len))
 
+typedef struct slapi_matchingRuleEntry {
+    char *mr_oid;
+    char *mr_oidalias;
+    char *mr_name;
+    char *mr_desc;
+    char *mr_syntax;
+    int mr_obsolete;
+} slapi_matchingRuleEntry;
+typedef struct slapi_matchingRuleEntry	Slapi_MatchingRuleEntry;
+
 Slapi_MatchingRuleEntry *slapi_matchingrule_new(void);
 void slapi_matchingrule_free(Slapi_MatchingRuleEntry **mrEntry,
                              int freeMembers);
@@ -652,6 +661,7 @@ int slapi_matchingrule_get(Slapi_MatchingRuleEntry *mr, int arg, void *value);
 int slapi_matchingrule_set(Slapi_MatchingRuleEntry *mr, int arg, void *value);
 int slapi_matchingrule_register(Slapi_MatchingRuleEntry *mrEntry);
 int slapi_matchingrule_unregister(char *oid);
+int slapi_matchingrule_is_ordering(const char *oid_or_name, const char *syntax_oid);
 
 /*
  * access control