On Tue, Jun 10, 2008 at 10:06 AM, Roger Ineichen <[EMAIL PROTECTED]> wrote:
> > 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.
> 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.
> Roger Ineichen
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
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
> ** 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 -