Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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#...



Out of curiosity, why did you need a sandbox if you didn't have any security concerns?


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.


  > 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.


At least we have subinterpreters now. Even if they are slow that is a really good thing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: