[e-lang] Newbie questions about persistence (Attn MarkM: Possible surprise-vulnerability in persistence protocol)

[Thomas Leonard]

On Mon, 2009-09-14 at 15:43 -0400, Kevin Reid wrote:
> On Sep 14, 2009, at 11:08, Thomas Leonard wrote:
> > On Tue, 2009-09-01 at 16:08 +0100, Thomas Leonard wrote:
[...]
> > There are 48 separate objects in my program that need it, so I'm
> > reluctant to start passing it around everywhere. I want to make it as
> > easy as possible to serialise objects in a safe way; otherwise people
> > will be tempted to __optUncall instead, I think.
> 
> __optUncall is appropriate for any 'data structure'-like (Transparent)  
> object with no private state.

Unfortunately, few of my classes are like that, and even a class which
currently provides free access to all of its state might be extended
later, and it would be easy to forget to switch to the secure version.

Also, people are going to cut-and-paste my code when extending it, and
they probably won't think about these things much while they're doing
it, so I'd like to make it as hard as possible to get it wrong.

> >> I think I still need more help here. A naive attempt would be:
> > [...]
> >> My attacker gets persisted with a single oneShot, but revives with  
> >> two
> >> (and can therefore print "Invoking!" twice).
> >>
> >> I suppose I could create a simple proxy to the oneShot and give  
> >> that to
> >> the attacker. The attacker could make copies of the proxy, but they'd
> >> still all forward to a single oneShot.
> >
> > Can someone confirm whether this is the correct approach?
> 
> I missed this point before. You're right - the persistence sealer  
> protocol does not ensure uniqueness. This could be fixed in the  
> protocol by including the object's own traversal key.
> 
> But as a workaround, you can define the proxy as you describe. I would  
> recommend making it part of the implementation of the oneShot, and not  
> exposing its existence to the user. (One way to do it would be to have  
> your oneShot serialize, not as its current state, but rather the slot  
> of the used flag: def uncall := [makeOneShot, "withFlagSlot",  
> [&used]]. Then the 'used' slot object serves as the un-duplicatable  
> object.

That's clever - thanks!

> But this seems like a kludge, and I think we should fix the  
> persistence protocol. Thanks for spotting this.
> 
> MarkM, do you agree this is an excessively surprising problem?


-- 
Dr Thomas Leonard
IT Innovation Centre
2 Venture Road
Southampton
Hampshire SO16 7NP

Tel: +44 0 23 8076 0834
Fax: +44 0 23 8076 0833
mailto:tal at it-innovation.soton.ac.uk
http://www.it-innovation.soton.ac.uk