> 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
> > 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.
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.
> Zope-Dev maillist - Zope-Dev@zope.org
> ** No cross posts or HTML encoding! ** (Related lists -
> http://mail.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -