Andy Dustman wrote:
On Thu, 16 Sep 1999 davidbro@namshub.org wrote:
I can see it... I think he's right.
Perhaps this is a general Zope problem. He got the index_html through aquisition, and it editted it in place.
More of a "Management Interface" problem...
Perhaps it should work like NewtonScript -- you could get to object attributes in a similar way, but if you changed them, it stored the changed attribute in the local object, rather than in the inheritted object.
Like this: ObjectA has attribute A, and ObjectB inherits from ObjectA. You can evaluate an expression like "ObjectB.A" and it would fetch the value from ObjectA. But if you chaged the value, like "ObjectB.A = foo", that created an attribute A in ObjectB. Copy on write, so to speak.
Yeah, I was hoping it worked that way. Hopefully this is just a problem with the Zope web site and not Zope itself.
I asked about the security of the site the other day (privately), response was: :Security is a difficult thing to do right. <snip> looks like a security HowTo/Manual should address this interface bug and many other security design issues.
From my own understanding (I'm no guru yet), it would be far safer to restrict anyone risky from accessing Management Interfaces and re-build your own interfaces that behave the way you write them. (Like the above, verify an object where you our, if its in PARENTS create a local object, and then write to the local one...). Sense I planned on doing this already, this bug doesn't mean much to me (except re-inforcing the idea and pointing out acquisition, thanks ;). The use of proxy security roles on the interface methods is almost a must for my own plans.
I haven't seen a true "security" problem yet, but it looks easy to give the wrong access away and not know what someone can do with it. This "design bug" shows acquisition has to be taken into account when creating Management Interfaces, for sure. David, tone
-- andy dustman | programmer/analyst | comstar.net, inc. telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce
For developer-specific issues, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )