Vangelis Mihalopoulos <mihalop@VTrip.NET> writes:
Well, i agree with you. But, still, using suid python scripts for half of my app is a problem... believe me, it will be much easier for someone to find a security flaw in my app than is Zope... :)
That's key, though. Your application is going to be a less attractive target for attacks than zope to the degree that it is a less prevalent application than zope. This doesn't mean that you shouldn't be careful to make your application secure - but it does mean that you have a lot more lattitude than zope, the application, to provide for your special local-host security concerns. Someone later in the thread suggested separating the code that needs to run as root as a separate service. I think that's heading in the right direction. You don't have to get very fancy to convey things between the separate processes, and you can arrange things so that it takes local-host access to deliver things to the root processing. If you can wait for batch processing, you could have an arrangement where the root processes run periodically (down to every minute) from cron, to look for files in a particular directory for handling. The zope side would just situate the files. You could restrict the file processing dir to the userid of the zope process, to regulate local access. The processor could even use http, xmlrpc, webdav, ZEO, etc to call back into zope to deliver the results of the processing. If you need more immediate call/response, you could have a long running process listening and talking on unix domain pipes. (Despite the name, i think windows systems have those, as well.) It isn't trivial to interact with interacting with pipes (you'll get acquainted with select, read buffering policies, etc), but it's valuable knowledge that serves you in ways beyond the specific problem. The essential principle, here, is that you want to make as narrow as you possibly can the ways which root processing is exposed across the network. Most network daemons that run as root have years of testing and many thousands of eyes - and still, holes are discovered and exploited daily. Zope tries to minimize that kind of exposure by refusing to run as root in the first place - it makes for a more manageable problem when abusive access is discovered. Ken Manheimer klm@zope.com