Grant Edwards wrote:
On 2005-01-25, Rocco Moretti <[EMAIL PROTECTED]> wrote:
Bottom line: Don't exec or eval untrusted code. Don't import untrusted modules.
I still don't see how that's any different for Python than for any other language.
Yep, and one should be careful about executing untrusted C code, too. If you're running a webserver, do you let random users upload executables and then run them? Probably not.
The key point here, what I was attempting to say in my earlier post, is that while Python can be useful as an internal scripting language inside of an application, it gives users of that application the same power over your system as any arbitrary C code. That's fine if it's an internal application, or the application can be run with (enforceable) restricted permissions, but it's still risky. How many security alerts has Microsoft issued because of some bug that allowed the execution of arbitrary code? Well, having Python scripting access is essentially the same thing. At best, you can use the external environment to limit the process running Python to its own sandbox (e.g. running as a limited-permission user in a chroot jail), but you still can't prevent one user of that application from screwing with other users of the application, or the application's own internal data.
In other words, the only difference is that Python makes it much more tempting to hand over the keys to your server.
I confess that I jumped to the (apparently unsupported) conclusion that this was some sort of server-based, internet/shared application. If that's not the case, then concerns about security are not so significant. If the users are running this application on their own machines, then letting them script it in Python is a perfectly valid (and probably quite desirable) approach.
Jeff Shannon Technician/Programmer Credit International
-- http://mail.python.org/mailman/listinfo/python-list
