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. Thanks
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"
On Tue, Jun 10, 2008 at 9:34 AM, Stephan Richter < srichter@cosmos.phy.tufts.edu> 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.
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?
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 _______________________________________________
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 )
On Tue, Jun 10, 2008 at 10:06 AM, Roger Ineichen <dev@projekt01.ch> 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 )
participants (4)
-
Daniel Blackburn -
Roger Ineichen -
Stephan Richter -
Zvezdan Petkovic