[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#5048) Suspicious use of 'unchecked' limit syncprov
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/