Re: (ITS#8163) Broken handling of deprecated attributes

[hyc@symas.com]

pierre@reactos.org 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 <pierre@reactos.org>
> 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/