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

[Evan Gibson]

On Mon, May 22, 2000 at 10:23:38AM -0600, mindlace wrote:
> Robin Becker wrote:
> > What kind of idiotic permissions model is this where God cannot create
> > anything? What is the function of the super user if not to manage?
> > Seems to be specially designed for bureaucrats, lawyers and politicians.
> 
> I feel like this specifically needed to be addressed.  This change in
> the ability of superuser stems directly from a security issue common to
> all through-the-web interfaces:
> http://www.zope.org/Members/jim/ZopeSecurity/TrojanIssueOverview
> The superuser cannot create objects, because any object that was owned
> by superuser would have permission to do whatever it pleased.

Yes, but if people _want_ to create superuser objects that can do anything
they should be permitted to. As long as the superuser doesn't make really
stupid objects they shouldn't get bitten.

The problem is that the new security model should have more handholding
to go along with it.
Perhaps the superuser should be changed to the name "usermanager" or
"permissionsmanager" or something like that and a default superuser
with the behaviour every actually expects the superuser to have be
created as well.
As it stands now you need _two_ "superuser" type users, so they should
both be created automatically instead of having to create one of them
manually afterwards.

Also I still maintain that, as well as the "Take Permissions" permission
that a NONE permissioned method should be available for ownership
transfer, that you can "offer" an object to someone and they can later
on "accept" it when they log in. (Like the moderation concept in Squishdot)
This is needed for cases where a site manager has say a hundred projects
going on under their Zope server. When one of the projects changes
project leader and leaves they have to transfer ownership to their
successor, but they _can't_ because their successor is _less_ authorised
than they are and can't "take permissions".
In this case they currently have to petition the person running the site
to change all of the permissions for their project over. This is a waste
of everyone's time and completely unecessary.
With a challenge/response transfer of objects you have complete security
maintained (especially if you allow the person accepting the ownership
to preview the object prior to their decision to accept it.)
It's more work to set up this system because nothing in core Zope uses
this type of messaging once people login, but it's a much broader and
usable means for ownership transfer without losing any security.

> Hope that's a bit more explanatory,
> ~ethan mindlace fremen
> digicool & imeme

-- 
  Evan ~ThunderFoot~ Gibson    ~ nihil mutatem, omni deletum ~
   It doesn't count as intimacy until somebody starts crying.