lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Sir Pogsalot wrote:
> Maybe this is just something that was drilled into me from a young
> age but I've always operated under the "libraries should never
> assert() or segfault" mindset.  Also, users are sometimes directly
> scripting in Lua -- WoW, awesome window manager people, Garry's Mod,
> Android game creation apps/frameworks, etc...  Sandboxed environments
> maybe, but still directly working with library functions.  I don't
> think I'm being overzealous by calling this minimal amount of
> 'defensive programming' necessary :>  Also lua_objlen() existed in
> 5.1 -- and it pains me daily to think how many libraries out there
> only luaL_checkudata() and blindly access members.  Thanks for
> contributing to my early death :<

The only way for a script user to change the metatable for userdata
would be to use the debug library. The normal setmetatable function only
works on unprotected tables. And the debug library comes with this warning:

<http://www.lua.org/manual/5.2/manual.html#6.10>:
> You should exert care when using this library. Several of its
> functions violate basic assumptions about Lua code (e.g., that
> variables local to a function cannot be accessed from outside; that
> userdata metatables cannot be changed by Lua code; that Lua programs
> do not crash) and therefore can compromise otherwise secure code.

So for my modules I would use almost the same pattern as for the default
file module and just check the metatable. If somebody had taken this
metatable and used debug.setmetatable to put it on some different
userdata -- well, they would *want* their application to crash. I cannot
imagine how you would do this on accident. Executing foreign code is a
different matter, but it wouldn't make a lot of sense to expose the
debug module in a sandbox.

Best regards,

David Kolf