[Zope3-dev] Certification: Supporting "Residual InformationProtection" in Zope 3

[Roger Ineichen]

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 - ct at gocept.com - phone +49 3496 30 99 112 -
> fax +49 3496 30 99 118 - zope and plone consulting and development
>