Why is there no reliable way to sandbox untrusted Python inside the same interpreter process?

## The question behind the question Interviewers ask this early because it separates candidates who think of Python as a set of features you can toggle from those who understand that its dynamism is structural. 'Just turn off the dangerous parts' is the wrong mental model, and this question surfaces it. ## What 'sandbox in the same process' means The tempting design is: run `exec(user_code, safe_globals)` where `safe_globals` has no `open`, no `__import__`, an emptied `__builtins__`, maybe a curated set of helpers. The hope is that by controlling the *names* the code can see, you control what it can *do*. This is in-process sandboxing, and it does not work. ## Why it does not work: reachability Controlling names controls only name *lookup*. It does nothing about *attribute access* on the objects that are unavoidably in scope. Consider what the untrusted code always has: - Any literal it writes (`()`, `''`, `0`) is a real object with a real `__class__`. - From `__class__` it reaches `__bases__`/`__mro__`, hence the builtin `object`. - `object.__subclasses__()` lists every loaded class in the process. - Any function object exposes `__globals__`, which typically contains `__builtins__` and the module's imports. - `gc.get_objects()` returns nearly every live object regardless of what was passed in. - Frame objects (`sys._getframe`) expose the caller's globals and locals. Each of these is an *edge* in the object graph, and the graph is redundant: several independent paths lead from 'a harmless literal' to 'the real `os` module'. You cannot delete these edges — CPython does not let you reliably strip attributes off builtin types, and even a perfect seal on one path leaves the others. There is no finite blacklist that closes a graph the language keeps fully connected by design. ## History backs this up Python once shipped `rexec` and `Bastion` modules intended to restrict execution. They were removed because they could not be made secure. The language documentation is explicit that there is no supported way to run untrusted code safely in-process. This is not a missing feature; it is a consequence of the object model. ## What actually works The boundary must be the operating system: - **Separate process.** Launch the untrusted code as a child process (for example via `subprocess`), so its interpreter is disjoint from yours. A breakout inside it reaches its own objects, not your application's. - **Least privilege and limits.** Drop privileges, remove network access, use a read-only or disposable filesystem, and impose CPU, memory, and wall-clock ceilings so the code cannot exhaust the host or hang forever. - **Container or VM.** For arbitrary, internet-submitted code, wrap the process in a container or a microVM for a much stronger kernel/hardware boundary. (The mechanics of containers and OS isolation belong to their own topics; the language-level point is simply that this is where the boundary lives.) ## The one-sentence version You cannot sandbox untrusted Python by hiding names, because reflection reaches everything the interpreter has loaded; put the untrusted code in its own process behind an OS boundary instead. ## Interview framing A junior is expected to state the conclusion confidently and give at least one reason (the object graph is connected; reflection reaches the builtins). A stronger answer names a concrete path such as `object.__subclasses__()` and mentions that `rexec`/`Bastion` were removed for exactly this reason, then points at the process/container/VM boundary as the fix.