3 ms·
There just aren't good Python sandboxing approaches. There are subinterpreters but they can slow to start from scratch. There are higher-level sandboxing approa
by kodablah 1y ago
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#workflow-sandbox https://github.com/temporalio/sdk-python?tab=readme-ov-file#...
- achierius 1y agoOut of curiosity, why did you need a sandbox if you didn't have any security concerns?
- necovek 1y ago> 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.
- kodablah 1y agoSibling quoted the proper part. It's to help people keep code deterministic by helping prevent shared state and prevent non-deterministic standard library calls.
- fzzzy 1y agoAt least we have subinterpreters now. Even if they are slow that is a really good thing.