Why is passing {'__builtins__': {}} as eval()'s globals not a sandbox for untrusted expressions?

## The setup this question always comes from A feature lands that lets people write a small formula. Take an invoice-PDF renderer where a template author can type an expression for a computed line total - `qty * unit_price * (1 + vat)`. Someone reaches for `eval()`, notices that is alarming, and writes what looks like the careful version: ```python eval(formula, {"__builtins__": {}}, fields) ``` It passes review because it *looks* locked down. It is not. ## What the empty builtins mapping actually does When `eval()` receives a globals dict without a `"__builtins__"` key, the interpreter injects a reference to the builtins module so that ordinary names work. Supplying an explicit empty mapping suppresses that injection. The effect is precisely one thing: names like the file-opening builtin, the import machinery's entry point, the object-introspection builtins and the compile/eval/exec trio are no longer resolvable *by name*. That is a name-resolution change. It removes convenience, not capability. Python's object model is uniformly reflective: every object exposes its class, and from a class the rest of the runtime is a chain of ordinary attribute accesses away. An expression that can perform attribute access on *any* live object has a path back to arbitrary callables. It does not matter that the starting object is a plain integer you passed in as a field value. This is why "restricted eval" is a recurring, and recurringly broken, genre: each published recipe blocks the previously-published escape, and a new one appears. Treat that history as the evidence - the specific escape chains are a study of their own, but the conclusion for design purposes is settled. ## The half nobody blocks: resources Suppose, arguendo, the namespace were airtight. `eval()` still has no time limit, no memory limit and no allocation ceiling; there is no timeout parameter and no release has ever added one. An expression consisting only of integer literals and operators - no names, no calls, nothing your validator would flag - can occupy a core for a very long time and drive the process into swap or into `MemoryError`. In the invoice renderer that failure does not look like an attack. It looks like an **intermittent timeout**: some PDF jobs come back, some hang until the request times out, retries make it worse because the retried job runs the same formula, and the metric that moves is render latency, not anything security-shaped. Nothing in a 27-minute test suite reproduces it, because the suite runs the formulas the team wrote, not the one a template author saved last Tuesday. Availability is the part of a restricted-eval design that fails first and gets diagnosed last. ## The safe door: parse, inspect, decide, then run `ast.parse()` is the mechanism that changes the shape of the problem. It compiles source into an abstract syntax tree **without executing anything**, which turns "run this and hope" into "look at this and decide". A validator walks the tree and rejects node types outright: ```python import ast ALLOWED = (ast.Expression, ast.BinOp, ast.UnaryOp, ast.Constant, ast.Name, ast.Load, ast.Add, ast.Sub, ast.Mult, ast.Div, ast.USub) def check(src): tree = ast.parse(src, mode="eval") for node in ast.walk(tree): if not isinstance(node, ALLOWED): raise ValueError(f"{type(node).__name__} is not allowed") return tree ``` An **allowlist** is the only defensible shape. A denylist of "dangerous" node types or substring filtering on the source text both fail for the same reason: they enumerate what you thought of. With calls, attribute access and subscripts excluded up front, the reflective paths that make the restricted-namespace approach hopeless are simply not expressible, because the *grammar* that reaches them never compiles. Then bound the rest: cap the source length and the tree depth before you walk it, cap the magnitude of numeric literals if exponentiation is allowed at all (or exclude the power operator, which is the cheapest single fix for the resource problem), and give the evaluation a wall-clock budget in a worker you can kill. ## When you genuinely need arbitrary code Sometimes the requirement really is "run the user's Python". Then the boundary must be one the operating system enforces around a separate process - not a dictionary inside your interpreter. That is a different design with its own long list of considerations, and the honest senior answer is to name it as a different design rather than to reach for a cleverer mapping. ## What to say in the interview Three beats. First: the empty builtins mapping changes name resolution and nothing else, and the object model makes name resolution an unsound boundary. Second: even a perfect namespace leaves CPU and memory unbounded, and in production that is the failure you actually meet. Third: the fix is to stop executing untrusted text - parse it, allowlist the node types, and evaluate only a subset you defined - reserving process isolation for the case where arbitrary code is a real requirement.