[z3-five] Unexpectedly unprotected code

Paul Winkler pw_lists at slinkp.com
Thu Feb 1 16:41:19 CET 2007


On Wed, Jan 31, 2007 at 08:22:16PM +0000, Chris Withers wrote:
> Paul Winkler wrote:
> >Hmm, was that really a big draw to Zope? 
> 
> When Zope was growing rapidly (1999-2003 for me, others may disagree) 
> everyone who came to Zope came to it by installing it and writing TTW 
> code. That was predicated on what I'm talking about ;-)

Yeah, but nowhere is it written in stone that the security model of
TTW code needs to be different than the security model of filesystem
code.  I'm heretically suggesting that we consider whether this
distinction does more harm than good. For a trivial example, the old
"import re is not allowed" FAQ.  IIRC the motivation for disallowing
re is that regular expressions can be indeterminately slow and a naive
scripter might create code that's an easy DOS target - or a malicious
scripter might do so deliberately.  In that case at least, I'm now
pretty firmly on the side of "give 'em the rope and if they hang
themselves, it's their own problem".

Where this hypothesis obviously falls down is the "multiple customers
(each with their own engineering staff) sharing one Zope"
scenario. Some Zope hosting providers run their low-budget plans this
way. You can't leave customer A a giant back door into customer B's
data. In this case, the default zope 2 security model makes a lot of
sense.

But since as far as I know Zope is the only framework that supports
that hosting model, again I wonder if the complexity is worth it.  If
the only option for hosting multiple customers is to give each its own
instance, things get much simpler. OTOH, being in the Zope hosting
business seems to be difficult enough already without exploding the
number of long-running processes required. I doubt
http://www.objectis.org/about-en/objectis/index_html would have the
resources for the model I'm suggesting.

-- 

Paul Winkler
http://www.slinkp.com


More information about the z3-five mailing list