Hi Marcel,

On Wed, Oct 23, 2019 at 8:11 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> What about unwanted side effects that are in-image? My precious collection
> of objects here, my background wallpaper there ... I don't want my
> wallpaper to turn black and my objects to get lost ... or surprisingly
> sorted for that matter. :-)
>

Right.  The approach that I'd figured out a while ago but forgot to state
below is that the simulation MethodFinder SandboxContext can maintain a set
of objects that it has instantiated and allow assignments only to them.  So
any attempt to modify any object that has't been created while performing
the method search could be easily prevented.  To do this SandboxContext
would have to intercept any and all invocations of the new primitives, plus
primitives that create objects such as large integer arithmetic primitives,
to collect the results in its "set of writable objects".  Then it would
intercept any state altering primitives (at:put: et al) and inst var
assignment etc (popIntoReceiverVariable:, popIntoLiteralVariable: et al),
and abort the current sub-search if the target was not in the set.

 And if required, exceptions could be added to the set on initialization;
global variables whose value could be expected to change often perhaps
(caches in class variables?).  The set of writable objects could be
organized as a Dictionary from object to evaluable that answers whether a
particular index is valid to modify the object, etc.  But the basic idea is
that SandboxContext is in a position to mediate any and all accesses while
simulating execution and hence selectively prevent assignment to anything,
and only allow assignment to specific things.  I apologize for having
forgotten to state this earlier.


> Best,
> Marcel
>
> Am 17.10.2019 20:47:57 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Thu, Oct 17, 2019 at 11:13 AM Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>>
>>
>> On Wed, Oct 16, 2019 at 2:55 AM Thiede, Christoph <
>> Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
>>
>>> Hi Marcel,
>>>
>>> as I see it, this Blocks check only restricts the possible hits, so
>>> removing it should not damage any existing functionality. (I am *not*
>>> talking about modifying Dangerous!)
>>>
>>> And if you do
>>>
>>> MethodFinder methodFor: {{#(1 2). [:x | Smalltalk saveSession.
>>> false]}.#()} "pls don't run this!"
>>>
>>> you will surely expect the side effects to be executed?
>>>
>>
>> If MethodFinder were implemented using simulation (a la Context
>> class>>runSimulated:) then we could implement a proper sandbox and
>> completely discard Dangerous.  We could catch any attempt to change the
>> class hierarchy, save a snapshot, etc.
>>
>
> It would be a great project to create a subclass of Context, say
> SandboxContext, and have this ensure that when simulating it only creates
> more SandboxContexts, never a normal Context, and have SandboxContext
> override primitive invocation.  This could be a place to intercept
> modification of the class hierarchy (at:put: & become: on MethodDictionary,
> and Array to see if an attempt is being made to assign to or become: a
> MethodDictionary and/or a subclasses Array).  Perhaps SandboxContext would
> need SandboxClosure, perhaps it could simply intercept value: et al on
> Closure (see Context>>#doPrimitive:method:receiver:args:).
>
> My gut tells me that while this implementation is clever, it will also be
> more general and more easily maintainable than the current one.  There are
> issues; a time limit would have to be placed upon simulated executions
> (that's also a potential issue for the current implementation).  But it
> would be safer since instead of relying on Dangerous to identify dangerous
> code it would depend on a reasonably well-defined notion of sandbox, what
> is possible to evaluate when searching, and what is not.  One could, for
> example, implement an instantiation budget in
> SandboxContext>>#doPrimitive:method:receiver:args:.
>
> > Just curious: what would be the block example for these examples?
>>>
>>> MethodFinder methodFor: {{#(1 2). #even}. #(1)}. *'(data1 reject:
>>> data2) '*
>>> MethodFinder methodFor: {{#(1 2). #yourself descending}. #(2 1)}. *'(data1
>>> sorted: data2) (data1 sort: data2) '*
>>>
>>> Hey, maybe we should make a small game of it? :-)
>>> GuessTheSelectorGame :D
>>>
>>> Christoph
>>>
>>>
>>> ------------------------------
>>> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
>>> Auftrag von Taeumel, Marcel
>>> *Gesendet:* Mittwoch, 16. Oktober 2019 10:54 Uhr
>>> *An:* gettimothy via Squeak-dev; squeak-dev at mail.squeak.org
>>> *Betreff:* Re: [squeak-dev] MethodFinder.Blocks
>>>
>>> Hi, Christoph.
>>>
>>> The method finder (or selector browser) has a hard-coded list of
>>> possible results (or messages) to not trigger dangerous side effects. Any
>>> new feature, such as that "quasi higher-order-message" symbol , would have
>>> to be added. Sure. But keep compatiblility with block arguments. :-)
>>>
>>> Just curious: what would be the block example for these examples?
>>>
>>> MethodFinder methodFor: {{#(1 2). #even}. #(1)}
>>> MethodFinder methodFor: {{#(1 2). #yourself descending}. #(2 1)}.
>>>
>>> Especially the latter seems kind of cryptic to me.
>>>
>>> Best,
>>> Marcel
>>>
>>> Am 14.10.2019 01:27:12 schrieb Thiede, Christoph <
>>> christoph.thiede at student.hpi.uni-potsdam.de>:
>>>
>>> Hi all,
>>>
>>>
>>> I just got irritated as I evaluated
>>>
>>>
>>> MethodFinder methodFor: {{#(1 2). #even}. #(1)}
>>>
>>>
>>> and got no hit.
>>>
>>> This is because the MethodFinder stores an extra list of selector
>>> parameters that are assumed to require a block argument (Blocks) -- but
>>> nowadays this requirement is not given, as you can pass a Symbol,
>>> MessageSend, SortFunction or whatsoever, thanks to polymorphy. So (how) is
>>> this block check still relevant? If I remove it, I get the right hit and
>>> can do thinks like
>>>
>>>
>>> MethodFinder methodFor: {{#(1 2). #yourself descending}. #(2 1)}.
>>>
>>>
>>> Also, #ifError: will prevent any error thrown if the block does not
>>> match the selector.
>>>
>>>
>>> Looking forward to your answers :)
>>>
>>> Christoph
>>>
>>>
>>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191024/bd6e75ff/attachment.html>