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

[Phillip J. Eby]

At 05:12 PM 5/16/00 -0400, Jim Fulton wrote:
>"Phillip J. Eby" wrote:
>> 
>> 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. 

Consider the situation of someone with "development" and "production"
sites, exporting from one and importing to the other.  Import is now
"lossy" with respect to responsibility.


>Moving is close enough, IMO.

If I make a copy of something on my desk, I expect it to not be the
original, so although I would expect it to work like the original, I could
understand that I would be responsible for the copy (since I made it).  But
if I move something on my desk to the other side, I don't expect it to
suddenly stop working, unless there is something about where it was that
made it work.  In that case, I would assume that moving it back would fix
it.  But moving it back doesn't fix it, because the objects were actually
changed.  When all you did was move them, changing objects irreversibly
seems just plain *wrong* to me.  I just moved the document: I didn't even
*read* it, let alone modify it or sign off on it!

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

Hm.  Perhaps in the proposed terminology, an "unowned" object could be
called an "irresponsible" object, which seems to have appropriate
connotations.  :)


>> 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?

Because as far as I can tell, until it's done, superuser and nobody are the
only users that exist to do it, if you want a GUF, GUS, or similar object
as your root acl_users.  You can't even make another user in a temporary
user folder, because if you copy the acl_users as superuser, you aren't
allowed because it would give the superuser responsibility.  And if you
delete the root acl_users so that you can then have the "manager" user do
the copy, the manager can no longer log in, because he doesn't exist any
more!  (Incidentally, this is another use case which suggests that moves
causing a responsibility change is wrong, since if they didn't do this, the
superuser could move acl_users to the root, assuming it was movable.)


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

We skimmed alot of the UnownableOwner stuff because it made our brains
ache.  :)  (All the darting back and forth between UnownableOwner vs. None
was confusing.)  Upon re-reading, it seems to me that if one were to set
_owner = UnownableOwner in a class, it would ensure that anything contained
underneath that location would be unable to have ownership assigned to it.
Is that correct?


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

For the specific situation identified, caching in the context would address
the problem.  It still wouldn't fix loops where a DTML method is called
repeatedly as part of a larger page, because the method would be added and
removed from the context stack repeatedly, and thus lose the cached user
information (unless perhaps it's done with a _v_ attribute on the
executable itself).  I'm also thinking that ZPatterns.Rack probably needs a
per-transaction cache (i.e. cleared between transactions) so that repeated
lookups like this within a single transaction can be generally avoided.


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

I can see that, and I do like the idea.  It's only the issues related to
ownership/responsibility that give Ty and I the creeps.  That part really
has no direct relationship to the SecurityManager/SecurityPolicy type
stuff, which could probably be usefully packaged with ZPublisher as a
standalone system.