At 03:13 PM 5/16/00 -0400, Tres Seaver wrote:
Nope, because objects owned by 'nobody' would be almost useless -- the intersection of nobody's permissions with any other users' is an empty set.
After reviewing the 2.2 code today, Ty and I have found some problems with the current terminology, API, and implementation of the new security system. Here is the short summary of what we found/propose: 1. The "owner" concept is extremely confusing to talk about, explain, etc. We propose a terminology change to "responsible user", and to "taking responsibility" for an object instead of "taking ownership" of an object. We further propose that all API's and attributes be renamed to reflect this terminology rather than "owner". (One benefit is that "take responsibility" sounds like something you'd want to be wary of, while "take ownership" sounds too much like something *good*.) 2. The current implementation/usage of "manage_fixupOwnership" seems broken to us, in that moving, renaming, and importing objects causes the current user to silently take responsibility for an entire object subtree. We think this is unequivocally broken with respect to renaming, and there are common use cases for which the current moving and importing behavior would have to be considered broken. We propose that only copying and adding should involve an implicit "take responsibility" action. 3. The ability of the superuser to be responsible for objects should be acquirable in some fashion, so that objects such as LoginManager and GenericUserSource (which require objects to be created inside them for bootstrapping) can permit "standard" Zope objects to be created within them by the superuser. Currently, this would have to be done by overriding _setObject in these classes such that it doesn't call manage_fixupOwnership. 4. The SecurityManager API and ZopeSecurityPolicy have a shared design flaw that could seriously impact performance when used with user objects which are not part of the ZODB. Specifically, ZSP asks executing objects for their "owner" objects, which causes a getUserById() hit, which can potentially cause external database lookups... for every single DTML name lookup! Further complicating things is that GenericUserSource and GenericUserFolder may call back to this very same security lookup in order to determine access to an SQLMethod or LDAPMethod needed to look up the user! We propose a refinement to the addContext/removeContext that allows the "responsible user" to be placed on the context stack, rather than having it looked up later by the security policy. This could still have a significant performance impact when calling DTML methods in an "in" loop, but would still be better than the current situation in all but pathological cases.