[email protected] wrote: > This is a cryptographically signed message in MIME format. > > --------------ms070202050304000100090907 > Content-Type: text/plain; charset=windows-1252 > Content-Transfer-Encoding: quoted-printable > > Finally, some more information thanks to the testing env. > > It seems that the SQL backend is indeed responsible for this and > apparently makes OpenLDAP no longer RFC-compliant.
back-sql currently has no maintainer and is not recommended for use. The primary database backends are back-bdb,hdb, and mdb. All of these are RFC-compliant. > You'll find the log extract from the server here: > https://www3.heisspiter.net/query_uid > https://www3.heisspiter.net/query_javaRemoteLocation > https://www3.heisspiter.net/query_javaCodeBase > > The first one is the query of the uid attribute which exists and returns > fine. > The second one is the query of the javaRemoteLocation attribute which > doesn't exist and thus, doesn't return fine. > The third one is the query of the javaCodeBase attribute which exists in > schema but that we don't use at all but returns fine. > > The guilty function *might* be backsql_get_attr_vals() which is the last > one called, raising the error. > > On 06/03/2015 01:47 PM, Pierre Schweitzer wrote: >> On 06/03/2015 11:47 AM, Michael Str=F6der wrote: >>> On 2015-06-03 11:20, Pierre Schweitzer wrote: >>>> This is not a question, but really a bug report about a broken behavi= > or. >>> >>> Again: >>> I can confirm that requesting an attribute which does not exist in the= > >>> subschema does not affect whether an entry is returned. >>> >>>> I quote them again: "Potentially, OpenLDAP should have a bug raised t= > o >>>> make it impossible to get into a situation where error 65 is returned= > on >>>> a query, as it likely does not conform to the RFC." >>> >>> Again: This statement is right and AFACIS OpenLDAP always worked corre= > ctly. >> =20 >> OK, so you confirm that what we see here is an incorrect behavior. >> =20 >>>> Here is the log extract you're asking for (I just filtered out the >>>> base DN): >>>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH base=3D= > "XXXX" >>>> scope=3D2 deref=3D0 filter=3D"(&(objectClass=3DinetOrgPerson)(uid=3Dh= > eis spiter))" >>>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH >>>> attr=3DjavaRemoteLocation >>>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SEARCH RESU= > LT >>>> tag=3D101 err=3D65 nentries=3D0 text=3D >>> >>> Up to now there's absolutely no evidence in the information you provid= > ed >>> that this is a bug. >>> >>> How did you make sure that an entry should be returned for exactly thi= > s >>> search with the bound identity and your configuration? >>> >>> I suspect a configuration or data error on your side. Many things can = > be >>> wrong. >>> Without seeing your config, data and the bound identity nobody can >>> track this down for you. >> =20 >> One technical information that would make sense: we are using the SQL >> backend. I've just checked, there's some attributes management in >> backend code, and the issue *may* come from this. >> The Atlassian support cannot reproduce the error with "out-of-the-box" >> OpenLDAP server not using SQL backend. >> =20 >> I will setup a dedicated test env for this issue so that I can more >> easily track & debug the issue. I'll come back at you when I've more >> information (or even a patch). >> =20 > > > --=20 > Pierre Schweitzer <[email protected]> > System & Network Administrator > Senior Kernel Developer > ReactOS Deutschland e.V. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
