[Zope-dev] Help on Zope security needed ...
Oliver Bleutgen
Oliver Bleutgen <myzope@gmx.net>
Fri, 3 Aug 2001 10:08:22 +0200
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