Re: (ITS#5048) Suspicious use of 'unchecked' limit syncprov

[hyc@symas.com]

h.b.furuseth@usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: HEAD, RE23
> OS: 
> URL: 
> Submission from: (NULL) (129.240.202.105)
> Submitted by: hallvard
> 
> 
> overlays/syncprov.c:syncprov_findcsn() sets an unchecked limit to 1.
> findcsn_cb() says
> 	/* We just want to know that at least one exists, so it's OK if
> 	 * we exceed the unchecked limit or size limit.
> 	 */
> 
> This looks like it can return a false positive if two or more other
> entries which the filter would eliminate have the same hash as the
> value syncprov searches for.

I don't believe this can cause any problem though. CSN indexing doesn't use a 
hash the way other indices do; the CSN timestamp is converted to binary form 
and saved as a 40 bit integer. Index collisions will only occur for multiple 
changes that occurred within the same 1-second interval.

The purpose of this search is to detect if a consumer's context CSN is stale, 
i.e., the provider no longer has any entries as old as the consumer's CSN. The 
fact that there is any index collision essentially proves that the CSN is not 
stale.

> Also syncprov_findcsn() passes fc_limits uninitialized outside of the
> .lms_s_unchecked field to slapd.  Valgrind complains in test018 about
> .lms_s_pr_hide in back-bdb/search.c:bdb_search().  Tested in HEAD.

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