Re: [Zope] The Ascetic Superuser
ethan mindlace fremen writes: Now every object excecutes according to the permision of the owner, *not* the viewer. It can also run as a proxy role. The super-bootstrap-user lives outside of "normal" zope authentication has permission to do anything save that which NotEvenGodShouldDo. Therefore, it shouldn't own objects. Am I really expected to understand this "Therefore"? In fact, I do not! Does it mean, that a Superuser can execute any method with *ITS* privileges and not the intersection of its priviledges with the owners privileges? I hope (and expect) not! Why is it much worse when an object is owned by Superuser than by a manager? What are the differences with respect to the Trojan Horse or other security issues? Dieter ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[Zope] The Ascetic Superuser
Chris Withers wrote: Well, okay, let me rephrase the question: Why is it bad for the bootstrap user to own anything? It used to be considered okay before Zope 2.2, so was has been changed/discovered that makes this now such a bad idea that despite loads of newbie pain and confusion, it's still worth while/necessary? Objects used to execute according to the permissions of the AUTHENTICATED_USER or the proxy role. "Ownership" only applied (for execution purposes) if you explicitly set the proxy role to "Owner". This was a Very Bad Thing (tm) because once you authenticated as superuser you could view a random HTML page on the web/in your inbox that had a little javascript thingy that went and wiped out your entire site or insert maliciousness here Now every object excecutes according to the permision of the owner, *not* the viewer. It can also run as a proxy role. The super-bootstrap-user lives outside of "normal" zope authentication has permission to do anything save that which NotEvenGodShouldDo. Therefore, it shouldn't own objects. This is *quite* important, and needs to stay. I don't know how to emphasize enough that this is a well thought out correction to an extremely deadly class of security problems that still (afaik) plagues many "other" through-the-web management systems. The newbie pain, however, could probably be mitigated- don't call it a Super user, since it hardly deserves the S or the cape. Have a user in the default install. Something like that. Patches accepted. -- ethan mindlace fremen Zopatista Community Liason Abnegate I! ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] The Ascetic Superuser
On Tue, 5 Sep 2000, ethan mindlace fremen wrote: Now every object excecutes according to the permision of the owner, *not* the viewer. It can also run as a proxy role. The super-bootstrap-user lives outside of "normal" zope authentication has permission to do anything save that which NotEvenGodShouldDo. Therefore, it shouldn't own objects. Methods actually now execute with the effective intersection of the permissions granted to the AUTHENTICATED_USER and the permissions granted to the method's owner. If a proxy role is specified, the method executes with permissions restricted to those roles assigned by the proxy role. This is unarguably a good thing. What's not entirely clear is *why* super can't own, which is a separate issue. The power it has beyond that of a normal management user is the ability to traverse the site unrestricted by the security machinery. I actually don't think there's an answer to this question that has to do with method execution. I think the ultimate answer is one or a few of the following: "because," "shrug," "for audit trail purposes," or "so you don't shoot yourself in the foot," or "be quiet." :-) Alternately, the answer might lie in an unobvious implementation detail that none of us really want to think about. This is *quite* important, and needs to stay. I don't know how to emphasize enough that this is a well thought out correction to an extremely deadly class of security problems that still (afaik) plagues many "other" through-the-web management systems. I just can't think of any situations where having a method execute with the effective intersection of the permissions granted to superuser and the permissions granted to another user would cause more damage than a method executing with the effective intersection of the permissions granted to a normal management user and another user. Can you? The newbie pain, however, could probably be mitigated- don't call it a Super user, since it hardly deserves the S or the cape. Have a user in the default install. Something like that. I agree. This should happen soon. Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
