Full_Name: Andrew Findlay Version: 2.4.10 OS: Linux URL: ftp://ftp.openldap.org/incoming/andrew-findlay-20080625.tgz Submission from: (NULL) (88.97.25.132)
When 'sortvals members' is in effect, some attribute modify operations produce bad results. This seems to occur when an operation adds an attribute that sorts to the end of the list.
The attached tarball contains a cut-down config and dataset, along with a set of scripts and LDIF files that demonstrate the bug.
To create the problem:
(This does NOT need to run as root)
edit vars to set appropriate PATH
# First version of problem - single LDAP op removes one member and adds another:
rm -r openldap-db mkdir openldap-db ./start-slapd ./load-dsa data.ldif
./update-dsa mess-tenk.ldif ./update-dsa unmess-tenk.ldif
The first update is OK, but the second fails thus:
modifying entry "cn=tenK,ou=groups,o=test,dc=example,dc=org" ldap_modify: No such attribute (16) additional info: modify/delete: member: no such value
If 'sortvals member' is not set in slapd.conf.test you can just alternate those two LDIFs forever.
Check data with:
./bound-search cn=tenk
Now compare with the same process using change-tenk.ldif and change-tenk-back.ldif - they do the same job but with a value that sorts earlier, and they work OK.
# Second version - repeat adding of single value:
./stop-slapd rm -r openldap-db mkdir openldap-db ./start-slapd ./load-dsa data.ldif
./update-dsa add-member.ldif ./update-dsa add-member.ldif ./update-dsa add-member.ldif
First update OK. Second update OK but should not be. Third fails is it should.
Check data with:
./bound-search cn=tenk