#48745 Matching Rule caseExactIA5Match indexes incorrectly values with upper cases
Closed: wontfix None Opened 8 years ago by tbordaz.

The test case is:
Create an entry like:

        dn: uid=new_account1,dc=example,dc=com
        cn: new_account1
        gidNumber: 222
        homeDirectory: /home/mYhOmEdIrEcToRy <<< this the the value with upper cases
        objectClass: top
        objectClass: posixAccount
        uid: new_account1
        uidNumber: 111

Index 'homedirectroy' with caseExactIA5Match/caseIgnoreIA5Match Matching Rule

It will create the index keys like:

        :caseExactIA5Match:/home/myhomedirectory  (note the index key contains a lower case tag)
        :caseIgnoreIA5Match:/home/myhomedirectory
        =/home/mYhOmEdIrEcToRy

The the entry can not be retrieved with:

ldapsearch -LLL -D "cn=directory manager" -w password -b "uid=new_account1,dc=example,dc=com" "(homeDirectory=/home/mYhOmEdIrEcToRy)"
ldapsearch -LLL -D "cn=directory manager" -w password -b "dc=example,dc=com" "(homeDirectory:caseIgnoreIA5Match:=/home/mYhOmEdIrEcToRy)"
ldapsearch -LLL -D "cn=directory manager" -w password -b "dc=example,dc=com" "(homeDirectory:caseIgnoreIA5Match:=/home/MYhomeDIRECTORY)"

but not with

ldapsearch -LLL -D "cn=directory manager" -w password -b "dc=example,dc=com" "(homeDirectory:caseExactIA5Match:=/home/mYhOmEdIrEcToRy)"

