peter.gietz@daasi.de wrote:

This bug report was given to me at the OpenLDAP booth on the Systems in Munich.

SQL search-statements are wrong because of a strange OR condition: "(2=2 OR (ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entry_objclasses.oc_name='"

So instead of a subset, all data are included in the response.

It is not a bug, but rather an easy means to indicate that the whole data should be returned to the frontend in order to filter it the LDAP way, since sub-classing might be involved. If that user doesn't want searches for (objectClass=person) to return objects with objectClass=inetOrgPerson, then he shouldn't be using LDAP.

Thats what the guy, who was too lazy to make the bug report himself told me. He also told me that he patched his code (by deleting the condition (2=2) and is happy for now.

Well, you see: open source software makes people happy.

As a side note, usually, well-designed RDBMSes understand that 2=2 is always true and do not proceed any further in evaluating other clauses in the OR. For those RDBMSes this causes a performance degradation (and, I insist, it would be the RDBMS' fault) the only **improvement** to OpenLDAP's back-sql (no bug) could consist in detecting that condition ourselves and omit that part of the WHERE clause entirely. But this would probably require to rewrite the filter translation layer, and it's not something I plan to do any soon (unless rewarded enough to distract me from other issues, I mean).

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------