On Thu, 2003-03-27 at 04:27, jamesd@mena.org.au wrote:
Having to create a new Manager and Reviewer role for each of the portals I host and setting it up to work correctly (considering checking for the role 'Manager' is hard coded in many places) would be an enormous task, so this is not feasable.
That's unfortunate, since it's the only reliably secure way of setting up multi-user, multi-host services. The recommendation about restricting the display of folder contents is still pretty high value and can probably be done painlessly. Cross-site scripting exploits are far harder to perform once Zope stops giving away detailed information on what stuff is available where. It's not a complete fix, but it's a huge step in the right direction.
Considering the exploit does not affect folders (going to plone2/portals/manage_main does not work, while plone2/plone1/manage_main does, where 'portals' is a folder)
It would appear that you have restricted access to the portals folder. That's a good thing. But it has nothing to do with whether the attacked object is a folder or not. It is possible to call *any* method of plone1 on *any* object of plone2 or its parents. The degree to which such an attempt works is dependent on little more than how roles are configured. is there a way to force the permissions
to be inherited from 'container' and not 'context'?
That's already how it works. The problem you have is that the roles for both these sites are defined in the *same* container. Unless you define roles/users a bit deeper in the tree, how can Zope possibly know where/how roles ought to be partitioned? I can appreciate the effort that is probably involved in retrofitting sites with hard-coded roles... but if security is important to you, your best bet is to combine Zope's excellent security framework with general best practices in designing and implementing security schemes. HTH, Dylan