A.M. Kuchling wrote: > Guido van Rossum wrote: > >> See my recent checkins and what I just sent to python-announce (not >> sure when the moderator will get to it): > > > Back in December I reduced the "Restricted Execution" HOWTO > to a warning not to use rexec. This morning, perhaps because of Guido's > announcement, I've gotten two e-mails from users of the module asking > for more details, both sounding a bit desperate for alternatives. > Doubtless more rexec users will come out of the woodwork as a result. > > I'd like to add some suggested alternatives; any suggestions? People > could run untrusted code inside a chroot()'ed jail; are there any > packages that help with this? > > If the application uses Bastion to let untrusted code access various > Python objects, things get really tough; the only option might be to > redesign the whole application to expose some socket-based interface to > those objects, and then run jailed code that can talk to only that > socket. (Completely redesigning applications that rely on running > untrusted code is probably a good idea in any event.) If you only want to secure a few objects, then mxProxy can help you with this: it allows access management at C level on a per-method basis and also via callbacks... http://www.egenix.com/files/python/mxProxy.html -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4