[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
(ITS#7248) Cast to string in back-sql when upper_needs_cast is declared in slapd.conf
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