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.

Here is a list of my views and concerns about ZCML and Five security.
Some or all of my points might be wrong. I had only one hour time to
read code and I did no debugging or unit testing of my concerns. (NYV =
not yet verified)

* ZCML security declarations are great for Zope3 and Five classes
because their default security policy is DENY unless explictly allowed.
[NYV] The default object security of ClassSecurityInfo is
declareObjectPrivate. [NYV]

* 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. 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.

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

* 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]
It is possible to protect attributes with different permissons by
hooking into __allow_access_to_unprotected_subobjects__. The class var
can be set to a bool (1 = public, 0 = private), a string (permission
name), a dict (attribute name -> 0/1) or a callable. I have an idea how
to protect descriptors and attributes based on some work from Sidney for

* 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?


Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to