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 5:06 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> > 2015-05-03 18:40 GMT+02:00 Nagaev Boris <bnagaev@gmail.com>:
> >> On Sun, May 3, 2015 at 4:35 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> >>>
> >>> You can put a function in the "string" table and it will immediately
> >>> be callable with object-oriented syntax on a string object just like
> >>> str:format etc. Since the first argument is provided, that function
> >>> can itself pick out a submethod from a table of functions.
> >>>
> >>
> >> Changing global metatable of all strings does not sound good. If all
> >> strings had same methods, then methods added to UrlString, would also
> >> be available to normal strings. It is confusing and it breaks idea of
> >> sandboxes, because sandboxed code can apply UrlString's methods to
> >> malicious strings.
> >
> > 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)
>
>
> --
>
>
> Best regards,
> Boris Nagaev

You pose an interesting "Y" problem, but your "X" (sand boxing) problem is not sufficiently weird enough to demand it.

If you want someone to not be able to modify the metatable then that's easy. If you want to let them modify it, but not affect the provided methods, then that is also easy.

If they ask for more than that, say like to make a url class, then have them make url objects that support the string library's methods and a strings metamethods. 

Does this cover the issues that sandboxing raises?

-Andrew