On Fri, Jun 10, 2011 at 12:54 PM, Iustin Pop <[email protected]> wrote: > On Fri, Jun 10, 2011 at 11:47:23AM +0200, Rene Nussbaumer wrote: >> On Fri, Jun 10, 2011 at 10:46 AM, Iustin Pop <[email protected]> wrote: >> > On Wed, Jun 08, 2011 at 11:00:32AM +0200, René Nussbaumer wrote: >> >> + """ >> >> + return (self.mc.add(key, value, time=ttl) or >> >> + self.mc.replace(key, value, time=ttl)) >> > >> > This does not make any mention of how/if the values are serialized. What >> > is happening here? >> >> The module memcache uses Pickler to do serialization and >> deserialization. So you want to have that documented in the docstring? > > Hmm. So each cache backend will have to do its own serialisation? I was > rather thinking that we control the serialisation in the generic cache > layer, and just send string key/vals to the cache backends.
Well it's fairly easy to add that to the memcache abstraction as well :) > In this particular case, this is not good. It is known that pickle has > potential security issues and one should not blindly unpickle untrusted > data; since memcache has no (AFAIK) ACLs, it means that any > unpriviledged process on the machine could potentially hijack our stuff. To exploit Pickle, yes. The issue of modifying the cache is possible even if we just store strings. However, memcache also supports SASL if modifying is of any concerns. memcache is designed to run on trusted network in first place :). I see the (very good) point in regard of Pickle (which we can work around by serialize into our own format first). I was not aware of this issue with Pickle, thanks for lighting me up. So about modifying cache values, given we have solved the Pickle, what can an potential attacker gain out of it? One can at worst confuse the iallocator, and fake some _runtime_ values to wrong values (like capacity) or did I miss something? The cache is supposed to be reinitialized, for now, at the beginning of every LU which modifies data and is not read only. René
