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

[Mark Miller]

Catching up now. Sorry for the long delay. I'd like to say it won't
happen again, but I'm likely to continue to be too busy for the
foreseeable future (at least seven months). But I'll try to catch up
again as I have the chance.

On Mon, Sep 14, 2009 at 3:43 PM, Kevin Reid <kpreid at mac.com> wrote:
> On Sep 14, 2009, at 11:08, Thomas Leonard wrote:
>> 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?

An oversight. This is a good plan. Thomas, feel free to submit a
patch. Kevin, feel free to make a commitment along the lines you
explain above.


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

This is indeed excessively surprising. I'm not sure whether or not the
slot solution is a kludge. The persistence of var-slots needs to be
fixed regardless.


-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM