I distinguish three levels of possible security failures, here: 1) Denial of service: Consumption of excessive CPU, memory, disk space, etc. 2) Improper object access: Bypassing permission/role security on ZODB contents. 3) OS-level access: Executing arbitrary code on the server. For reasons I don't want to broadcast on a public mailing list, I'm not worrying too hard about #1, yet. Number 2 and *especially* #3 are showstoppers, though. If PythonMethods break security in either of those ways, they shouldn't be used except by people willing to assume that level of risk. If they break security without people *knowing* that there's a risk, that's unacceptable. That said, note that the import question is not PythonMethod-specific. Scarywildunchained PythonMethods are inherently a huge security hole, and I advertise that fact. Standard PythonMethods don't allow generalized import, so the issue there *should* be identical to the issue with DTML, namely, what can you safely bring into the namespace through External Methods. Robin Becker wrote:
Ok I see we're getting more deeply into what can be imported and what can't. How can you snoop into another thread? As I understand it at present the PMs can only access their locals. If I can get access to any form of peek/poke I can certainly do nasty things. But can I do this with the re module? The sys module is certainly dangerous as is the thread module since it might allow us to use up all the threads. Since denial of service is possible with looping constructs any form of non resource limited thing is insecure. I'm fairly sure individual threads in Python aren't resource limited and unless Zope contains some kind of watchdog simple PMs are insecure. Importing re might make them more insecure by using up resources more rapidly (I believe certain regexps are very cpu intensive), but I don't think they change the quality of the insecurity.