El entorno del chunk: cargar con su propio _ENV

El nivel 9 estableció que un chunk se compila siempre dentro de una variable externa llamada _ENV y que todo nombre libre es un campo de esa variable. La lección anterior añadió que load devuelve el chunk como una función corriente. Junta las dos frases y obtienes la consecuencia más productiva de todo el nivel: si puedes decidir el valor de ese upvalue en el momento de cargar, puedes decidir qué mundo existe para el código que acabas de compilar. De esa capacidad de una sola línea salen la configuración como código y el sandboxing, que son la misma técnica mirada desde dos intenciones opuestas: una quiere recoger lo que el chunk escribe, la otra quiere limitar lo que el chunk alcanza.

El cuarto argumento

El chunk principal producido por load declara siempre un upvalue, y ese upvalue se llama _ENV. Cuando pasas el cuarto argumento, Lua lo instala ahí antes de devolverte la función; cuando no lo pasas, instala el entorno global.

local mundo = { print = print }
local f = load("print(saludo)", "=prueba", "t", mundo)

print(debug.getupvalue(f, 1))   --> _ENV   table: 0x...
mundo.saludo = "hola"
f()                             --> hola

saludo = "adios"                -- global del anfitrion
f()                             --> hola   el chunk no lo ve

No hay ninguna otra pieza en juego. El chunk escribe print(saludo), el compilador lo reescribe como _ENV.print(_ENV.saludo), y _ENV es la tabla que le diste. Como la instalación ocurre sobre un upvalue ordinario, también puedes cambiarla después sin recompilar:

local otro = { print = print, saludo = "buenas" }
debug.setupvalue(f, 1, otro)
f()                             --> buenas

Compilar una vez y ejecutar contra entornos distintos es, por tanto, una operación de coste constante. Una plantilla compilada, una regla de negocio, un script de usuario: todos se compilan al arrancar y se ejecutan después tantas veces como haga falta, cada vez contra una tabla distinta. Ese desacoplamiento entre el código y su mundo es lo que hace que la técnica escale.

Configuración como código

Si todo asignación a un nombre libre es una escritura en el entorno, entonces un archivo de configuración escrito en Lua es una tabla: basta con darle una tabla vacía y recogerla al terminar.

local function cargar_config(ruta)
  local datos = {}
  local chunk, err = loadfile(ruta, "t", datos)
  if not chunk then return nil, err end
  local ok, e = pcall(chunk)
  if not ok then return nil, e end
  return datos
end

Y el archivo de configuración es Lua legítimo, no un formato:

tema           = "catppuccin"
numeros        = true
tab            = 2
plugins        = { "telescope", "treesitter", "fugitive" }

for i = 1, 9 do
  atajos["espacio" .. i] = "ir a la pestana " .. i
end

Lo que se gana frente a un formato de datos es exactamente lo que se pierde en garantías, y conviene enunciarlo sin adornos. Se gana el lenguaje completo: bucles, condicionales, funciones auxiliares, composición de valores, reutilización entre archivos. Se pierde la terminación garantizada —un archivo de configuración puede colgarse— y la posibilidad de analizarlo sin ejecutarlo, que es lo que permite a una herramienta externa reescribir un archivo JSON conservando comentarios. Neovim, nginx con su módulo de Lua y el redis embebido viven todos en el primer lado de ese intercambio, y no por casualidad: cuando la configuración describe comportamiento y no solo valores, un formato de datos acaba creciendo hasta convertirse en un mal lenguaje de programación.

La versión seria del patrón no entrega una tabla vacía sino una con metatabla, y ahí es donde la técnica supera a cualquier formato. Interceptando la lectura se ofrece un vocabulario controlado y se detecta el uso de un nombre inexistente; interceptando la escritura se detecta la errata en el nombre del campo, en el instante de la carga y con número de línea.

local campos = { tema = true, numeros = true, tab = true, plugins = true }
local vocabulario = { rojo = "#f38ba8", azul = "#89b4fa", ipairs = ipairs }
local datos = {}

local entorno = setmetatable({}, {
  __index = function(_, k)
    local v = vocabulario[k]
    if v == nil then error("nombre no disponible aqui: " .. k, 2) end
    return v
  end,
  __newindex = function(_, k, v)
    if not campos[k] then error("campo de configuracion desconocido: " .. k, 2) end
    rawset(datos, k, v)
  end,
})

El segundo argumento de error hace que la posición señalada sea la del archivo de configuración y no la del metamétodo, que es lo que convierte el mensaje en algo accionable. Ninguna configuración en JSON o TOML detecta una errata en el nombre de una clave sin un esquema aparte; aquí sale gratis del mecanismo de metatablas.

Lo que el entorno no protege

Aquí empieza la parte que se enseña mal. Un entorno restringido controla qué nombres se resuelven, y eso no es lo mismo que controlar qué objetos son alcanzables. Cualquier objeto al que se llegue por una cadena de indexaciones desde el entorno está concedido, aunque no tenga nombre propio en él.

flowchart TD
E[Entorno del chunk] --> A[Nombres concedidos explicitamente]
A --> B[Objetos alcanzables por indexacion]
B --> C[Metatablas de esos objetos]
C --> D[Metatabla compartida de las cadenas]
D --> F[Biblioteca string del anfitrion]
A --> G[Cualquier funcion del anfitrion pasada al invitado]
G --> H[Sus upvalues incluido su propio _ENV]
H --> I[Fuga completa si el invitado tiene debug]

La lista de vías de fuga es corta y hay que conocerla entera.

La biblioteca debug anula el mecanismo por completo: con debug.getupvalue sobre cualquier función del anfitrión que llegue al invitado se recupera su _ENV, y debug.getregistry entrega directamente el entorno global desde el registro de C. Un sandbox que exponga debug no es un sandbox.

Las cadenas comparten una única metatabla en todo el estado de Lua. Si el invitado puede escribir un literal de cadena —siempre puede—, alcanza la biblioteca string a través de ella, lo cual suele ser inofensivo; lo que no es inofensivo es que pueda modificarla, porque esa mutación afecta al anfitrión y a todos los demás invitados. La defensa se aplica desde fuera, protegiendo esa metatabla con el campo __metatable antes de crear ningún sandbox.

Exponer load dentro del sandbox es aceptable solo envuelto: hay que forzar el modo de texto y el entorno, porque en otro caso el invitado carga bytecode manipulado y sale del proceso de Lua por completo, como vimos en 20.1. Y require con package concede el sistema de archivos y la carga de bibliotecas en C, que es la fuga total.

Queda lo que ningún entorno puede tocar: el tiempo y la memoria. Un bucle vacío consume una CPU indefinidamente y una concatenación en bucle agota la memoria del proceso, y ambas cosas ocurren sin nombrar un solo símbolo prohibido. Sus contenciones viven fuera del lenguaje: un hook de cuenta de instrucciones instalado por el anfitrión, que es el asunto de la lección 20.4, y un asignador de memoria con límite instalado desde la API C.

Las cuatro fronteras

Un sandbox que merezca ese nombre defiende cuatro cosas distintas, y el entorno solo defiende la primera.