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

[Jim Fulton]

Jim Fulton wrote:
...
 > If we
> need to be able to do this, we should design support into the
> authorization system that we certify.

I'll note that this implies that the grants are stored centrally.
There are a number of reasons why this might be beneficial.

It's interesting to note that on Unix systems, it is not too terribly
expensive (though not cheap) to change security information on a large
tree. (I'd guess the same is true on Windows, probably for similar
reasons.) This is because the information is stored in inodes, rather
than in the files themselves.  The actual files don't need to be open
and read.  In our current annotation-based approach, we have to load
an object to get it's grant annotation.

A pet project of mine that I'm dying to work on, but fear I won't have
time for, is to add optional support for managing security information
in ZODB.  A storage that supports object security would maintain extra
information, accessable as additional persistent objects, that maintain
lists of principal grants for each object.  A grant for a principal
for an object would be a triple of boolean values for read, write, and
ownership, where you would need the ownership to change the grants.
Of course, the storage would use this information to mediate access.
The main goal of this would be to make ZEO a much more viable protocol
for client-server applications.

I also think that the flexible permission scheme I introduced to Zope
was a huge mistake.  A security system that people don't understand
is insecure.  A corrolary of this is that complex security systems are
not secure.  I wish I knew more (had time to read literature) about
"usable" security systems.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org