Question regarding the security restrictions - why disable built-ins such as `all`, `set`, `list`, `enumerate`, `min`, `sum`, `sorted`, etc?
Question regarding the security restrictions - why disable built-ins such as `all`, `set`, `list`, `enumerate`, `min`, `sum`, `sorted`, etc?
https://pypi.python.org/pypi/RestrictedPython
I realize this is annoying, and ideally I shouldn't even be doing this. It was just a quick hack for the version 1. I'll probably try to run user scripts in something like Docker. Any suggestions would be appreciated.
You'll need to communicate with the Python script using IPC.
- Portability: it's just as portable as lxc, so if you meant portability in the sense of 'well he could use it on FreeBSD if he wants to switch from Linux' I don't think there's a win there. If you mean that his containers won't depend on the environment used to spawn them, I guess I don't think that's so important. I always make sure my environments are easily reproducible, and I am happy to reap the reward of that--the reward being that I can do 'unportable' things and not have to worry. Instead of running the environment you want in a container, why not just run it normally and skip that step?
- Reproducibility: see last point. If he wants reproducibility, he can shove that one-liner in a script somewhere and call it.
All he wants to do is isolate a process. You don't need a chroot for that, or service discovery, or lifecycle managment, or a Dockerfile, or whatever else. It's like if someone advocated the use of a 'grep manager' instead of just running grep. The simplest possible thing to do is unshare the namespaces he wants to isolate from harm. So I suggested exactly that.
EDIT: also re portability, it sounds like the rest of his environment depends on these Python scripts anyway, so I don't think he'd gain anything from being able to use them in a different environment.