[ZODB-Dev] Python RPC

[Jeremy Hylton]

>>>>> "CW" == Chris Withers <chrisw@nipltd.com> writes:

  CW> Basically, ZEO is cool, but insecure. You can't implement
  CW> security on the client side because your clients can then be
  CW> hacked and the security removed.

It's not just that they can be hacked, but that the basic
client-server protocol deals in objecs.  It's not so much clients
being hacked that I worry about, but a program that uses the ZEO
client-server protocol to gain unauthorized access to the database.

  CW>                                   So, I think that means you
  CW> need to do security on the server side where you're clients
  CW> can't futz, which I think leaves:

  CW> Client Python Environment
  CW>           ^
  CW>           |
  CW>    secure transport
  CW>           ^
  CW>           |
  CW>  Server Python Environment
  CW>           |
  CW> RestrictedPython Environment
  CW>           |
  CW>      ZEO Connection

  CW> Is this possible? Does it make sense? If so, is there anything
  CW> already out there that will take care of any of the layers?

This sketch of an architecture looks reasonable.  You'd want an
authenticated connection between the endpoints with optional
encryption.  The server would load objects using the ZEO connection
and enforce some security policy.  The details of how to describe
security policies and enforce them is, of course, the hard part.  

I'm not sure how much of Zope you'd need to swallow to use just its
security mechanism.  It may be appropriate for non-Zope apps, but it
may not.

There's also a level of security that could be provided without quite
so much hassle, although it's utility may be marginial.  We could have
a basic access control mechanism that would allow multiple parties to
share a single storage.  Individual objects would be assigned
permissions, along the lines of file permissions.  Some objects could
be private, others read-only, etc.

Jeremy