Chris Withers wrote:

...

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.

Do a search for "Confused Deputy", and you'll find lots on this sort of problem. In particular around http://www.eros-os.org/ and http://www.erights.org/ - both capability-based systems. The crunch of this is that you either need a fully-fledged capabilities system, which would have to be insanely granular in this example (caps assigned to each edit of each page), or you want to execute the zwiki page content at the lowest possible access priviledge (the problem seems to be that "execute" is more akin to "render" in the zope world). Changing ownership of the zwiki pages seems a dangerous thing to do in itself - and how do you know not to change it back? You never ever want to run/ render it as a higher user than the lowest priviledge editor... Can I suggest that zwiki pages with DTML content are inherently evil? ;) KevinL (Disclaimer: I haven't looked closely at the zope security model yet :(

Steve Alexander wrote:

...

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.

However... the zope security system could help with this. Here's an ill thought out idea for your consideration :-)

Have a function that takes two sets of permissions, and returns the intersection of these sets. Then, use some sort of local permissions combination to make the wiki page that's been edited have the resultant lowest-common-denominator permissions, even for the owner.

Great minds certainly do think alike. :-) That's the way the security model works now. Jim gets the credit. If a manager comes along and executes something created by another user, it is executed with the permissions consisting of the intersection of the permissions of the manager and the user. So the "DEE()" example would not work *if the ownership is changed upon editing the page*. That's the key: it is my understanding that all Zope products that can potentially execute code need to be updated to change their ownership upon editing. I don't know how much has been corrected. Note that proxy roles still work as before with one difference: they can also be used to *reduce* the permissions in effect.

Make this kind of thing a standard feature of the security system, and write some guidelines to help out authors of products that allow editing content that is also executable.

Yes, there needs to be more documentation on this point. What needs to be edited, if it doesn't mention it already, is Brian's new security guide for product authors. However, there's a good chance it already covers this. Shane

KevinL wrote:

...

Steve Alexander wrote: However... the zope security system could help with this. Here's an ill thought out idea for your consideration :-)

Have a function that takes two sets of permissions, and returns the intersection of these sets. Then, use some sort of local permissions combination to make the wiki page that's been edited have the resultant lowest-common-denominator permissions, even for the owner.

Correct me if I'm wrong, but wouldn't this have the same problem? Person of high access makes zwiki, person of low access adds evil function to it, person of high access views it - unless you're tracking "smallest set of privileges held by anyone editing this page" at all times, you're going to intersect owner with creator and still allow editor to trojan.

Yes, the idea would be to track the smallest set of privileges held by anyone editing this page. You take the intersection of the page's current permissions and the currently-editing user's permissions. Another simpler solution is to make all the pages unowned, make new pages unowned, and make them remain unowned even when edited. However, that may not be a general solution as it is more restrictive that it may need to be. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net

Itamar Shtull-Trauring wrote:

...

Another simpler solution is to make all the pages unowned, make new pages unowned, and make them remain unowned even when edited.

I think "unowned" in 2.2 is the like the 2.1 behaviour - executes at the privilige level of the viewer.

:( I'd prefer it to be like the Unix 'nobody' but maybe this was needed for backward compatability? cheers, Chris