Chris Withers wrote:
> 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
> 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
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.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -