Hi Christian interesting question! This is really a missing part in Zope3.
> Hi, > > within the certification we once created a list (drawn from the CC > catalogue) of functionality we want to support. > > One of those is called "Residual Information Protection" (RIP) > > The meaning of RIP is that when you delete security attributes (roles, > users, groups, permission grants/denials) you want to make > sure that the > overall consistency of your security attributes is not affected. > > Example: > > Bob is a user of your site with the login name "bob". He > was granted > permissions all over the place, for example in folder > "/asdf" he has > the permission "perm.ModifyObjects". > > Bob doesn't want to work with you anymore and tells you so. You > delete the user account "bob" from the system. > > 2 years later. > > Another Bob arrives and you assign him the same username. > Suddenly he > has all the permissions that the original "bob" had. > > This is a simple example of what can happen when you only partially > delete security attributes. And it is a known problem with > todays Zope 2 > security. Yes, that is excatly what we d right now. If we remova a principal we don't delete the permssion/grant imformation in the annotation. I guess we have to add a generic subscriber for this and cleanup all grant information in the object's annotation. > Two questions arise for me now, as I face implementing the effective > removal of residual data: > > - Does anybody know/understand whether this will heavily collide with > undoing transactions or not? You mean if a principal get added back via the undoing transaction or if there is a meachnism to not allow to undo principal removal? > - Is there an efficient way on the application-level in Zope 3 to > iterate over objects out of the database? (There is something in the > ZODB IIRC that can support iterating over objects of the same class) Do you mean if sombody uses a SQL DB backend or something like that? If so, I guess they have to provide the sublocation implementation as well. I have no idea if this is supported in SQL implementation like the SQLObject etc. > Otherwise this function is likely to become a performance killer, as > I'd have to go all over the place to remove stuff. We do this everytime we delete a object. This is done with subscribers and dispatching events to sublocations if a ObjectRemoveEvent get fired. The only part we have to add is a subscriber which will remove grant information for sublocations. We have to use a little hook for this implementation since the content data structure isn't directly a child of the IAuthentication utility. Hm, perhaps we have to add a special event inherited from ObjectRemoveEvent and dispatch this event to sublocations of the ISite reather then to the sublocations of the IAuthentication. A different event will make sure that we not directly dispatch the original ObjetRemoveEvent to the content objects of ISite. Are I'm correct or did I miss something? Regards Roger Ineichen > Cheers, > Christian > > -- > gocept gmbh & co. kg - schalaunische str. 6 - 06366 koethen - germany > www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - > fax +49 3496 30 99 118 - zope and plone consulting and development > _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com