Bug 1290600 - The 'eq' index does not get updated properly when deleting and re-adding attributes in the same ldapmodify operation
The 'eq' index does not get updated properly when deleting and re-adding attr...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
7.0
Unspecified Unspecified
urgent Severity urgent
: rc
: ---
Assigned To: Noriko Hosoi
Viktor Ashirov
Petr Bokoc
: ZStream
Depends On:
Blocks: 1290726
  Show dependency treegraph
 
Reported: 2015-12-10 18:11 EST by Noriko Hosoi
Modified: 2016-11-03 16:38 EDT (History)
6 users (show)

See Also:
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 16:38:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Noriko Hosoi 2015-12-10 18:11:27 EST
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@dev.null
   mail: alias@dev.null
   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@dev.null
   mail: alias@dev.null
   -
   add: mail
   mail: user0099@dev.null
   EOF
   ;;

4. Search for entries that have 'mail=alias@dev.null' (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@dev.null 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@dev.null' has been deleted:
# ldapsearch -LLL -x -h localhost -D 'cn=Directory Manager' -w <password> -b
"dc=example,dc=com" mail=alias@dev.null 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@dev.null



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@dev.null
=user0099@dev.null

The 'sub' index as part of the mail index does seems to be updated properly.
Comment 3 Mike McCune 2016-03-28 19:13:32 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 5 Simon Pichugin 2016-06-14 09:36:26 EDT
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@dev.null
mail: alias@dev.null
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@dev.null
mail: alias@dev.null
-
add: mail
mail: user0099@dev.null

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

4. Search for entries that have 'mail=alias@dev.null' (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@dev.null 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@dev.null

Marking as verified.
Comment 7 errata-xmlrpc 2016-11-03 16:38:28 EDT
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

Note You need to log in before you can comment on or make changes to this bug.