[Zope-dev] Request For Comments: SecurityJihad

Michael R. Bernstein webmaven@lvcm.com
13 Aug 2001 20:15:11 -0700


On 13 Aug 2001 22:57:28 -0400, marc lindahl wrote:
> 
> 
> > From: "Michael R. Bernstein" <webmaven@lvcm.com>
> >
> > So I'm asking the product authors on the list if that breakage is
> > acceptable, provided they can re-activate the "magic" by doing:
> > 
> > security.useMagicMethodNames("yes")
> > security.docstringsMakeObjectsPublishable("yes")
> 
> I liked the idea of having some new replacement classes to Item &
> SimpleItem, where you could just change the inheritance to unbreak your
> product... then you could depreciate Item & Simpleitem, and put that stuff
> in those?  Then nothing would break...  eventually you could delete Item &
> SimpleItem to cause breakage, after a suitable crossover period?

If an existing product inherited from Item or SimpleItem *and* used
declarative security, then switching to the new base classes wouldn't be
enough.

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").

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.

Michael Bernstein.