[ZODB-Dev] Re: Can __setstate__ trigger an RCE?

[Casey Duncan]

On Tue, 6 Jul 2004 16:48:56 -0400
"Tim Peters" <tim at zope.com> wrote:

> [Christian Robottom Reis]
> >> I'm still trying to track down a problem that occurs with read
> >conflicts> in IndexedCatalog when using ZODB without MVCC enabled.
> >The issue is> that occasionally, I find in my client logs a conflict
> >error on a> OOBucket instance stored as _change_buffer in Catalog
> >persistent> instances. The interesting part is that the Catalog has
> >the following> code as part of its __setstate__ method:
> >>
> >>     def __setstate__(self, state):
> >>         # Load the _change_buffer to ensure we have its state and
> >>         # avoid a ReadConflictError when handling it
> >>         list(self._change_buffer.items())
> 
> [Casey Duncan]
> > This code is probably more likely to cause an RCE rather than
> > prevent it, because it tries to load *all* of the buckets of the
> > BTree whenever the BTree's container is loaded. If somebody else
> > somewhere has modified the btree in any way since this transaction
> > started, then you're toast (even if this transaction would never
> > actually read the changed buckets of the tree).
> 
> Well, Christian said _change_buffer is bound to an OOBucket, not to a
> BTree. If that's correct, maybe he'd be better off switching to a
> BTree (depends on how big _change_buffer gets; if it's typically "very
> small", it's going to live in a single bucket regardless).
> 
> [... or, if it is a BTree already, lots of good advice snipped ...]

I figured it was a bucket in a BTree (he said the conflict happened on a
bucket), but that was just a guess on my part. if _change_buffer it is
just a bucket, then you don't need to do so much work to load it since
all the key/value pairs are in one persistent record.

-Casey