Re: Userdata/Table Unification

[Mike Pall <mikelu-0407@...>]

Hi,

Virgil Smith wrote:
> 1. Sandboxing.  The fact that Lua code cannot modify the metatable of
> Userdata is an important security benefit.  Consider for instance the effect
> of a script changing the gc metamethod of a userdata.

Ok, setmetatable() does not work on userdata objects. But you can change
the contents of the metatable itself:

u = any_userdata_constructor()
getmetatable(u).__gc = nil      -- Ouch!
u = nil
collectgarbage()

This will lead to resource depletion in the best case (e.g. lost file
handles) and to memory corruption in the worst case (there may be
dangling backreferences to userdata memory).

The current approach is *not* safe unless you deny the sandbox access to
getmetatable() or use a wrapper. But then you might as well protect
setmetatable(), too. I think the setmetatable() pseudo-safeguard provides
a false sense of security.

> On the other hand,
> Lua extends a method for Lua side code to mark a metatable as protected and
> so this is duplicated effort.  Also, the most important aspect of script
> security <i.e. sandboxing> is not protected by the "special status" of
> userdata.  That aspect is the protection of variables that reference
> userdata values so that malicious/buggy scripts can't "hijack" the variable.

As Jamie Webb pointed out we need to be able to completely override *all*
access methods (and maybe a special GC API).

Someone should do some benchmarks with a large application to see whether
the additional checks are really such a bad performance hit. Maybe they
can be merged with an existing flow control statement or other parts can be
optimized to compensate for it.

Bye,
     Mike