News for hackers. Stuff that matters.
Re:MCP Run Python by kodablah on Thursday April 17, 2025 @05:23PM (#43722369)
There just aren't good Python sandboxing approaches. There are subinterpreters but they can slow to start from scratch. There are higher-level sandboxing approaches like microvms, but they have setup overhead and are not easy to use from inside Python.

At Temporal, we required a sandbox but didn't have any security requirement, so we wrote it from scratch with eval/exec and a custom importer [0]. It is not a foolproof sandbox, but it does a good job at isolating state, intercepting and preventing illegal calls we don't like, and allowing some imports to "pass through" the outside instead of being reloaded for performance reasons.

0 - https://github.com/temporalio/sdk-python?tab=readme-ov-file#...

Re:MCP Run Python by achierius on Thursday April 17, 2025 @07:52PM (#43723510)
Out of curiosity, why did you need a sandbox if you didn't have any security concerns?
Re:MCP Run Python by necovek on Friday April 18, 2025 @07:20AM (#43726969)

  > but it does a good job at isolating state, intercepting and preventing illegal calls we don't like
Sounds like they put the reason just there.
Re:MCP Run Python by kodablah on Friday April 18, 2025 @09:10AM (#43727756)
Sibling quoted the proper part. It's to help people keep code deterministic by helping prevent shared state and prevent non-deterministic standard library calls.
Re:MCP Run Python by fzzzy on Friday April 18, 2025 @09:56AM (#43728142)
At least we have subinterpreters now. Even if they are slow that is a really good thing.