lua-users home
lua-l archive

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

Josh Haberman wrote:
> But then I have to trust users not to touch the real
> members obj.__foo and obj.__has_foo whereas with a userdata
> I can make them mostly inaccessible.

Well, why do you mistrust the users of your code? Document the
public API and deny support if they use any undocumented parts.
If you can't trust your fellow developers, then none of this
protected/public nonsense will help, anyway.

Note there's an important difference between 'untrusted users of
your code' and 'untrusted code'. I wasn't sure about your
intentions, but see below.

> Would the straight cdata approach be noticeably more efficient?


> Is there any reasonable way you could prevent direct access to cdata
> in a Lua program, but allow it if the Lua program called into a module
> that had FFI enabled?  Does a function have source/line information
> about where it was defined that could be used to perform this access
> control?

That's not a viable approach for sandboxing. The only reasonably
safe way to run untrusted/malicious Lua scripts is to sandbox it
at the process level. Everything else has far too many loopholes.