Re: (ITS#9120) Searches including generalizedTime attributes with index

[hyc@symas.com]

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.

-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/