[Zope-dev] Request For Comments: SecurityJihad

Michael R. Bernstein webmaven@lvcm.com
14 Aug 2001 09:26:34 -0700


On 14 Aug 2001 09:32:23 -0600, Casey Duncan wrote:
> "Michael R. Bernstein" wrote:
> > 
> > If your class *depended* on some of the magic behavior such as
> > docstrings making unprotected objects publishable or traversable, then
> > that behavour would break, unless you also added
> > security.docstringsMakeObjectsPublishable("yes").
> 
> Changing that behavior (which admittedly is unintuitive if not worse),
> would break the vast majority of existing products. Why not go the other
> direction and make it so new products must subclass a new base class
> "DamnSecure" or somesuch that the ZPublisher looks for in order to alter
> that behavior (and others gracefully). Products that do not use this
> base class would cause a security warning to be outputted to the console
> and/or logs. 

What I am proposing is that that breakage would only occur if the
product used *both* the Declarative Security Framework (introduced in
Zope 2.3) *and* relied on the "magic" behaviours.

There should be very little overlap between the two categories, and the
'quick-fix' should be available for the exceptions.

I guess I'm trying to draw a 'line in the sand' with declarative
security, and eliminate the fuzzy middle ground.

> I'm not so much concerned about product authors, as I am the poor users
> who would be trying to use old versions of products (and those not yet
> or ever updated from Zope.org). I will guarantee a 1000% increase in
> mailing list traffic of the nature "I upgraded to Zope 2.5 and I'm
> hosed!" if some semblance of backward compatibility (with warnings)
> isn't kept.

I understand. That is a concern for me too, but I think that if only
very recent products that rely on the magic behaviour *and* use
declarative security are broken, and a 'quick-fix' is available to
product authors, then the pain should be minimal, as a minor version
upgrade would be all that's neccessary for those products.

Old products that do not use declarative security should not break.
 
> > In fact, switching to the new base classes would be unneccessary in this
> > case, as mostly what they do is not mess up the 'deny unless allowed'
> > policy, like Item and SimpleItem do.
> > 
> > So, if you switched to the new base classes, you could then eliminate
> > security.setDefaultAccess("deny") from your class, but otherwise there
> > would be no other change.
> 
> I could certainly live with that.
> 
> I certainly think this proposal is a very good one. As you pointed out,
> you have know alot about what specific mix-ins do to security to create
> a secure product. It should take effort to create an insecure product,
> not the other way around.

Thanks! I appreciate the feedback.

Michael Bernstein.