[Date Prev][Date Next]
Re: (ITS#8163) Broken handling of deprecated attributes
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#8163) Broken handling of deprecated attributes
- From: firstname.lastname@example.org
- Date: Wed, 03 Jun 2015 13:52:50 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
> This is a cryptographically signed message in MIME format.
> 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
> You'll find the log extract from the server here:
> The first one is the query of the uid attribute which exists and returns
> 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=
>>> 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=
>>>> make it impossible to get into a situation where error 65 is returned=
>>>> a query, as it likely does not conform to the RFC."
>>> Again: This statement is right and AFACIS OpenLDAP always worked corre=
>> OK, so you confirm that what we see here is an incorrect behavior.
>>>> Here is the log extract you're asking for (I just filtered out the
>>>> base DN):
>>>> Jun 3 09:17:30 rose-java slapd: conn=3D1516 op=3D1 SRCH base=3D=
>>>> scope=3D2 deref=3D0 filter=3D"(&(objectClass=3DinetOrgPerson)(uid=3Dh=
> eis spiter))"
>>>> Jun 3 09:17:30 rose-java slapd: conn=3D1516 op=3D1 SRCH
>>>> Jun 3 09:17:30 rose-java slapd: conn=3D1516 op=3D1 SEARCH RESU=
>>>> tag=3D101 err=3D65 nentries=3D0 text=3D
>>> Up to now there's absolutely no evidence in the information you provid=
>>> that this is a bug.
>>> How did you make sure that an entry should be returned for exactly thi=
>>> search with the bound identity and your configuration?
>>> I suspect a configuration or data error on your side. Many things can =
>>> Without seeing your config, data and the bound identity nobody can
>>> track this down for you.
>> 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.
>> 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).
> Pierre Schweitzer <email@example.com>
> 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/