Robin Becker wrote:
Couldn't this and similar things be done as a property setting on the method. The you could have a proxy security to allow various degrees of un-safeness rather than just hack the code for all people. So really safe people could open files on the server etc others could do regexps etc etc.
Well... Sort of. I mean, yes, obviously this can be done, but there's a problem; Once *anyone* is allowed access to unsecure PythonMethod you've got a fairly large security risk going unless you routinely manage your server through https. Suppose someone snoops your management sessions and grabs the username/password you use for site administration. Normally, this lets them destroy or subvert the contents of your ZODB, but that's all. With scarywildunchained PythonMethods in the picture, they now have full access to your system as 'nobody', or whatever you run Zope under. On Windows, at least, this could be effectively root access. This *can* be made secure (I think) by routing all management through an SSL-enabled server and shutting off Zope2's other port access methods, but it's not secure by *default*, which is a concern. The upshot of all this is that I'll probably make unsecure PythonMethods an option, but not through the web-interface. I'll probably make it a switch in the source code, down in a broom closet in the basement with a sign on the door saying "Beware of the Leopard". and-don't-forget-the-toe-gremlins-ly y'rs Evan Simpson