RE: [Zope3-dev] Certification: Supporting Residual InformationProtection in Zope 3
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
RE: [Zope3-dev] Certification: Supporting Residual InformationProtection in Zope 3
Hi, Am Freitag, den 16.12.2005, 11:14 +0100 schrieb Roger Ineichen: 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. That's what my understanding about the current situation was as well. I guess we have to add a generic subscriber for this and cleanup all grant information in the object's annotation. That leads me to the question of local event subscribers ... Do they exist? 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? I mean to make sure that the set of data that can be retrieved by undoing something doesn't make the system inconsistent. Example: - bob still exists. - bob is granted the permission perm.Modify on the object /asdf/b. - b gets deleted. - bob gets deleted, RIP comes in and removes all referenced permission grants - The deletion of /asdf/b gets undone. - The user bob is re-added. This could be handled by making sure that when something is undone, all the security attributes are valid. But I can give you an example that is even worse: - bob exists and is granted perm.Modify an the object /asdf/b - /asdf/b is deleted - bob is deleted and RIP is effective - bob get's readded - The deletion of /asdf/b gets undone. Now. At the point of making the deletion of /asdf/b undone will not be able to know that bob is a different bob then the one that existed before deleting it. :( Looks like we would have to introduce (globally) unique identifiers for users that are non-repeatable. - 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 Nope. I thought about something to use if local event subscribers don't exist. 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? Sounds like you understood my request very well. Regarding the implementation, I might need a small hint about the (sub-)location issues ... 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 signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Certification: Supporting Residual InformationProtection in Zope 3
Roger Ineichen wrote: [Christian] 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. Wouldn't this still be a performance killer? I.e. if a user gets removed in a large site, wouldn't an event need to be sent to all objects that have security annotations in the tree? And at the end, a large transaction, or a lot of transactions, would need to be committed. From my experience with Zope 2, this sounds like a potentially very expensive operation, right? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Certification: Supporting Residual InformationProtection in Zope 3
Am Freitag, den 16.12.2005, 12:52 +0100 schrieb Martijn Faassen: Roger Ineichen wrote: [Christian] 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. Wouldn't this still be a performance killer? I.e. if a user gets removed in a large site, wouldn't an event need to be sent to all objects that have security annotations in the tree? And at the end, a large transaction, or a lot of transactions, would need to be committed. From my experience with Zope 2, this sounds like a potentially very expensive operation, right? Right. -- 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 signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Certification: Supporting Residual InformationProtection in Zope 3
Christian Theune wrote: ... I guess we have to add a generic subscriber for this and cleanup all grant information in the object's annotation. That leads me to the question of local event subscribers ... Do they exist? No. I don't see why you need them here. You don't need a local subscriber to provide a local effect. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
