Christian Theune wrote:
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
This is only a problem if username === user id. In both Zope 2 and
Zope 3, these are distinct, although this isn't widely recognized or
leveraged in Zope 2. I don't think it is necessary to remove all
grants to an old user *id* as long as ids are never reused. I'd say it
might even be useful to keep the old grants, at least for some period,
for auditing purposed.
If we *do* need to be able to remove all grants for a deleted user
when we remove a user, then we need to provide an authorization system
that makes this possible.
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?
It would. The Undo feature should not be included in the CC certified
version, or, perhaps undo should only be exposed to adminstrators as
a "break glass" sort of feature. The reason is that, for current
versions of ZODB, undo cannot maintain transactional integrity.
- 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)
Otherwise this function is likely to become a performance killer, as
I'd have to go all over the place to remove stuff.
By definition, there is no efficient way to iterate over all objects
in a database, any database, unless the database is small. If we
need to be able to do this, we should design support into the
authorization system that we certify.
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list