Bug 1290600

Summary: The 'eq' index does not get updated properly when deleting and re-adding attributes in the same ldapmodify operation
Product: Red Hat Enterprise Linux 7 Reporter: Noriko Hosoi <nhosoi>
Component: 389-ds-baseAssignee: Noriko Hosoi <nhosoi>
Status: CLOSED ERRATA QA Contact: Viktor Ashirov <vashirov>
Severity: urgent Docs Contact: Petr Bokoc <pbokoc>
Priority: urgent    
Version: 7.0CC: jkurik, msauton, nkinder, pbokoc, rmeggins, spichugi
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 389-ds-base-1.3.5.2-1.el7 Doc Type: Bug Fix
Doc Text:
Deleting and adding the same LDAP attribute now correctly updates the equality index Previously, when several values of the same LDAP attribute were deleted using the "ldapmodify" command, and at least one of them was added again during the same operation, the equality index was not updated. As a consequence, an exact search for the re-added attribute value did not return that entry. The logic of the index code has been modified to update the index if at least one of the values in the entry changes, and the exact search for the re-added attribute value now returns the correct entry.
Story Points: ---
Clone Of:
: 1290726 (view as bug list) Environment:
Last Closed: 2016-11-03 20:38:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1290726    

Description Noriko Hosoi 2015-12-10 23:11:27 UTC
Description of problem:
Deleting an indexed multi value attribute and re-adding it with the same value
in the same ldapmodify operation does not update the 'pres' index properly.

Version-Release number of selected component (if applicable):
389-ds-base-1.2.11.15-65.el6_7.x86_64


How reproducible:
Always


Steps to Reproduce:
1. Setup a RHDS server (stand-alone)
2. Create a user:
   # ldapadd -x -h localhost -D 'cn=Directory Manager' -w <password> <<-EOF
   dn: uid=user0099,ou=People,dc=example,dc=com
   givenName: Test
   sn: User
   loginShell: /bin/bash
   uidNumber: 10099
   gidNumber: 10099
   objectClass: top
   objectClass: person
   objectClass: organizationalPerson
   objectClass: inetorgperson
   objectClass: posixAccount
   uid: user0099
   gecos: Test User
   mail: user0099
   mail: alias
   cn: Test User
   homeDirectory: /home/user0099
   EOF

3. Update the mail attribute by deleting all values and add only one value,
   that was previously used, in the same ldapmodify command:
   # ldapmodify -x -h localhost -D 'cn=Directory Manager' -w <password> <<-EOF
   dn: uid=user0099,ou=People,dc=local,dc=redhat,dc=com
   changetype: modify
   delete: mail
   mail: user0099
   mail: alias
   -
   add: mail
   mail: user0099
   EOF
   ;;

4. Search for entries that have 'mail=alias' (i.e. the value that was
   deleted):
   # ldapsearch -LLL -x -h localhost -D 'cn=Directory Manager' -w <password> -b
"dc=example,dc=com" mail=alias cn

5. Check the entry as returned by 4:
   # ldapsearch -LLL -x -h localhost -D 'cn=Directory Manager' -w <password> -b
"dc=example,dc=com" uid=user009 mail



Actual results:
The search in 4. returns the user009 object while the mail attribute for
'alias' has been deleted:
# ldapsearch -LLL -x -h localhost -D 'cn=Directory Manager' -w <password> -b
"dc=example,dc=com" mail=alias cn
dn: uid=user0099,ou=People,dc=local,dc=redhat,dc=com
cn: Test User

The search in 5. shows this object does not contain the deleted mail
attribute:
# ldapsearch -LLL -x -h localhost -D 'cn=Directory Manager' -w <password> -b
"dc=example,dc=com" uid=user009 mail
dn: uid=user0099,ou=People,dc=local,dc=redhat,dc=com
mail: user0099



Expected results:
The search in 4. not to return the user009 object.


Additional info:
A dbscan of the mail index db shows both values (even after the db cache is
flushed):
# dbscan -f /var/lib/dirsrv/slapd-<instance>/db/userRoot/mail.db4 | grep ^=
=alias
=user0099

The 'sub' index as part of the mail index does seems to be updated properly.

Comment 3 Mike McCune 2016-03-28 23:13:32 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 5 Simon Pichugin 2016-06-14 13:36:26 UTC
Build tested:
389-ds-base-1.3.5.4-1.el7.x86_64

Verification steps:
1. Install a directory server instance

2. Create a user:
[0 root@host ~]# ldapadd -x -h localhost -D 'cn=Directory Manager' -w Secret123
dn: uid=user0099,ou=People,dc=example,dc=com
givenName: Test
sn: User
loginShell: /bin/bash
uidNumber: 10099
gidNumber: 10099
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: posixAccount
uid: user0099
gecos: Test User
mail: user0099
mail: alias
cn: Test User
homeDirectory: /home/user0099

adding new entry "uid=user0099,ou=People,dc=example,dc=com"

3. Update the mail attribute by deleting all values and add only one value,
   that was previously used, in the same ldapmodify command:
[0 root@host ~]# ldapmodify -x -h localhost -D 'cn=Directory Manager' -w Secret123
dn: uid=user0099,ou=People,dc=example,dc=com
changetype: modify
delete: mail
mail: user0099
mail: alias
-
add: mail
mail: user0099

modifying entry "uid=user0099,ou=People,dc=example,dc=com"

4. Search for entries that have 'mail=alias' (i.e. the value that was
   deleted):
[0 root@host ~]# ldapsearch -LLL -x -h localhost -D 'cn=Directory Manager' -w Secret123 -b "dc=example,dc=com" mail=alias cn

Nothing found.

5. Check the entry
[0 root@host ~]# ldapsearch -LLL -x -h localhost -D 'cn=Directory Manager' -w Secret123 -b "dc=example,dc=com" uid=user0099 mail
dn: uid=user0099,ou=People,dc=example,dc=com
mail: user0099

Marking as verified.

Comment 7 errata-xmlrpc 2016-11-03 20:38:28 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2594.html