Re: Lua 5.1, string metatable, sandboxing...

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

On Wed, Apr 30, 2014 at 4:28 PM, Philipp Janda <siffiejoe@gmx.net> wrote:
> You can take some inspiration from here[1].
>
> Philipp
>
>   [1]: http://lua-users.org/lists/lua-l/2014-04/msg00860.html

I would call this hack: Heroic.

It highlights that "Lua can't do this" or at the very least "really
doesn't want you to do this" (if Lua actually had an opinion).

I've been thinking about this topic. I abuse the string table and it
is the only non-sandboxed alteration to my libraries. My desire to do
it overcame my ability to behave and I'd prefer that they legalize
basic type metatable manipulation so I could make libraries that way,
but I can see the hazards, too. The most primary being that strings
are supposed to act like values.

So, then I was thinking about uservalues for regular types, but that
doesn't help. Then I was thinking about some kind of "_LOCALENV" table
that you could put values into and would be like env, but have the
caller's scope, but that seems tacked on and hack-ish.

I've mentioned another approach: make it so you can express the type
intent of a value. That way,  you can make an object out of a table
and "stuff" would just work with it. Something like:

setmock(my_string_object, "string")

if mock(my_string_object) == "string" then
   --do stuff on the string
end

When working with Lua or other libraries, we can't pass tables as
strings because many libraries don't accept the presence of
"__tostring" as proof that the table is supposed to be a "string":

local str_obj = setmetatable({}, {
  __tostring = function (t)
      return "called"
  end,
})
print(str_obj)
--> hello
io.write(str_obj)
--> lua: iotostring.lua:10: bad argument #1 to 'write' (string
expected, got table)


And it wouldn't work, anyway. __tostring is used as an "object ID"
method in some of my code and I suspect other's too.

As a consequence of running up against this, I've wrapped type to
support this kind of thing and it works really well. If/when I
refactor it, I'll probably choose to rename the library "mock" or
something like it, just to avoid monkey patching, as previously
discussed.

I can say that this approach works really well. I can put multiple
"mock" names on objects that can behave as multiple "types". For
example a {samples, scale} tuple is a "frequency" and a "number" so
that: (using the new name)

mock(my_profile) == "frequency"
--> true

mock(my_profile) == "number"
--> true --currently this is false, but if I use "mock", having this
true would be more useful.

--currently:
type.get(my_profile) >= "number"
--> true --my_profile contains number, but it isn't the primary "type".

Since Lua doesn't have this as part of the core library, I have to
patch things to work this way. It does nothing to help interact with
unknown libraries.

This is only a sandbox problem for strings (and functions, especially
things that expect functions but don't like functables), but this
facility avoids *most* of the motivation for patching strings in the
first place...

str "I have to wrap it in an object, %s" % { "so I'll just go on
breaking the law... for now"}

-Andrew