<br><br><div class="gmail_quote">On Tue, Jun 10, 2008 at 10:06 AM, Roger Ineichen <dev@projekt01.ch> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi<br>
<br>
> Betreff: Re: [Zope-dev] permission inheritance from conflicting groups<br>
<div><div></div><div class="Wj3C7c">><br>
> On Jun 9, 2008, at 9:38 PM, Daniel Blackburn wrote:<br>
><br>
> > It seems that there either may be an issue with Zope<br>
> security or I do<br>
> > not understand it properly. Please let me know what you guys think.<br>
><br>
> It seems you misunderstood it.<br>
><br>
> > Lets say we have a principal with no direct permissions or roles<br>
> > assigned to see a view index.html. The principal has two groups,<br>
> > group1 and group2. group1 allows the principal to see index.html and<br>
> > group2 denys access to index.html. It seems to me that in this<br>
> > situation of conflicting permissions a deny permission<br>
> should result<br>
> > for the principal to the index view. However it does not, the<br>
> > permission will be digested into allowing the principal to<br>
> have access<br>
> > to the view. Is this the desired behavior, or just simply<br>
> overlooked.<br>
> > I looked in the doctests and did not see anything like this. Any<br>
> > feedback would be appreciated.<br>
><br>
> Here's a scenario from the real world.<br>
><br>
> You start working in a company. The security team puts you<br>
> in a group of regular employees so that when you swipe you<br>
> card at the card readers in front of each door you are<br>
> allowed to rooms A, B, and C, but explicitly denied access to<br>
> rooms D, E, and F.<br>
><br>
> After a while you are promoted to a special team. The<br>
> security team adds you to that group. Now when you swipe<br>
> your card at the door D, the computer checks the following.<br>
><br>
> - Read your employee ID from the card.<br>
> - Get the groups that employee ID belongs to.<br>
> - Regular employee group<br>
> - Cannot access door D<br>
> - Special team group<br>
> - Can access door D<br>
> - Employee ID belongs to at least one group that can access this door.<br>
> - Open the door.<br>
><br>
> The door F will be open only to a member of the security team (group).<br>
><br>
> This is equivalent to the old times when they give you a key<br>
> when you start working. That key does not let you in all rooms.<br>
> After a while, you are promoted, which really means that you<br>
> are in a special group. They give you another key. That one<br>
> lets you in one more room.<br>
><br>
> Can you access that room?<br>
> Not with the first key.<br>
> How about the second?<br>
<br>
</div></div>I think this way too and can agree and yes, the zope<br>
securitpolicy acts this way by default.<br>
<br>
but...<br>
You can implement a custom securitypolicy which takes more<br>
care on deny settings. I think it's also valid for high secure<br>
systems that a deny is allways a deny. This means if you will get<br>
any deny from somewhere you will not be allowd to access it.<br>
<br>
The default policy makes it real hard to find out if some bad settings<br>
give access to the wrong users. But since we have the great security<br>
tool from Daniel it's no problem anymore to find out what's configured.<br>
<br>
Regards<br>
<font color="#888888">Roger Ineichen</font></blockquote><div><br><br> Thanks guys,<br> <br> I just wanted some clarification for the security tool as I was running<br> through these edge cases with the demo. I am more of a default deny <br>
person myself as well. Thanks for the compliment Roger it nice to see <br> someone using it. I have been procrastinating the Beta release but I think<br> I will bite the bullet this week.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<font color="#888888"><br>
</font><div><div></div><div class="Wj3C7c"> _______________________________________________<br>
> Zope-Dev maillist - <a href="mailto:Zope-Dev@zope.org">Zope-Dev@zope.org</a><br>
> <a href="http://mail.zope.org/mailman/listinfo/zope-dev" target="_blank">http://mail.zope.org/mailman/listinfo/zope-dev</a><br>
> ** No cross posts or HTML encoding! ** (Related lists -<br>
> <a href="http://mail.zope.org/mailman/listinfo/zope-announce" target="_blank">http://mail.zope.org/mailman/listinfo/zope-announce</a><br>
> <a href="http://mail.zope.org/mailman/listinfo/zope" target="_blank">http://mail.zope.org/mailman/listinfo/zope</a> )<br>
><br>
<br>
_______________________________________________<br>
Zope-Dev maillist - <a href="mailto:Zope-Dev@zope.org">Zope-Dev@zope.org</a><br>
<a href="http://mail.zope.org/mailman/listinfo/zope-dev" target="_blank">http://mail.zope.org/mailman/listinfo/zope-dev</a><br>
** No cross posts or HTML encoding! **<br>
(Related lists -<br>
<a href="http://mail.zope.org/mailman/listinfo/zope-announce" target="_blank">http://mail.zope.org/mailman/listinfo/zope-announce</a><br>
<a href="http://mail.zope.org/mailman/listinfo/zope" target="_blank">http://mail.zope.org/mailman/listinfo/zope</a> )<br>
</div></div></blockquote></div><br>