[Zope] Server Side Trojan thoughts...

[Evan Gibson]

I've been reading the description of this problem and have
been wondering about a few things...

Mainly I have questions about "Taking Ownership". This permission
will need to be kept from almost everyone.
For starters since a user gains the "owner role" whenever they
take ownership of an object this can be used to gain complete access 
to absolutely anything they can take ownership of.

Does the existing owner lose the "owner role" when another person
becomes owner? I don't think so currently.

People with the "owner role" are allowed to delegate and give this
"owner role" to others, the _exact_ opposite of the model for
moving "owner" itself which can only be taken. This is bound to
cause even more confusing.

Wouldn't it be better to actually dump the whole concept of "owner
role" and have a single coherent ownership system? Then there
would be no confusion. The whole "owner role" seems to be 
predominately for delegation, but it _already_ works differently
from normal permissions in that the person who has the owner role
for any particular object isn't a set property of the user, but
rather a mix of the user and the actual object.
It would make sense to me to divorce the normal permissions system
(in which a user has certain set roles according to their acl_user
settings, regardless of where they are in the subtree) from the
ownership system (in which the permissions the user has are not
absolute).

Shouldn't "owner" have to be given away as _well_ as accepted?
I understand why it has to be accepted, otherwise you could script
your objects to pass themselves to a person with more authority
and then run themselves.
Acceptance would be difficult in that currently everything to do 
with ownership is atomic, but if it was introduced there would be
no need to have a "Take Permissions" permission that needed to be
jealously guarded, you'd return to trusting the people themselves
instead of being draconian and paranoid.
Mainly I see cases of virtual hosting in which the leader of a 
certain web-project is leaving and wants to pass on ownership to
his successor, someone who's also been working on the project but
doesn't have as high permissions.
Since it's virtual hosting neither has superuser permissions,
neither has "Take permission" permissions. Given the suggested
model they would have to petition the superuser to move the
ownership over. (I presume that's going to be possible for the
superuser?)
If you had 500 projects running the superuser shouldn't have to
deal with this kind of thing, it should be possible for the
people to do themselves without having to have an extremely
dangerous permission.



Unrelated but still permission stuff...
Is management of the permissions planning on changing?
It's a different problem, but I was planning on implementing
a "project" system in which people were able to become members
of projects which would give them specific permissions within
the subtree that housed that project.
This isn't feasible within the existing security framework as
you have to set up every project as a separate role, disallow
all access to that role except in the directory given.
There is a _lot_ of messing about with checkboxes and you can't
automate it easily. With (say) 100 projects you'd have a _lot_
of trouble searching through the permissions screen, especially
if you needed to add new roles and they ended up in the middle
of all the project specific roles. It'd be very confusing.
What I was planning on doing was making a "projects" property
for users, just a list of which projects they were members of
and then in the header of every dtml page within a project check
that that projectname was contained in the list else redirect
to a safe page.
This would work, but it wouldn't protect non dtml objects.
I suppose the proper thing to do would be to create a "project
folder" object that checked the users membership of that project
as well as using the normal zope security.
Anyone got any other suggestions?


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