Hi Joachim,
No, it shouldn't. Am starting to think that the Zope security model implementation is a bit "strange".
So, actually I thought that _my_ brain is going wrong here, but if it isn't, this is IMO a very serious bug. I just couldn't believe that something serious like that could have gone through up to zope 2.3.3 without anybody noticing, when it is indeed not wanted behaviour.
What I'd need in practice is a security model that
a) is completely predictable (that's what http://dev.zope.org/Wikis/DevSite/Proposals/SecurityJihad is working on) b) would normally make sure that somebody in a subfolder can not get access to anything that is explicitly protected in the parent folder
I would think not follwing a) and esp. b), the software has a bug, or the documentation. I for one can't find anything in http://www.zope.org/Members/michel/ZB/Security.dtml which would warn about the above described behaviour.
c) would on the other hand offer the possibility to bind access to a role, regardless where in the folder hierarchy somebody gets the role.
No, I wouldn't like this, I always thought that containment before context should also apply to security.
The problem is with acquisition: If I have an "editButtonsBar" widget in my root directory, I'd like to make it available to ALL Editors, not just to the ones who have editor roles in root.
Do you want to make it available or editable?
On the other hand, if I have a standard header or footer that should not be overriden in a subfolder, this should be possible. This means I'd not only need a permission that can not be bound to roles in the subfolder, but also a mechanism to prevent overriding the object ...
Isn't this a typicial problem for a zclass or product or whatever? Even if I couldn't overide standard_html_header, i.e. create my own methods with that name, I could always change the places where it is called to call my_own_header instead. cheers, oliver