(ITS#7778) Index and derived attribute bug

[yann.cezard@univ-pau.fr]

Full_Name: Yann Cezard
Version: 2.4.38
OS: Debian GNU/Linux Wheezy / amd64
URL: ftp://ftp.openldap.org/incoming/Yann-Cezard-130109.tgz
Submission from: (NULL) (2001:660:6701:14:225:64ff:fe92:685b)


Hello,

I hit a bug with the latest version of OpenLDAP (2.4.38) that was not present,
at least in 2.4.17 (made a test on an older server that we were using before I
discovered this).
This happens on both lmdb and bdb backend (as we were using BDB before upgrading
to 2.4.38, I tested with both on 2.4.38 to ensure that the problem was not LMDB
related).

The problem shows up when you delete the last attribute of en entry, which is
derived from another attribute, which has an index on it (not easy to
explain...).
As an example (complete LDIF files - config/schema + data - provided on the
incoming FTP), considering an attribute that is derived from the 'mail'
attribute (which is defined in core.schema, and used in InetOrgPerson) :
attributetype ( 1.3.6.1.4.1.7135.1.2.1.34 NAME 'supannAutreMail'
        DESC 'adresses mail non institutionnelles'
        SUP mail )
and an associated objectClass that use it (called supannPerson in the next
example).
Now place an index on mail :
olcDbIndex: mail pres,eq,sub


Now with an entry like this :

dn: uid=test,ou=users,dc=example,dc=com
uid: test
sn: Test
cn: Test
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
objectClass: supannPerson
structuralObjectClass: inetOrgPerson
entryUUID: 2699b5b4-0d7c-1033-9546-613643720ad1
creatorsName: cn=root,dc=example,dc=com
createTimestamp: 20140109131736Z
mail: test@example.com
supannAutreMail: root@example.com
supannAutreMail: user.test@example.com


If you make a search with '(mail=*)', the entry matches :
#############
$ ldapsearch -x -h ldap-test -b ou=users,dc=example,dc=com -D
cn=root,dc=example,dc=com -w test -s one '(mail=*)' dn
# extended LDIF
#
# LDAPv3
# base <ou=users,dc=example,dc=com> with scope oneLevel
# filter: (mail=*)
# requesting: dn 
#

# test, users, example.com
dn: uid=test,ou=users,dc=example,dc=com

# search result
search: 2
result: 0 Success
##############

That's pretty normal.

Now, remove both the supannAutreMail attributes from the entry.
Run the same ldapsearch :
##############
$ ldapsearch -x -h ldap-test -b ou=users,dc=example,dc=com -D
cn=root,dc=example,dc=com -w test -s one '(mail=*)' dn
# extended LDIF
#
# LDAPv3
# base <ou=users,dc=example,dc=com> with scope oneLevel
# filter: (mail=*)
# requesting: dn 
#

# search result
search: 2
result: 0 Success

# numResponses: 1
##############

The entry doesn't match anymore...
But still it has a mail attribute :
##############
$ ldapsearch -x -h ldap-test -b ou=users,dc=example,dc=com -D
cn=root,dc=example,dc=com -w test -s one '(uid=test)' mail
# extended LDIF
#
# LDAPv3
# base <ou=users,dc=example,dc=com> with scope oneLevel
# filter: (uid=test)
# requesting: mail 
#

# test, users, example.com
dn: uid=test,ou=users,dc=example,dc=com
mail: test@example.com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
##############

The only ways to make the '(mail=*)' filter matches again the modified entry, is
to modify the mail attribute, or to run slapindex.
If you remove the index on the mail attribute, then there is no such problem.
It only happens when deleting all/the last derived attributes (supannAutreMail
here) from the entry.

Sounds to me like a bug, isn't it ?

Regards.