←back to thread

MCP Run Python

(github.com)
173 points xrd | 3 comments | 15 Apr 25 11:09 UTC | HN request time: 0.449s | source
Show context
behnamoh ◴[17 Apr 25 15:27 UTC] No.43718268[source]▶
So their method of sandboxing Python code is to spin up a JS runtime (deno), run Pyodide on it, and then run the Python code in Pyodide.

Seems a lot of work to me. Is this really the best way to create and run Python sandboxes?

replies(11): >>43718335 #>>43718770 #>>43718841 #>>43719300 #>>43719370 #>>43719672 #>>43719881 #>>43721408 #>>43722369 #>>43723869 #>>43726452 #
kodablah ◴[17 Apr 25 21:23 UTC] No.43722369[source]▶
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#...

replies(2): >>43723510 #>>43728142 #
1. achierius ◴[17 Apr 25 23:52 UTC] No.43723510[source]▶
Out of curiosity, why did you need a sandbox if you didn't have any security concerns?
replies(2): >>43726969 #>>43727756 #
2. necovek ◴[18 Apr 25 11:20 UTC] No.43726969[source]▶

  > 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.
3. kodablah ◴[18 Apr 25 13:10 UTC] No.43727756[source]▶
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.