Re: ZEO Client space was: [Zope] Prerequisites for a desktop IDE, or any desktop app w/Zope
On Thu, 24 May 2001, Tim Cook wrote:
Michel Pelletier wrote:
XMLRPC could do this, but I'm afraid it would be seriously limited. XMLRPC is very useful, but it does not map as well as it could onto the python object model. I would prefer to see a GUI client running in the same process space as a ZEO client, this way the GUI client could do everything that Zope could do and re-use alot of the existing interfaces (like security, acquisition, script objects, etc).
Michel, I took this off list because it was off topic for the thread. But feel free to Cc it back if you feel it's important. I think it was covered a few weeks ago on the -dev list but couldn't locate it.
It's not off topic so I'm cc:ing the list.
Anyway, the question is: I thought I had read that using ZEO basically by-passed the Zope security model? Maybe I was thinking of direct ZODB access?
This is a good question. Using ZEO does bypass the Zope security model, but then again, Zope bypasses the Zope security model. Zope is, essentially, a client that implements an application on top of a persistent database. Why can't your client do the same thing? Zope enforces security upon its users using tested, re-usable interfaces. You're should essentially change the user interface to the Zope core code by making it call wxPython widgets or whatever instead of spewing HTML to a browser over a socket. If this GUIfied ZEO client ran on the same machine as the server, it would actually be safer than a "real" Zope ZEO client, which is exposed to the web. We use ZEO clients to access Zope through many different interfaces, not necessarily all of them over a network, or running in a context we don't trust. We use ZEO clients to debug zope from the command line, to serve just FTP or a monitor server, and each different way of doingit is just a shim on top of the core Zope interfaces. By going with xml-rpc, you'll be shoving *very* rich interface semantics of a full blown windowing sytem down the tiny semantic straw of xml-rpc, to try and manipulate interfaces that were originally indented to be used by medium to poor semantic HTML interfaces. If you use a ZEO client, there are no bottle necks. You could render the object system in 3D OpenGL if you wanted to, and still enforce the user. Jerome's ZShell script shows how this can be done safely. His shell is essentialy just another interface to the Zope core code. It would be very dangerous if it did not use Zope's security API to restrict its actions. In zshell's case, the interface is really simple, a command line. It is probably not as safe to to grant access to this command line over unprotected networks. and it would be unsafe to expose a GUIfied ZEO client to unprotected networks, but this is easily mitigatable with things like ssh or ssl. -Michel
On 24 May 2001 21:25:14 -0700, Michel Pelletier wrote:
On Thu, 24 May 2001, Tim Cook wrote:
Michel Pelletier wrote:
XMLRPC could do this, but I'm afraid it would be seriously limited. XMLRPC is very useful, but it does not map as well as it could onto the python object model. I would prefer to see a GUI client running in the same process space as a ZEO client, this way the GUI client could do everything that Zope could do and re-use alot of the existing interfaces (like security, acquisition, script objects, etc).
Michel, I took this off list because it was off topic for the thread. But feel free to Cc it back if you feel it's important. I think it was covered a few weeks ago on the -dev list but couldn't locate it.
It's not off topic so I'm cc:ing the list.
Anyway, the question is: I thought I had read that using ZEO basically by-passed the Zope security model? Maybe I was thinking of direct ZODB access?
This is a good question.
A ZEO Client has full access to the underlying objetcs, that's kinda the point of it. ZEO being independant of Zope, it has no clue about the Zope security mechanism. I think it would be possible to make it aware, but others disagree.
Using ZEO does bypass the Zope security model, but then again, Zope bypasses the Zope security model. Zope is, essentially, a client that implements an application on top of a persistent database. Why can't your client do the same thing? Zope enforces security upon its users using tested, re-usable interfaces.
Here is the rub, and why ssh/ssl is irrelevant and insecure too. You are trustin the client implicitly, as 'root' on the ZODB. ALL the security is implemented on the CLIENT side with Zope, and and ZEo client fo rtha matter. For example, try this out: Set up a Zope ZSS. Set up a Zope ZSS client on the machine. Set up a second one. In the first one, make your emergency user 'bob', password 'bar'. On the second, make the emergency user 'Fred', password 'spam'. Fred has root-level access to the ZODB. I don't care if you use SSH tunnelling or SSL, you are still giving the user god-like abilities to do whatever they please with your database. if they wish, they can replace their client's auth mechanism with one that returns true all the time, without bothering to actually look at the authentication. They can give themselves whatever roles they desire. This makes it, an all or nothing approach. Either you give the user 'root' to your Zope database, or you don;t allow them ZEO access. IMO, that is bad, and dangerous. ...
By going with xml-rpc, you'll be shoving *very* rich interface semantics of a full blown windowing sytem down the tiny semantic straw of xml-rpc, to try and manipulate interfaces that were originally indented to be used by medium to poor semantic HTML interfaces. If you use a ZEO client, there are no bottle necks. You could render the object system in 3D OpenGL if you wanted to, and still enforce the user.
I agree, xml-rpc is not exactly the way to go for this type of usage. SOAP perhaps, but not xmlrpc.
Jerome's ZShell script shows how this can be done safely. His shell is essentialy just another interface to the Zope core code. It would be very dangerous if it did not use Zope's security API to restrict its actions.
In zshell's case, the interface is really simple, a command line. It is probably not as safe to to grant access to this command line over unprotected networks. and it would be unsafe to expose a GUIfied ZEO client to unprotected networks, but this is easily mitigatable with things like ssh or ssl.
If ZShell connects via ZEO, it is insecure. You are correct that it would be bad to allow over untrusted networks, as is any ZEO that needs security of data/data modification. As I have mentioned, ssl/ssh are mostly irrelevant to database security, as even though the data may be non-usbale to network outsiders, those with access can literally do anything. Whmever you give access to via ZEo has unlimited authority on the database. For example, the oops in the ZShell 1.0 release illustrates this nicely. To wit: """ This means that unfortunately the setperms command doesn't check if the user has the "Change permissions" permission before changing permissions, and changes them. """ So, you give a user you presumably trust, ssh/ssl access to use ZShell. They comment this code out, or the code that even botehrs to check for permssion to do anything, and now they now '0WNZ Y0ur z0p3 sist3m'. I think ZEO needs a forced authentication path hook. It wouldn't need to implement the actual security, but would provide a method where upon the app designer could say 'when accessing objects, first run through this method to determine access level'. But that's a separate thread, for a different list. :)
On Fri, May 25, 2001 at 11:39:54AM -0600, Bill Anderson wrote:
So, you give a user you presumably trust, ssh/ssl access to use ZShell. They comment this code out, or the code that even botehrs to check for permssion to do anything, and now they now '0WNZ Y0ur z0p3 sist3m'.
Except that in this particular case the user would also have to have got filesystem write access to the Extensions directory and a Manager role in /Control_Panel in order for him to be able to comment out the code and restart Zope, because ZShell is currently an external method. Anyway I tend to agree with you, it shouldn't be possible to bypass the security mechanism. bye, Jerome Alet
unprotected networks. and it would be unsafe to expose a GUIfied ZEO client to unprotected networks, but this is easily mitigatable with things like ssh or ssl.
Michel, you're on the ZODB-dev list, right? Did the diagram I just posted look like it would fit well with this? In essence, keep the incesure ZEO connection wholly on the server and have the ZEO client serve out as rich an interface (but one that is secure, I was thinking RestricedPython for this) over its connection. comments? cheers, Chris
participants (4)
-
Bill Anderson -
Chris Withers -
Jerome Alet -
Michel Pelletier