I tried building something like this for rust, in order to execute closures as a separate process[0]. I could probably automate it for a struct with a macros s

I tried building something like this for rust, in order to execute closures as a separate process[0]. I could probably automate it for a struct with a macros so that the API was autosandboxed. Also, it was purely an experiment and is not particularly safe - secrets in the "broker" process would leak to the client, for example. I had plans to deal with at least some of these issues using a build.rs to generate a separate binary that could be exec'd but I stopped caring. I wonder how this sandboxapi gets around that? The reason I didn't bother was because I found that constructing the sandbox was the hard part, not executing the code in it - how do you detect what the code needs to do in the sandbox? You end up too tight or too loose. Also, performance is miserable if you have to fork/exec every single time. So you may be tempted to cache the process across executions but that comes with its own pains. Again, curious how this is dealt with in sandboxapi. Personally, I want to see sandboxing support at a language level. I imagine a language, perhaps like Pony, which has isolated units of execution that connect via some form of RPC/message passing. With a type system that "taints" types based on actions, basically a capability type that propagates upwards, you could generate seccomp filters for every unit of execution. Pony seems like it's actually not far from this, from what I could tell. Sandboxing in a language like this is a matter of moving the execution unit out of process, which shouldn't be that hard. [0] https://github.com/insanitybit/sandbox https://github.com/insanitybit/sandbox