I don't know if this is a false alarm or not, but anyway:
Sorted values, as with SLAP_ATTR_SORTED_VALS in attr_valfind(), needs an unambiguous ordering. However value_match() can return error, and does not say which of the compared values caused the error.
Are there sorted value examples where it can return error both because of the stored value and because of the assertion value? Or overlays like rwm which can cause this? If so the sort order of (normal value, value causing error) will depend on the order of arguments to the compare function.
Then if we manage to insert an "ambiguously-sorted" attribute value into the sorted list of values, then a binary search for an existing normal value can fail if it hits the naughty value as a pivot entry. Or it can cause a new value to be inserted at the wrong place.
Possibly there are also some other strange matching rules where the ordering is ambiguous, I don't know.
In any case, I think this whould mean that:
- value_match() and ordering-compare functions should try to define unambiguous orderings of (normal value, truble value). I think sorting of (trouble value 1, truble value 2) does not matter.
- maybe Sorted values should only be supported for attributes whose compare functions do define such an ordering.
However there are also inequality filters vs. sorted attribute values. This code in slapd/filterentry.c:test_ava_filter() is similarly broken if there is an error-generating value at either end of the array of values:
if (( a->a_flags & SLAP_ATTR_SORTED_VALS ) && type != LDAP_FILTER_APPROX ) { unsigned slot; int ret;
/* For Ordering matches, we just need to do one comparison with * either the first (least) or last (greatest) value. */ if ( use == SLAP_MR_ORDERING ) { const char *text; int match, which; which = (type == LDAP_FILTER_LE) ? 0 : a->a_numvals-1; ret = value_match( &match, a->a_desc, mr, use, &a->a_nvals[which], &ava->aa_value, &text ); if ( ret != LDAP_SUCCESS ) return ret;
For such a value, and with a normal assertion value, the function ought to search for the nearest non-error-generating value and compare with that.