Re: [Zope-dev] Help on Zope security needed ...
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
Hi! I'm feeling that my head could explode sooner or later. But I'll try anyway to sort out that security thing: So what we are building is a content management system (Kontentor) that, unlike the CMF, can have as many "sub-portals" to a portal as you like. We are initially doing this for a university. So there this the main site of the university, with some target-group-specific portals like "studying abroad" or "alumni", and then there are the sites of the faculties (or "schools") (e.g. "School of Business") and institutes, which themselves contain sites for departments (e.g. "Department of International Marketing"). The look&feel ("chrome"/"skins") and basic site layout should be enforced globally. There is a role model with "Editors" and "Reviewers" (a bit simplified, but it will do for the example). People can hold these roles for branches in the tree, e.g. somebody could be Reviewer and Editor for the Marketing Department, but only Editor for the Business School site. In addition, he/she could also be an Editor in a completely unrelated branch, let's say in the Computer Science Department. So these are the security-relevant use case that I have to deal with: 1. An Editor for anything on any branch in the tree should be able to SEE the managementButtonBar on top of the site when logged in 2. An ordinary visitor of the site should NOT SEE the managementButtonBar, not even if he/she calls the object's URL directly 3. On the sites the Editors are responsible for, they should see and be able to use in-site management buttons/icons like "move up" or "delete" for all elements they are authorized to edit (i.e. NOT the basic elements that are pre-configured by their "parent" site, like site-wide menu bars etc.). In terms of actual coding, I do not want to have to check for security, just do things like "<dtml-var managementButtonBar missing>" or try/excepts in Python. If I have to hard-wire things like "if user is Editor then display", I won't be able to change the names of the roles etc. later. Let's say we have a security model that checks like this: "If the current user has a role that is linked to my permission, and he has that role for the container I am in or for one of its parent containers, then grant access!". That's how we all thought the Zope security model should work. So if I am an Editor in the Marketing Department, I can edit all local elements whose "manage_edit" method is bound to a permission "Edit Content Object", which is globally bound to the "Editor" role. Even though I have the Editor role, I can NOT edit objects of the same type in other branches of the tree (e.g. the Computer Science Dep.) or up in the tree (i.e. on the root level of the Business School). Fine. So if everything that seems to be broken in the security model is fixed, number 3. is partly doable. But let's go to the rest of the use cases, and a missing aspect in case 3.: How would I normally do No. 1? I'd bind the "view" permission of the managementButtonBar to the Editor role. That way I can say "<dtml-var managementButtonBar missing>" in the index_html, and voila: an ordinary user would not see the buttons, but my Editor would. Yes, but only if he is an Editor in ROOT (that's where the managementButtonBar DTML Method is at home). If I choose to NOT protect the managementButtonBar directly but to do things like "<dtml-if AUTHENTICATED_USER.has_role('Editor')>", the DTML Method will be callable by anybody directly. This may not be an issue for the management button bar, but it would for more security-relevant methods. The crucial point is: Everything works fine if I can bind my roles to local instances of the Product, e.g. a local "faculty" instance. Then, the Editor is editor for THAT instance. But as soon as I want to use acquisition for some of the display methods, those will not work as needed. So what we seem to need for those is the possibility to say "any Editor on any level in the hierarchy should be able to use this", or as an alternative, "faculties (or whatever other sub-object we have) can acquire this method as their own and make it available to their Editors, but if the object is called directly, it is protected". Probably the only way of doing most of this with the current security model is having myriads of Roles, like "Editor of Business School" or "Reviewer of Computer Science Department", and putting all the users into the ROOT folder. That's rather ugly ... O.k. Have I lost all my readers now? If not, I'd like to hear what you think ... ;-) Joachim
[Joachim Werner] | O.k. Have I lost all my readers now? If not, I'd like to hear what | you think ... ;-) I was in the same situation as you are, and solving it by getRoles and friends is hell. The suggestion you make sounds excellent to me, but I feel I don't have enough experience building those types of application, so I might be wrong. :-)
On Fri, 3 Aug 2001, Joachim Werner wrote:
1. An Editor for anything on any branch in the tree should be able to SEE the managementButtonBar on top of the site when logged in 2. An ordinary visitor of the site should NOT SEE the managementButtonBar, not even if he/she calls the object's URL directly 3. On the sites the Editors are responsible for, they should see and be able to use in-site management buttons/icons like "move up" or "delete" for all elements they are authorized to edit (i.e. NOT the basic elements that are pre-configured by their "parent" site, like site-wide menu bars etc.). [...] managementButtonBar missing>" in the index_html, and voila: an ordinary user would not see the buttons, but my Editor would. Yes, but only if he is an Editor in ROOT (that's where the managementButtonBar DTML Method is at home).
Couldn't you solve this bit by having two roles (naming could be difficult; EditorToolUser and Editor, maybe?), one of which gets the 'view' permission for the global tools, and one of which gets the 'modify' permissions for the editable objects in the subfolders? Of course, you would have to put all users in the root folder in that case; generally I find that more convenient anyway, myself. But I haven't done much with user accounts, really. --RDM
participants (4)
-
Erik Enge -
Joachim Werner -
Oliver Bleutgen -
R. David Murray