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

[Kevin Reid]

On Sep 14, 2009, at 11:08, Thomas Leonard wrote:
> On Tue, 2009-09-01 at 16:08 +0100, Thomas Leonard wrote:
>> On Fri, 2009-08-28 at 19:15 -0400, Kevin Reid wrote:
>>> No, you should use the vat-wide persistence sealer, whose unsealer  
>>> is
>>> closely held by the vat persistence system, in your
>>> __optSealedDispatch. If you seal your portrayal (what you would  
>>> return
>>> from __optUncall) then you will get the behavior you want without  
>>> any
>>> global definitions.
>>>
>>> Unfortunately, IIRC, the persistence sealer is also closely held,  
>>> but
>>> there is no good reason for this. (MarkM, could you confirm this?)
>
> OK, I modified ScopeSetup to put a "persistence" object in safeScope  
> (I
> couldn't see a way to do this from E). The main program binds this  
> to an
> object with the brand and sealer, using a resolver in privScope. Is  
> this
> sensible (at least as a work-around)?

IMO, ScopeSetup should directly get the sealer from the  
PersistentKeyHolder, rather than having E-level code do it. There may  
be a reason to have more configurability than that though.

MarkM, is there any reason the persistence sealer should not be widely  
available?

> 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.

>> 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.

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?

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>