On Sun, May 3, 2015 at 1:38 PM, Andrew Starks <andrew.starks@trms.com> wrote:
<snip/>
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
Also, you can use the debug library to discover the caller's environment and
then call the methods found in the "strings" library of that _ENV or yours,
if that table is absent.
So I believe that what you want is achievable, in the sort of tar-pit-like
way that happens when you can't yet / quite re-imagine your problem to fit
the language. :)
-Andrew
I could not bare to triple post, and this idea is different enough
that I'll take the opportunity to fork...
sand boxing the string's metamethods is something that would be nice
to be able to do, but it is hard to imagine that feature existing
without something being treated as "special".
I don't know if this mechanism would be general and useful enough for
consideration, but I did think of a way that I believe could be used
to solve this problem. Both options are the same idea, but with a
different implementation:
#1: Change setmetamethod: `setmetatable(t, [table mt, function(t,
_ENV) return [mt table, nil] end, nil])`
Cons: It would break much code
Pros: Maybe it would be faster for tables that just use a table
for their metatable and not a function?
#2: Add metamethod: __getmetatable = function(t, mt, _ENV) return [mt
table, nil] end
Cons: Perhaps slower, because every object with a metatable would
need to have this field checked, first?
Pros: It would only break code if `getmetatable` did not respect
the metamethod (and you would also need `rawgetmetamethod` as well).
I'm not really proposing anything, so I welcome the rocks that anyone
wishes to throw at it. It does seem a tad... "meta meta". I only
suggesting that this sort of solution seems reasonably Lua-like, at
least from an interface perspective.
--Andrew
