[Zope-dev] Re: Superuser ownership (was "Adding LoginManager at the root")

[Jim Fulton]

"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.