Python Desktop Server Weblog 2004/10

Due to a comment on my last posting I changed the PickleRPCHandler to be only enabled when the user explicitely set's a config flag. The reason being the still running discussion wether unpickle is safe for untrusted data. The problem is discussed here. There are several aspects to it: evaling quoted strings (deemed not to be a problem because the strings are inspected before evaluating and Python doesn't have things like interpolation in Perl) and constructor/destructor calls for class instances.

With Python 2.2, only classes with a special attribute could be instantiated, but with Python 2.3 it seems like this security measure was dropped - so an exploit would have to instantiate a class in a way that opens up the system.

In general it's better to play on the safe side and just don't use the PickleRPC mechanism if you expose your toolserver to untrusted systems.

Update: I added a shared secret that you need to set in both the server config and the client constructor call. The shared secret is used to build a secure hash based on the actual call data and the shared secret. That way your calls are signed with your shared secret without transfering itself over the wire. The check on the shared secret is done before any unpickling takes place, so at least you know who to yell at if you get bad code in your pickle

The shared secret is now used for both the request (so the server can be sure that at least the client knows about the shared secret) and the response (so the client can be sure that the result wasn't tampered with).

TooFPy: native pickle based RPC mechanism

TooFPy (in CVS) now has it's own native python RPC mechanism. What it does is it marshalls the call as a tuple (methodname, args, opts) that is pickled and base64 encoded. The result is returned directly as a base64 encoded pickle, too. This native RPC mechanism is much faster than XML based mechanisms, since you just can use standard libraries with fast algorithms (it uses cPickle, if available). Additionally exceptions are better supported (with XMLRPC you just get a standard error code, with SOAP you only get the faultType exception, with PickleRPC you get all exceptions as they happen on the server).

Due to the multi-protocol-nature of TooFPy you don't loose portability: if you use Python both on the client and the server, you can use the new PickleRPC mechanism. If you use other languages on the client, you just use SOAP or XMLRPC, whatever suits your need. All methods are available through all protocols and the validation wrappers and programming by contract wrappers are used the same way regardless of the protocol you use.

Additionally the TooFPy code was restructured so that adding new protocols is very easy. PickleRPC can be seen as a sample implementation for this extensibility. The code includes a client module that you can use in your own programs.