SecureZEO rehash, was Re: [ZODB-Dev] ZEO signal feature

[Christian Reis]

On Mon, Sep 23, 2002 at 12:26:45PM -0400, Jeremy Hylton wrote:
> >>>>> "CR" == Christian Reis <kiko@async.com.br> writes:
> 
>   CR> On Mon, Sep 23, 2002 at 12:07:49PM -0400, Jeremy Hylton wrote:
>   >> I'm trying to clear out the backlog of ZEO todo items in hopes of
>   >> getting another beta release out soon.  I'd like to accommodate
>   >> the use cases that lead to the signal code, but I wonder if we
>   >> could consider some other alternatives.
> 
>   CR> We have been working on a SecureZEO class this week that
>   CR> subclasses ClientStorage and the basic Storage. We're trying to
>   CR> get a solution that doesn't avoid changing ZEO, but we might
>   CR> need to. Can we send patches your way for review, to check if it
>   CR> is acceptable for integration?
> 
> Yes.  Happy to look at patches, or to review design plans before they
> get to the patch stage.

Do we have plans for SecureZEO outlined somewhere? There are some
references to http://www.zope.org/Wikis/ZODB/ZEO2 but nothing very
solid. 

There *is* a comment by someone famous that says:

    * There's been a fairly length discussion of this issue
      on the zodb-dev mailing list. The short answer is the untrusted
      clients can't use the ZEO protocol because it gives them access to
      object pickles. Instead, you'd need something like a trusted ORB
      that served objects to untrusted clients via RPC. --jeremy

Our mechanism allows very simple access control, and removes the need
for an ORB for this specific case. 

There is also a reference to doing client IP access control, which is
nice but can be implemented using a firewall, so it isn't top-priority
for us.  Anyway, the auth() hook is flexible enough for it to be
implemented easily, as would Zope security, I suppose.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL