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
Description: This is a digitally signed message part
_______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com