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.