This is really a missing part in Zope3.
> 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.
> 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
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
> 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
Are I'm correct or did I miss something?
> 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