Very difficult search for gidNumber and others (ITS#3195)

[andreas@conectiva.com.br]

Full_Name: Andreas Hasenack
Version: 2.1.30
OS: GNU/Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (200.140.247.99)


Only equality-type searches work on the gidNumber attribute (and others as well,
this is just one example).

[root@pandora root]# ldapsearch -x -LLL gidNumber=10000 uid
dn: uid=testuser,ou=People,o=company,c=br
uid: testuser

[root@pandora root]# ldapsearch -x -LLL gidNumber=1000* uid
[root@pandora root]#

Logs of the successful search:
Jun 21 10:40:38 pandora slapd[3022]: conn=4 fd=13 ACCEPT from
IP=10.0.2.177:32821 (IP=0.0.0.0:389)
Jun 21 10:40:38 pandora slapd[3030]: conn=4 op=0 BIND dn="" method=128
Jun 21 10:40:38 pandora slapd[3030]: conn=4 op=0 RESULT tag=97 err=0 text=
Jun 21 10:40:38 pandora slapd[3030]: conn=4 op=1 SRCH base="o=company,c=br"
scope=2 filter="(gidNumber=10000)"
Jun 21 10:40:38 pandora slapd[3030]: conn=4 op=1 SRCH attr=uid
Jun 21 10:40:38 pandora slapd[3030]: conn=4 op=1 SEARCH RESULT tag=101 err=0
nentries=1 text=
Jun 21 10:40:38 pandora slapd[3031]: conn=4 op=2 UNBIND

Now the error:
Jun 21 10:40:50 pandora slapd[3022]: conn=5 fd=13 ACCEPT from
IP=10.0.2.177:32822 (IP=0.0.0.0:389)
Jun 21 10:40:50 pandora slapd[3030]: conn=5 op=0 BIND dn="" method=128
Jun 21 10:40:50 pandora slapd[3030]: conn=5 op=0 RESULT tag=97 err=0 text=
Jun 21 10:40:50 pandora slapd[3030]: conn=5 op=1 SRCH base="o=company,c=br"
scope=2 filter="(gidNumber=1000*)"
Jun 21 10:40:50 pandora slapd[3030]: conn=5 op=1 SRCH attr=uid
Jun 21 10:40:50 pandora slapd[3030]: <= bdb_substring_candidates: (gidNumber)
index_param failed (18)
Jun 21 10:40:50 pandora slapd[3030]: conn=5 op=1 SEARCH RESULT tag=101 err=0
nentries=0 text=
Jun 21 10:40:50 pandora slapd[3031]: conn=5 op=2 UNBIND

The logs show an error in the substring index search, which is expected. But
this attribute doesn't accept a substring index. It also does not accept ">=" or
"<=" searches. I thought that, without the substring index, searches would just
be slow, but they simply do not work with this attribute type. So, it is
impossible to search for anything but an exact match.

slapd.conf:
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args
database        bdb
suffix          "o=company,c=br"
rootdn          "cn=manager,o=company,c=br"
directory       /var/lib/openldap-data
checkpoint 512 30
index   objectClass     eq
index   uid,uidNumber,gidNumber,memberUid       eq

testuser.ldif used:
dn: o=company,c=br
o: company
objectClass: top
objectClass: organization

dn: ou=People,o=company,c=br
objectClass: top
objectClass: organizationalUnit
ou: People

dn: uid=testuser,ou=People,o=company,c=br
uid: testuser
objectClass: top
objectClass: posixAccount
objectClass: person
uidNumber: 10000
gidNumber: 10000
cn: testuser
sn: testuser
gecos: this is a test user
userPassword: testuser
homeDirectory: /home/testuser
loginShell: /bin/bash


Using openldap-2.1.30, berkeley DB 4.2.52 + 2 patches, sasl-2.1.18