Chris Withers wrote:
Hi,
This comes from a chat on #zope and some worries I've had since the server side issue was raised.
Unless I'm mistaken, the new security model doesn't solve the issue because ownership isn't changed by editing.
Lets take the example of a ZWiki page which executes any DTML in its contents when it is rendered. Jim in a Manager Paul is a Manager DrEvil has the ability to edit ZWiki Pages, but not call the DEE (Delete Everything, Everywhere ;-) Method
So, Jim comes along an creates a ZWiki Page describing the new security model.
DrEvil comes along, edits the page and plants a <dtml-call "DEE(backup='no')"> in the page. He can't view this page since, as I understand it, code is executed with the lower of the owner and the viewer's permissions.
Paul comes along to read the new ZWiki page, and IIUC, inadvertently executes DEE and deletes everything, everywhere, because he is a manager, and Jim (still the owner) is a manager and so DEE executes.
Have I missed something?
When I write a product that allows users to edit executable content, I have an extra responsibility to collaborate with the new security model. I reckon that it is up to the ZWiki product to change ownership appropriately if the page is edited. The zope security system can't possibly know about what constitutes editing executable content and what does not. Only a product author can know that. As a general princliple, executable content should never be editable by users with lower permissions than the owner of the content. This is the same principle system administrators use on a Unix system to know never to have a root-owned file that is executable by root, and also writable by others. The problem with applying this principle in Zope is that the roles and permissions system is very expressive, and it is complex to know when one user has lower permissions than another. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net