"Phillip J. Eby" wrote:
(snip)
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*.)
I'm not going to play in a naming argument. I'll leave that to Brian and others. I'd be happy to call it penguin. (Dang, that names taken ....)
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.
I can agree wrt naming. I don't agree wrt import. Import is equivalent to copy. Moving is close enough, IMO.
3. The ability of the superuser to be responsible for objects should be acquirable in some fashion,
superuser can never be responsible, however, the same effect is had by making an object unowned.
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.
Why *must* this be done by the superuser?
Currently, this would have to be done by overriding _setObject in these classes such that it doesn't call manage_fixupOwnership.
If you need to assure that all objects under some object are unowned, then that can be arranged. (Hint, grep for "UnownableOwner" in the sources.)
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.
I can live with this. Could you make a proposal in the Wiki? Alternatively (or in addition), we could automagically cache this information in the context. Note that part of the rational of the SecurityPolicy api was to provide *you* the hooks you needed to choose a different policy. For example, the API would allow you to turn off the ownership checks for an entire site or for specific executable objects. The API turned out to be a huge improvement for other reasons. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.