Re: metatables for strings?

[Andrew Starks <andrew.starks@...>]

On Sunday, May 3, 2015, Nagaev Boris <bnagaev@gmail.com> wrote:
> On Sun, May 3, 2015 at 9:00 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> > 2015-05-03 19:40 GMT+02:00 Nagaev Boris <bnagaev@gmail.com>:
> >> On Sun, May 3, 2015 at 5:06 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> >>> If the methods were all provided by the sandbox author, who presumably
> >>> knows what he is doing, I don't see the problem.
> >>>
> >>
> >> Can a sandbox isolate added string's methods? Can you provide
> >> sandboxing function passing this test:
> >>
> >> string.hack = function() print("Hacked") end
> >> code = [[ ("just string"):hack() ]]
> >> sandbox(code)
> >
> > That's not the way a sandbox operates. A sandbox loads and runs
> > a string containing code from outside. I.e. the author of that code does not
> > have access to the sandbox's environment except via his code, which
> > can access global variables as fields in whatever environment the
> > sandbox's "load" cares to supply. That environment should not give
> > access to dangerous tools like the debug library, should lock the
> > string metatable, and should allow only object-oriented access to
> > string methods.
> >
>
> Consider [[ ("just string"):hack() ]] to be code from outside.
> I want prevent it from calling certain methods of string (e.g.,
> string.dump).
>
> There is practical application of such a sandbox (in forked thread).
> Can we move this discussion to that forked thread?
>
> --
>
>
> Best regards,
> Boris Nagaev

I see your point, and I can't quite conceive as to how how you can get around it, without looking up the caller's ENV from debug and proxying it with that info (unless that's dumb, as dirk has suggested, but I'm not exactly sure how).