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:[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 [email protected] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