With caseExactIA5Match MR in the filter, the search is indexed.
But the 'filter:"(homeDirectory:caseExactIA5Match:=/home/mYhOmEdIrEcToRy)"' does not exist in the index (it is stored as ':caseExactIA5Match:/home/myhomedirectory'
With the 'filter:"(homeDirectory:caseExactIA5Match:=/home/myhomedirectory)"' the key exists in the index (candidate_list=1), but then does not match the filter evaluation when returning the entry.

Note a base search returns the entry:

ldapsearch -LLL -D "cn=directory manager" -w password -s base -b "uid=new_account1,dc=example,dc=com" "(homeDirectory:caseExactIA5Match:=/home/mYhOmEdIrEcToRy)"

CI testcase to be attached


This bug has a different symptom as ​https://fedorahosted.org/389/ticket/48746 but the fix, involving the same part of code, was fixed in ​https://fedorahosted.org/389/ticket/48746#comment:6.

The test case of both bugs is different, but the test case for 48745 was also committed with 48746.

This bug is closed as duplicate of 48746

The bug fix https://fedorahosted.org/389/ticket/48746 introduced a regression that is fixed with
https://fedorahosted.org/389/ticket/48844.

The fix of 48844 does not fix 48745, so I am reopening it.

ds/dirsrvtests/tests/tickets/ticket48362_test.py:273: SyntaxWarning: name 'installation1_prefix' is assigned to before global declaration
global installation1_prefix

Some thing like this should fix it:

{{{
--- a/dirsrvtests/tests/tickets/ticket48362_test.py
+++ b/dirsrvtests/tests/tickets/ticket48362_test.py
@@ -14,9 +14,6 @@ from lib389.utils import *
logging.getLogger(name).setLevel(logging.DEBUG)
log = logging.getLogger(name)

-installation1_prefix = None

-
PEOPLE_OU='people'
PEOPLE_DN = "ou=%s,%s" % (PEOPLE_OU, SUFFIX)
MAX_ACCOUNTS=5
@@ -36,14 +33,9 @@ class TopologyReplication(object):

@pytest.fixture(scope="module")
def topology(request):
- global installation1_prefix
- if installation1_prefix:
- args_instance[SER_DEPLOYED_DIR] = installation1_prefix

 # Creating master 1...
 master1 = DirSrv(verbose=False)
  • if installation1_prefix:
  • args_instance[SER_DEPLOYED_DIR] = installation1_prefix
    args_instance[SER_HOST] = HOST_MASTER_1
    args_instance[SER_PORT] = PORT_MASTER_1
    args_instance[SER_SERVERID_PROP] = SERVERID_MASTER_1
    @@ -59,8 +51,6 @@ def topology(request):

    # Creating master 2...
    master2 = DirSrv(verbose=False)
    - if installation1_prefix:
    - args_instance[SER_DEPLOYED_DIR] = installation1_prefix
    args_instance[SER_HOST] = HOST_MASTER_2
    args_instance[SER_PORT] = PORT_MASTER_2
    args_instance[SER_SERVERID_PROP] = SERVERID_MASTER_2

}}}

Otherwise, looks good, the tests pass for me, and it builds correctly, so I'm happy to ack this.

Thanks William for the review. I did update ticket48632_test.py.

'''git push origin master'''
Counting objects: 11, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (11/11), 1.71 KiB | 0 bytes/s, done.
Total 11 (delta 9), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
7ebc170..d975431 master -> master

commit d975431
Author: Thierry Bordaz tbordaz@redhat.com
Date: Fri May 20 11:49:29 2016 +0200

Description: Fixing a minor coverity defect introduced by #48745.

Defect type: REVERSE_INULL
plugin_mr.c:671: check_after_deref: Null-checking "pi" suggests that
it may be null, but it has already been dereferenced on all paths
leading to the check.
Moving the NULL check back to the original position.

Pushed to master:
43d5ac6..a0b8f46 master -> master
commit a0b8f46

Thierry, the milestone is 1.3.4.9. Do you think this fix is needed for F23? If not, can we reset it to 1.3.5.x? Thanks!

Hi Noriko,

Several fixes were done in MR plugin code.
All these fixes rely on https://fedorahosted.org/389/ticket/48270
These fixes were:
https://fedorahosted.org/389/ticket/48497
https://fedorahosted.org/389/ticket/48745
https://fedorahosted.org/389/ticket/48746
https://fedorahosted.org/389/ticket/48844

48270 is fixed in 1.3.5.1. So I agree that the milestone for this ticket should be > 1.3.5.1
Also I think that the milestone for 48497, 48745, 48746 should also be > 1.3.5.1, right ?

{{{
git log --oneline | egrep 'bump|48270|48497|48745|48746|48844'
f4cfadb bump version to 1.3.5.5
d975431 Ticket 48745 Matching Rule caseExactIA5Match indexes incorrectly values with upper cases
7ebc170 Ticket 48844 Regression introduced in matching rules by DS 48746
962116b bump version to 1.3.5.4
6575db8 Ticket 48497 - uncomment pytest from CI test
0e4b061 bump version to 1.3.5.3
83d57ee bump version to 1.3.5.2
83f3f44 bump version to 1.3.5.1
dde5b62 Ticket 48746: Crash when indexing an attribute with a matching rule
b9dd886 Ticket 48497 test case
f230d32 ticket: 48497 extended search without MR indexed attribute prevents later indexing with that MR
e033d4b Ticket 48270: test case
3752886 Ticket 48270: fail to index an attribute with a specific matching rule

}}}

Thanks for the clarification, Thierry. I'm happy about 1.3.5.x. My question is actually on 1.3.4.x. I wanted to make sure if you want to have this 48745 fix in 1.3.4.x branch or not.

I ran the same grep on the 389-ds-base-1.3.4 branch. Then I found 48497 and 48746. Do you think freeipa needs to have other fixes 48270, 48745 and 48844 in 389-ds-base-1.3.4.12? Please note that 1.3.4 is running on F23.
Thanks!
{{{
$ git log --oneline | egrep 'bump|48270|48497|48745|48746|48844'
7715ac1 bump version to 1.3.4.11
5233e61 bump version to 1.3.4.10
c6ebe12 Ticket 48497 - uncomment pytest from CI test
718bcf2 bump version to 1.3.4.9
cba64d1 Ticket 48746: Crash when indexing an attribute with a matching rule
70670f2 ticket: 48497 extended search without MR indexed attribute prevents later indexing with that MR
}}}

Looking at 1.3.4:

Metadata Update from @tbordaz:
- Issue assigned to tbordaz
- Issue set to the milestone: 1.3.4.9

7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1805

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata