markus.widmer@daasi.de wrote:
Full_Name: Markus Widmer Version: 2.4.48 OS: CentOS 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.24.13.226)
Hi!
we have recognized a strange behaviour for searches which include an attribute with syntax 1.3.6.1.4.1.1466.115.121.1.24 and the matching rules generalizedTimeMatch and generalizedTimeOrderingMatch set. If the timestamps in the objects have values before 1970, then a search for "<=" or ">=" only seams to works if:
- The attribute is not part of the index
- The attribute is part of the index but "objectClass" is not
Reproduction: We used two entries with the attribute "schacExpiryDate" from the objectClass "schacEntryMetadata" but this can be reproduced with other attributes as well:
attributetype ( 1.3.6.1.4.1.25178:1:2:17 NAME 'schacExpiryDate' DESC 'Date from which the set of data is to be considered invalid (format YYYYMMDDhhmmssZ)' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
We used two entries:
user.1: schacExpiryDate: 19711007093230.514Z
user.2: schacExpiryDate: 19561007093230.514Z
First try: we used this index configuration:
index sn eq index schacExpiryDate eq index objectClass eq
Search filter 1 was: (schacExpiryDate<=19800101120000Z) Result 1 was: user.1
Search filter 2 was: (schacExpiryDate>=19010101120000Z) Result 2 was: user.2
Second try: we used this index configuration:
index sn eq #index schacExpiryDate eq index objectClass eq
Search filter 1 was: (schacExpiryDate<=19800101120000Z) Result 1 was: user.1 and user.2
Search filter 2 was: (schacExpiryDate>=19010101120000Z) Result 2 was: user.2 and user.2
Third try: we used this index configuration:
index sn eq index schacExpiryDate eq #index objectClass eq
Search filter 1 was: (schacExpiryDate<=19800101120000Z) Result 1 was: user.1 and user.2
Search filter 2 was: (schacExpiryDate>=19010101120000Z) Result 2 was: user.1 and user.2
We could reproduce this with 2.4.42, 2.4.44 and 2.4.48. We hope you can reproduce this as well to see what is happening here.
Yes, can reproduce this. The function that converts a component-wise time into a timet is referencing time since 1970. The date in 1956 would yield a negative timet value but the fields are unsigned ints, so instead it's treated as 17,000 years in the future. We can probably change this to handle signed timestamps but need to consider this further.