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

[Jim Fulton]

"Phillip J. Eby" wrote:
> 
> 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

I should have remarked that the user is explicitly doing something.
There isn't really anything solient about it.

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

No, It's gainy, uh, or maybe switchy. :)
 
> >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!

You are slowly swaying me on this ..... I'll let Brian figure out if there
is a consensus on this.
  
> >> 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.)

Hm. Interesting point.
 
> >> 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?

Right, at least without low-level intervention.

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

There is a terminology problem here. The SecurityPolicies API,
http://www.zope.org/Members/michel/Projects/Interfaces/SecurityPolicies,
uses the term context for two concepts. Context is both an overall context
that is passed to policy objects and the incremental context added
by an executable. I was suggesting that we cache owners in the
per-request not per-executable context. (lib/python/AccessControl/
SecurityManagement.SecurityContext).

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

That's the whole point. The SecurityPolicies API is security-policy
agnostic. OTOH, Zope has it's *own* security policy, which you can 
choose not to use if you wish.

Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.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.