[Zope-dev] Re: Improvements for Zope2's security

[Philipp von Weitershausen]

Hey Christian, welcome back! :)

Christian Heimes wrote:
> Lennart Regebro schrieb:
>> You have many good points in your list of troubles. Many of them are
>> resolved by using security declarations through ZCML instead. It would
>> be interesting to here your views on this.
> 
> In general I preferre old and well tested security code over new
> security related code. Martjin, Phillip and all the other people are
> doing a great job with Five but well ... it's new code. New code tends
> to break because it is not as well tested as old code.

There isn't much new in terms of security regarding what ZCML does in Five.

> Here is a list of my views and concerns about ZCML and Five security.
> Some or all of my points might be wrong.

This is hazardous. We're about to spend serious time on discussions that 
may be pointless due to the lack of proper research...

> * ZCML security declarations are great for Zope3 and Five classes
> because their default security policy is DENY unless explictly allowed.

ZCML does NOT change the security policy of Zope 2. ZCML is just an 
*spelling* of security declarations. So, it's not much new code at all.

> [NYV] The default object security of ClassSecurityInfo is
> declareObjectPrivate. [NYV]

Where? In Five or in Zope 2? And what's the point?

> * But if you mix in subclasses of SimpleItem and others (Image, File and
> many more) you ar gaining their default security setting
> declareObjectPublic or declareObjectProtected(View)! It means that every
> method is availableunless explictly restricted.

That's Zope 2 for you.

> This could lead to security breaches. IMO it is easier to find an
> unprotected method by reading code when the security declaration sits
> next to the method. A checker method for unit tests could be useful.

Yup.

> * Comments like <!--deny attributes="baz" /--> <!-- XXX not yet
> supported --> are adding a bad gut feeling ...

<deny /> is soemthing that's not in Zope 3 and I don't know what Sidnei 
(who did the ZCML-Zope2-security integration) intended there. It's 
certainly nothing that poses a security threat. We don't operate on bad 
gut feelings. If you see definite problems with Five code, I'll be happy 
to discuss them.

> * As far as I understand the security system Zope2's can't protect
> attributes and descriptors (properties) with
> security.declarePrivate('attributename'). The default object permission
> always wins. A ZCML directive that protects an attribute or descriptor
> can lead to false security assumptions. [NYV]

Again, ZCML is just a different spelling of security.declare*, but one 
that can help you avoid typo problems (e.g. when you use interfaces). It 
cannot solve deeply rooted problems of Zope 2's security machienry and 
the confusion it may create. Developers using security.declarePrivate 
may just as well be misled as someone using ZCML.

> * A long time ago somebody has told me that Zope2's security works only
> for objects that subclass from ExtensionClass.Base or an Acquisition
> class. Is this still true or is it a false information?

At least currently the Zope 2 security policy needs an acquisition 
context because it aq_acquires __roles__. I have some work in a local 
sandbox that will make the dependency on Acquisition-based classes go away.

Philipp