Re: [Zope-dev] permission inheritance from conflicting groups
On Jun 9, 2008, at 9:38 PM, Daniel Blackburn wrote: It seems that there either may be an issue with Zope security or I do not understand it properly. Please let me know what you guys think. It seems you misunderstood it. Lets say we have a principal with no direct permissions or roles assigned to see a view index.html. The principal has two groups, group1 and group2. group1 allows the principal to see index.html and group2 denys access to index.html. It seems to me that in this situation of conflicting permissions a deny permission should result for the principal to the index view. However it does not, the permission will be digested into allowing the principal to have access to the view. Is this the desired behavior, or just simply overlooked. I looked in the doctests and did not see anything like this. Any feedback would be appreciated. Here's a scenario from the real world. You start working in a company. The security team puts you in a group of regular employees so that when you swipe you card at the card readers in front of each door you are allowed to rooms A, B, and C, but explicitly denied access to rooms D, E, and F. After a while you are promoted to a special team. The security team adds you to that group. Now when you swipe your card at the door D, the computer checks the following. - Read your employee ID from the card. - Get the groups that employee ID belongs to. - Regular employee group - Cannot access door D - Special team group - Can access door D - Employee ID belongs to at least one group that can access this door. - Open the door. The door F will be open only to a member of the security team (group). This is equivalent to the old times when they give you a key when you start working. That key does not let you in all rooms. After a while, you are promoted, which really means that you are in a special group. They give you another key. That one lets you in one more room. Can you access that room? Not with the first key. How about the second? ___ 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 )
Re: [Zope-dev] permission inheritance from conflicting groups
On Tue, Jun 10, 2008 at 10:06 AM, Roger Ineichen [EMAIL PROTECTED] wrote: Hi Betreff: Re: [Zope-dev] permission inheritance from conflicting groups On Jun 9, 2008, at 9:38 PM, Daniel Blackburn wrote: It seems that there either may be an issue with Zope security or I do not understand it properly. Please let me know what you guys think. It seems you misunderstood it. Lets say we have a principal with no direct permissions or roles assigned to see a view index.html. The principal has two groups, group1 and group2. group1 allows the principal to see index.html and group2 denys access to index.html. It seems to me that in this situation of conflicting permissions a deny permission should result for the principal to the index view. However it does not, the permission will be digested into allowing the principal to have access to the view. Is this the desired behavior, or just simply overlooked. I looked in the doctests and did not see anything like this. Any feedback would be appreciated. Here's a scenario from the real world. You start working in a company. The security team puts you in a group of regular employees so that when you swipe you card at the card readers in front of each door you are allowed to rooms A, B, and C, but explicitly denied access to rooms D, E, and F. After a while you are promoted to a special team. The security team adds you to that group. Now when you swipe your card at the door D, the computer checks the following. - Read your employee ID from the card. - Get the groups that employee ID belongs to. - Regular employee group - Cannot access door D - Special team group - Can access door D - Employee ID belongs to at least one group that can access this door. - Open the door. The door F will be open only to a member of the security team (group). This is equivalent to the old times when they give you a key when you start working. That key does not let you in all rooms. After a while, you are promoted, which really means that you are in a special group. They give you another key. That one lets you in one more room. Can you access that room? Not with the first key. How about the second? I think this way too and can agree and yes, the zope securitpolicy acts this way by default. but... You can implement a custom securitypolicy which takes more care on deny settings. I think it's also valid for high secure systems that a deny is allways a deny. This means if you will get any deny from somewhere you will not be allowd to access it. The default policy makes it real hard to find out if some bad settings give access to the wrong users. But since we have the great security tool from Daniel it's no problem anymore to find out what's configured. Regards Roger Ineichen Thanks guys, I just wanted some clarification for the security tool as I was running through these edge cases with the demo. I am more of a default deny person myself as well. Thanks for the compliment Roger it nice to see someone using it. I have been procrastinating the Beta release but I think I will bite the bullet this week. ___ 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 ) ___ 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 ) ___ 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 )
Re: [Zope-dev] permission inheritance from conflicting groups
On Monday 09 June 2008, Daniel Blackburn wrote: It seems that there either may be an issue with Zope security or I do not understand it properly. Please let me know what you guys think. Lets say we have a principal with no direct permissions or roles assigned to see a view index.html. The principal has two groups, group1 and group2. group1 allows the principal to see index.html and group2 denys access to index.html. It seems to me that in this situation of conflicting permissions a deny permission should result for the principal to the index view. However it does not, the permission will be digested into allowing the principal to have access to the view. Is this the desired behavior, or just simply overlooked. I looked in the doctests and did not see anything like this. Any feedback would be appreciated. I would epxect the order of the groups to matter and simply the setting that is found last wins. This is a third possible behavior that mimics Python's inheritance behavior. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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 )
Re: [Zope-dev] permission inheritance from conflicting groups
On Tue, Jun 10, 2008 at 9:34 AM, Stephan Richter [EMAIL PROTECTED] wrote: On Monday 09 June 2008, Daniel Blackburn wrote: It seems that there either may be an issue with Zope security or I do not understand it properly. Please let me know what you guys think. Lets say we have a principal with no direct permissions or roles assigned to see a view index.html. The principal has two groups, group1 and group2. group1 allows the principal to see index.html and group2 denys access to index.html. It seems to me that in this situation of conflicting permissions a deny permission should result for the principal to the index view. However it does not, the permission will be digested into allowing the principal to have access to the view. Is this the desired behavior, or just simply overlooked. I looked in the doctests and did not see anything like this. Any feedback would be appreciated. I would epxect the order of the groups to matter and simply the setting that is found last wins. This is a third possible behavior that mimics Python's inheritance behavior. The order seems to have no effect on the inheritance, I just ran the tests with two groups and toggled the permissions on each. ___ 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 )
Re: [Zope-dev] permission management behaviour
I try to set the permission to role mapping (which worked with the code snippet I posted, except for the behaviour i described). I just thought the manage_role could be used for this task. I will have a look at the methods used by the ZMI. thanks Stefan Zitat von Dieter Maurer [EMAIL PROTECTED]: bTurtle ZOpe wrote at 2004-11-30 16:37 +0100: ... Can someone explain why this is so? or what I am doing wrong. I did not understand what you are trying to achieve. Do you want to: * determine the protection of methods by permissions? You would use ClassSecurityInfo and its declareProtected for this. The Zope Developper Guide would tell you the details. * set the permission to role mapping? Look how the ZMI does it. The relevant methods are in AccessControl.Role. * something else? -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Permission Question
Andre Schubert writes: i have i question on the permission-system of zope. Lets say i have a product which contains a zclass foo and i have created a role foo_role where every user belonges to this role is able to add foo instances. This works fine. But how do i define my permissions so, that all users which belong to foo_role are able to delete foo-instances. I created a zope-permission Delete Foo objects, then i mapped this permission to Delete objects in the zclass foo like the mapping from Add Foos to Create class instances. But this doesnt work. Delete objects is a permission of the container (containing the objects to be deleted) and not the objects themselves. You can make your own object deletion method (script) that applies the permission checks you want (give it a Manager proxy role, such that it is able to actually delete the objects). Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Permission Question
On Mon, 13 May 2002 21:16:24 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: Andre Schubert writes: i have i question on the permission-system of zope. Lets say i have a product which contains a zclass foo and i have created a role foo_role where every user belonges to this role is able to add foo instances. This works fine. But how do i define my permissions so, that all users which belong to foo_role are able to delete foo-instances. I created a zope-permission Delete Foo objects, then i mapped this permission to Delete objects in the zclass foo like the mapping from Add Foos to Create class instances. But this doesnt work. Delete objects is a permission of the container (containing the objects to be deleted) and not the objects themselves. You can make your own object deletion method (script) that applies the permission checks you want (give it a Manager proxy role, such that it is able to actually delete the objects). Dieter Thanks for your help, i will try to implement such a method. Regards.. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Permission problems
morten writes: I've been struggling with some permission problems, and I'd appreciate some help... Maybe, you take a look at URL:http://www.dieter.handshake.de/pyprojects/zope/book/chap3.html Perhaps, its security section make some aspects clearer. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Permission
Tom Deprez wrote: Thanks Jim, for answering my q'n. In order to change a permission for a certain role, we have to check or uncheck this permission at the roles permission checkbox. I don't understand this. You can grant permissions to a role locally, regardless of whether you acquire permission settings. If you don't acquire, then the role only gets the permissions you set, otherwise, it *may* get permissions from above. So, if I understand this correctly : A)Assume I want to remove the View permission from the anonymous role in folder 'private' (just below root-folder). I've to uncheck the view permission for anonymous and also the acquire permission for view (because otherwise anonymous would still have the view permission by acquisition from root) Right. Since acquire permission for view is unchecked, all roles take over the permission set for View at folder 'private' (no acquisition). Only those roles you've checked will have the view permission of acquisition of permission settings is disabled. Assume I had in root a 'RoleA' and permission was set for View. At this moment I have to check the view permission for RoleA. Right. B)Assume I want to give Anonymous the right to 'Add Folders' Then I only have to check the 'Add Folders' permission for Anonymous and the permission will be granted to Anonymous (even, although in the root-folder Anonymous doesn't has the right? Right. Acquisition doesn't takes part, although it is still check for 'Add Folders'?) Yes and no. Since everyone has the anonymous role, Zope won't bother checking containing folders if anonymous is granted access. If above is correct, then I was wrong in my thinking for situation B. But then where stands acquisition for this situation? It is checked for 'Add Folders', so it should get it's permission from 'root' and not from 'private'. You've lost me. If you are saying that granting anonymous a permission makes acquirintg settings for that permission irrelevent, you are right. Now, why couldn't this be implemented like the following? Isn't this easier to grasp? The Acq_perm column doesn't exists. Assume that acquisition of a permission is always Active. The checkboxes of the role show their actual value (according to the acquisition). Thus if permissionA is checked in the parent-object, permissionA is also checked. If you want, for a certain role that this permission is not given, you uncheck permissionA. The subobject will show an unchecked permissionA box (because it acquires from its parent). In order to give the subobject again the permission, we only have to check permissionA. The problem with this is that it doesn't recognize changes made to containers later. I was more talking about another view to the permission roles. Iside Zope you would still need to have the acquire permission boolean. However, this would be attached to every role per container. Instead of one acquire permission column, you would have an acquire permission column for every role per container. This would eliminate the things wich happend with RoleA (see above), because the acquire permission is still checked for RoleA for this container. Off course having a second column of checkboxes (acquire permission) would confuse even more. Therefor the proposition of handling the acquire permission automatically behind the scenes. But perhaps this isn't possible when situation 'B' is possible. Another possibility would be at provide an option to deny access. Then you could deny access to view in example A without affecting RoleA. By acquiring permission settings you are allowing containers to grant a permission to a role today or sometime in the future. This allows someone to control permissions in a centralized fashion. Sorry, I don't understand above sentence. The point is that the acquisition is done dynamically when permissions are checked. Suppose I acquire the permission settings for the "Add Folder" permission. Today, that may mean I acquire the ability for "Owners" to add folders. Tomorrow, someone may also grand "Add Folder" to members. I'll acquire that as well, automatically. Other question: If acquire permission is set for RoleA (in 'private') and RoleA has the 'view permission' in 'Root', then RoleA has the view permission in 'private' (acquisition, not?). You cant set the "acquire permission settings" check box for roles. You can only set it for permissions. If the acquire permissions settings is set for the permission "View" in folder "private" and "RoleA" has the "View" permission in the root, then "RoleA" has the permission setting implicitly in folder "private". However the checkbox at 'view permission' for RoleA is not checked. Because it is not set here. I it possible to put name next to this checkbox which tells that permission to 'view' for RoleA is acquired from 'root', or just a link which brings us
Re: [Zope-dev] Permission
Tom Deprez wrote: Hi, I have this q'n already a long time in my head and I still don't know the answer to it. It has to do with the security-view. I hope that someone can shed a light on my brains. Why is their an Acquire permission (referred to as acq_perm in following text) checkbox column? It allows you to honor permission settings made in containing objects. In order to change a permission for a certain role, we have to check or uncheck this permission at the roles permission checkbox. I don't understand this. You can grant permissions to a role locally, regardless of whether you acquire permission settings. If you don't acquire, then the role only gets the permissions you set, otherwise, it *may* get permissions from above. However, for this to work we have to uncheck the acq_perm column (because if this one is checked, the permission is taken from parent-folder-objects anyway, the value of the role checkbox doesn't counts at that moment). You don't have to ncheck the acq_perm column if you simply want to grant a permission to a role. You only need to uncheck the acq_perm column if you want to prevent containing objects from granting a permission to other roles. As a drawback, this means that all roles have to be checked/unchecked, because they don't acquire the permission anymore from one of its parents-folder-objects. So don't uncheck the acq_perm column. Now, why couldn't this be implemented like the following? Isn't this easier to grasp? The Acq_perm column doesn't exists. Assume that acquisition of a permission is always Active. The checkboxes of the role show their actual value (according to the acquisition). Thus if permissionA is checked in the parent-object, permissionA is also checked. If you want, for a certain role that this permission is not given, you uncheck permissionA. The subobject will show an unchecked permissionA box (because it acquires from its parent). In order to give the subobject again the permission, we only have to check permissionA. The problem with this is that it doesn't recognize changes made to containers later. A) In the first approach we've to uncheck the acq_perm checkbox and have to set the checkbox of every role according to how we want the permission to be handled by that role. You don't need to uncheck the acq_perm checkbox unless you want to prevent containers from granting permissions. B) In the second approach we've to uncheck the permission checkbox of the role(s). Other roles are not effected. Am I missing something here? Is my explenation somewhere wrong? Why does Zope uses the first approach? Which, sounds for me, a little bit more complicated. By acquiring permission settings you are allowing containers to grant a permission to a role today or sometime in the future. This allows someone to control permissions in a centralized fashion. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! Technical Director (888) 344-4332http://www.python.org Digital Creationshttp://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
