[Zope] Re: [Zope-dev] Introspection, managing External Methods?

[michel@digicool.com]

Robin Becker <robin@jessikat.demon.co.uk> writes:

> In article <199907181357.XAA01659@mbuna.arbhome.com.au>, Anthony Baxter
> <anthony@interlink.com.au> writes
> >
> >This has come up on a number of occasions - the problem is that an
> >external method can subvert all the protections and access control
> >that Zope provides.
> >
> >Having said that, there's nothing stopping you (or someone else) 
> >writing an external method that allows you to edit external methods. :)
> >
> >Anthony
> >
> Yes I know that external methods can do anything. But since the manager
> can destroy the site what's wrong with allowing editing only for the
> manager. I realise that malicious managers could wipe the hard disk if
> the manager user could, but then so can the manager sitting at the
> console.
> 

The problem here is that Zope can have many concepts of a 'manager'.
Someone you trust with managerial rights in
/some/backwater/zope/folder is as much a 'manager' as a top level
manager, only restricted in place, not permission.  If you give a user 
the 'Manager' role, they will have the permission to 'Edit External
Methods' unless you explicitly turn it off.

Another reason is that HTTP is not the World's Most Secure Protocol.
In fact, HTTP Basic authentication is downright scary.  Remember,
external methods can do more than just whack your site, they can do
anything to the filesystem the Zope process owner can do.  Including
something more sinister than just mere deletion (which any sys admin
worth her salt should be able to restore in minutes) such as password
sniffing trojan horses and possibly even something kinda wild like
XML-RPC worms (now THAT would be cool!).  The last thing we want to
see is a back orifice for Zope, which is exactly what I think could be 
developed if we ever provided a hole through Zope's security machinery.

-Michel