Full_Name: Rene Snajder Version: 2.4.30 OS: RHEL 6 URL: ftp://ftp.openldap.org/incoming/openldap-upper-strcast.patch Submission from: (NULL) (193.171.77.1)

I reported (from my other e-mail address dermaniac@gmail.com) a bug report in January. I reported it to the technical mailing list first: http://www.openldap.org/lists/openldap-technical/201201/msg00233.html which I got no reply on. I then posted a ticket here: http://www.openldap.org/its/index.cgi/Incoming?id=7130;page=12 which I got one reply but it didn't fix my problem (and I didn't get further replies).

I then took matters in my own hand and found 3 bugs in back-sql which lead to errors when UPPER is applied to integer values.

Since there was no reaction here I tried to report it to Redhat (since I'm using RHEL) where the issue finally got some attention. I created a bugfix and they advised me to submit it directly to openldap, so now I'm trying it here again.

Strangely, the same day that redhat responded to my patch I got a reply here: http://www.openldap.org/lists/openldap-technical/201204/msg00108.html to which I cannot seem to answer (my mails to the mailing list never seem to make it through).

Here are the bugs that I found:

1) It is not checked whether the UPPER function can be applied on a type in the database. Comments in the code itself confirm that this is "currently broken". (see my previous 2 comments)

2) One would assume that the parameter "upper_needs_cast yes" in the slapd.conf would add a string casting statement to every UPPER statement in the SQL queries. In fact, it only does so for one single query (when it queries for "ldap_entries.dn"). All other queries where UPPER is applied still don't use a cast, even though I declare "upper_needs_cast yes" in the main config file.

3) The slapd.conf file lets me declare a "strcast_func" which is the name of the function for a cast to string. This strcast_func is used at some points in the queries, but not consistently. For the one query that actually pays any attention to the "upper_needs_cast" parameter (which i mentioned before) a hardcoded string cast function is used instead. This function is always "(cast ? as varchar(255))".

Now these are 3 separate problems in the back-sql code. To fix my particular problem I took a closer look at problem number 2. I attached an patch which can be applied to the version in the GIT repository. When this patch is applied, the hardcoded strcast function from problem number 3 is at least applied to every use of the UPPER function (or at least everywhere where the upper function is applied properly!), effectively fixing problem number 2.

This may THEORETICALLY lead to the following problem: IF someone set "upper_needs_cast yes" in their config, with a database backend that does not support the hardcoded strcast function, this patch would break the SQL queries for this user. BUT, in that case using the "upper_needs_cast yes" statement would have been useless - or even causing problems - before this patch anyways - since it was always using the hardcoded function and only at one single point.

My patch is here: ftp://ftp.openldap.org/incoming/openldap-upper-strcast.patch

For a more detailed description see my bug report in the Redhat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=809105