Skip to content

Instantly share code, notes, and snippets.

@ShadowNinja
Created December 7, 2016 04:13
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ShadowNinja/4cbd51890b46ff40a94739dfb6cfe6a5 to your computer and use it in GitHub Desktop.
Save ShadowNinja/4cbd51890b46ff40a94739dfb6cfe6a5 to your computer and use it in GitHub Desktop.

Ideally we'd just keep each mod in a separate lua_State and make mods pass data amongst themselves through a Minetest API. This would improve security and probably make mod-level multithreading easier, but it would break just about all mods. Without this we're limited to a "best guess" as to what mod is running. During init time this guess is fairly accurate, but after init time it's a mess.

For example, even at init time I think the following sandbox escape is possible (although I haven't actually tested it):

minetest.conf:
    secure.trusted_mods = trusted
mods/trusted/depends.txt
    untrusted
mods/trusted/init.lua:
    untrusted()
mods/untrusted/init.lua:
    function untrusted() assert(minetest.get_insecure_environment()) --[[ !!! ]] end

The less extreme case of an untrusted mod writing to another untrusted mod's files is also possible (but less problematic since there's no outright sandbox escape). This issue isn't possible if your trusted mods are written carefully (or better yet, you have no trusted mods), but it's quite a pitfall. And mod interactions become much more complicated after init time. Minetest has a "best guess" for debug purposes (see core.{get,set}_last_run_mod()), but it isn't reliable enough to bother checking it in a security context.

In short: adding security over an API that was never designed to be secure is hard, and all of these compatibility hacks are getting annoying. :-P

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment