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
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
