2 ms·
Just run it in a separate process with a seccomp sandbox, using pipe/socket IPC with a timeout (if it's some anti-DoS/intrusion thing, just fail allowing the re
by devit 9y ago
Just run it in a separate process with a seccomp sandbox, using pipe/socket IPC with a timeout (if it's some anti-DoS/intrusion thing, just fail allowing the request, since it's going to have false negatives anyway).
The IPC cost should not be significant compared to the rest of the web server code.
Can also ask them to do the work and provide a small open source in-process shim that sets up and talks to the sandboxed process.
- anonacct37 9y agoI'm surprised your comment is showing up grey (downvoted). It' a perfectly reasonable solution. I'm considering adding a new "remote" plugin type to our server for running hooks in sidecar processes. It wouldn't be my first or second choice but it makes lots of sense if you have to talk to something that might have bad p99 response times. Please feel free to reach out to me (info in profile) if you ever want to have a chat or are looking for some fun work.
- mabbo 9y agoIt's not only the idea of "running this code might be dangerous". It's also "depending on this code to do something we need, it might suddenly drop dead and we'll still need it". It's a question of devops- if this thing dies, or changes in negative ways, do I have the power to fix it internally? Or am I calling an outside company during business hours only to request that they please look at my problem? That's the danger large companies face when deciding if they should depend on an external vs build it internal.