While the baroqueness of local roles, ownership, permissions, etc. hasn't changed much, the API for asserting permissions on methods within a Product has changed radically since Zope 2.3. It's much simpler now to "spell" security within a Product. For more info, see http://www.zope.org/Documentation/ZDG/Security.dtml (preview of Zope developer's guide). If __ac_permissions__ and __allow_access_to_unprotected_subobjects__ is the basis for the kvetch, it's no longer necessary to spell these things this way. - C
Apart from that, I think Zope's security model needs to be reviewed. As I'm currently churning out 100-hour workweeks, I haven't really spent much thought on how it could be improved, but somehow this whole proliferation of roles, coupled with extremely low "visibility" of who can do what, doesn't feel right. One of the reasons that I want to split off business code in a separate appserver is that I can "escape" the Zope security model. At the moment, I publish database records through a Python product that applies Zope security to them (e.g. the owner_id of a row gets the Owner role of the object that's published through Zope), and I must say that - apart from the work to get it to work - it doesn't give me a good feeling. Security must be simple, and the baroqueness of owners, local roles, permissions, and whatnot doesn't really support that goal.