uniqueMember attribute compare does not seem to work properly (uniqueMemberMatch is not implemented?)

• Key: DIRSERVER-766
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Emmanuel Lecharny
• Reporter: Kirill Kovalenko
• Affects Version/s: 1.5.0
• Fix Version/s: 1.5.1

Description

When it comes to search attributes with syntax 1.3.6.1.4.1.1466.115.121.1.34, like uniqueMember, the server does not seem to work properly. For example, in my environment, the (uniqueMember=uid=kvaughan,ou=People,dc=example,dc=com) search filter brings the search result while (uniqueMember=uid=kvaughan, ou=People, dc=example, dc=com) does not. The only difference here is spaces between RDN components in the search filter value. Server should normalize uniqueMember values before compare takes place.

Comments

[Emmanuel Lecharny]

Have you escaped the '=' char in the filter ?

[Emmanuel Lecharny]

Is this still an issue? May we have an LDIF file which can be imported and a scenario to reproduce the problem, or is this just a syntax problem with the not escaped '=' ?

Will wait one more week to have further information, then we may close the issue...

[Kirill Kovalenko]

No. it's not a problem with escaping. We used standard example.ldif file from Netscape DS 6.01 installation. The problem, I believe, is with the the comparer used by the server.

[Kirill Kovalenko]

This is a slightly modified standard example file that comes with Netscape DS. It can be imported to Apache DS to reproduce the issue.

[Emmanuel Lecharny]

Thanks for the ldif attachment.

I confirm that it is a bug in the server. It seems that the comparizon using DistinguishedNameMatch does not follow the chapter 4.2.14 of RFC 4517, but is using a simple string comparizon, which obviously falis if some extra spaces are seen in one of the DN.

Comparizon of such attributes should be done by a comparizon of the number of RDN, the position of RDNs in the DN, and at the end, by comparing the values.

I will debug the server to figure out a fix for this issue, which is quite serious.

After a further investigation, here what I found :
- We are not checking the syntax of attributes. Here, uniqueMember attribute type is NameAndOptionalUid, which does not exist in ADS (we are currently adding them in 1.5)
- As we don't check those syntax, we don't know that they are DN and should be transformed with respect to DN representation (RFC 4514)
- thus, we compare them as string, not as DN
- and as a DN is composed of multiple attributes, whith each one having its own syntax, this lead us to have big problem finding entries with a uniqueMember not having the same value than the one which as created.

In one world : Damn !

[Emmanuel Lecharny]

Postponned to 1.5 : we need a strong schema checking system we don't have in 1.0 to solve it

[Alex Karasulu]

Emmanuel did'nt you add a matching rule for this? I thought you fixed this issue a while back with all those new normalizers, comparators, and syntaxCheckers. Let me know if not.

[Emmanuel Lecharny]

Postponed to 1.5.1

[Emmanuel Lecharny]

Fixed ! And also fixed a bug in the associated SyntaxChecker.

http://svn.apache.org/viewvc?rev=569405&view=rev
http://svn.apache.org/viewvc?rev=569435&view=rev
http://svn.apache.org/viewvc?rev=569436&view=rev
http://svn.apache.org/viewvc?rev=569437&view=rev
http://svn.apache.org/viewvc?rev=569565&view=rev
http://svn.apache.org/viewvc?rev=569569&view=rev
http://svn.apache.org/viewvc?rev=569570&view=rev
http://svn.apache.org/viewvc?rev=569579&view=rev
http://svn.apache.org/viewvc?rev=569580&view=rev

[Emmanuel Lecharny]

closed