h.b.furuseth(a)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/