[ZODB-Dev] ZEO and Security

[Jason Cunliffe]

"Jeremy Hylton" <jeremy@digicool.com> wrote:
> I don't agree.  There are a variety of security issues that ZODB
> should probably address.  For ZEO, a minimum level of security is
> controlling access to the database.  For any interesting application,
> however, there needs to be some real access control machinery.
> Something like Python's rexec, which can be used to force a client to
> use an object's official interface, seems like the right place to
> start.
>
> On the whole, it seems like a big project.


hmm... Wondering if one could embed PYRO to manage a ZEO security system?

http://www.xs4all.nl/~irmen/ap/pyro.html

<quote>
Current release version: 2.0 (31-Jan-2001)

Pyro is an acronym for PYthon Remote Objects. It is a basic Distributed
Object Technology system written entirely in Python, and for use in Python
only. With this, it closely resembles Java's Remote Method Invocation (RMI).
It has less similarity to CORBA - which is a system- and language
independent Distributed Object Technology and has much more to offer than
Pyro or RMI. But Pyro is small, simple and free!

...

What features does Pyro have?

Written in 100% pure Python. It is small, simple and extremely portable - it
runs everywhere Python runs, and - at least for now - the socket module is
available. It's not bound to AmigaPython, it works on all Python platforms.

Naming Service which keeps record of the location of objects. The location
of the NS can be discovered by a broadcast mechanism, and various other
ways, if your network doesn't support broadcasting. NS has option to keep
its naming database persistent (on disk) so that it survives shutdowns.

Mobile objects. Clients and servers can pass objects around - even when the
server has never known them before. Pyro will then automatically transfer
the needed Python bytecode.
Support for Python types only restricted by those that the standard 'pickle'
module handles (all builtin types, and user created classes) Objects as
arguments are also supported.

All arguments have pass by value semantics. There is no pass by reference.

Support for all Python argument types (variable argument lists and keyword
arguments, *args and **keywords).

Exceptions that occur in the remote object will actually be raised too on
the client, just as if the error occured locally. Pyro's exception
transportation mechanism makes this possible.

Potential support for different protocols, without having to change your
code. Currently however only one protocol is implemented: PYRO (which runs
on top of TCP/IP).

Dynamic Proxies - no need for additional tools or classes.

Direct remote attribute access with normal Python syntax.

Server can dynamically create or remove new Pyro objects.

Multithreaded server support to handle multiple requests simultaneously.

Automatic reconnection in case of network connection failures.

And much more...
</quote>


./Jason
___________________________________________________________
Jason CUNLIFFE = NOMADICS['Interactive Art and Technology']