Global environment leakage from restricted setfenv environment tables

Answer the exact question first

When a Lua 5.1 function is given an environment table that has no __index pointing to the original _G, pure Lua code cannot recover the true global environment. The same isolation holds in Lua 5.2+ when the function’s _ENV upvalue is set to such a table. No documented Lua‑level mechanism lets the function reach _G unless that reference is explicitly passed, stored in an upvalue, or the sandbox has access to the debug library to inspect other functions’ upvalues.

Why the isolation is strict in Lua 5.1

• setfenv(f, env) replaces the function’s environment table with env.
• Variable lookups inside f first consult env. If a key is missing and env has no __index, the lookup fails and returns nil.
• The global table _G is itself a key in the original environment; if env does not contain a reference to _G, the name _G is unresolved.

Same principle in Lua 5.2+ with _ENV

• Compiled functions capture the current environment in the _ENV upvalue.
• Re‑assigning _ENV to a restricted table behaves analogously to setfenv.
• Without an __index to the original _G, lookups for global names return nil and the name _G is not found.

Potential escape routes (outside pure Lua)

• debug.getupvalue can expose an upvalue that holds a reference to _G if the sandbox has access to the debug library.
• C extensions that call lua_getglobal or lua_getfield can bypass the environment table entirely, but this is outside the scope of a vanilla Lua interpreter without hostile extensions.

Verification steps for Lua 5.1 and 5.2+

1. Create a restricted environment table without __index:

   local env = {print = print}  -- only a safe function
   

2. Define a function that uses a global name:

local function test()
  return foo  -- 'foo' is a global that does not exist in env
end

3. Replace the environment:

   setfenv(test, env)  -- Lua 5.1
   

   test._ENV = env  -- Lua 5.2+ (or use _ENV in the function body)
   

4. Call the function and check the result:

   print(test())  -- should print nil, not the global 'foo'
   

5. Attempt to access _G directly:

   print(_G)  -- should be nil, confirming no reference
   

6. Optionally, add a __index to env that points to _G and repeat the call to observe that globals become reachable again.

What to ask if the sandbox might have extra capabilities

If the sandboxed environment can load modules or access the debug library, the isolation guarantee weakens. In that case, the recommendation changes: you must either disable debug or ensure that no function in the sandbox holds an upvalue to the original _G. So, does the sandbox have access to the debug library?

Conclusion

Under the stated premises—no hostile C extensions and no debug access—a Lua 5.1 function set with setfenv to a table lacking an __index cannot escape to the original global environment. The same holds for Lua 5.2+ with _ENV. Verification is straightforward by attempting to read a known global and checking that the result is nil and that _G is unresolved.