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

[Phillip J. Eby]

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.