[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
(ITS#9120) Searches including generalizedTime attributes with index
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.
Thank you very much for doing a great job!