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

[Christian Theune]

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 - ct at gocept.com - phone +49 3496 30 99 112 -
fax +49 3496 30 99 118 - zope and plone consulting and development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20051216/7f36fc77/attachment-0001.bin