Safe Local XMLRPC

[Michael Urman]

Hi. I'm a user of python for about 3 years now. I've written a
client-server application that uses SimpleXMLRPCServer and
xmlrpclib.ServerProxy to communicate. It's intended to be used by a
single-person as a backend and GUI frontend. I've got it running
great. Much stabler than my custom RPC I'd tried before.

I've used the default support available by these classes. Thus it will
run on a potentially public TCP/IP port. As the application backend
allows, among other things, saving files to the local filesystem, this
would be a clear security hole in the wild. Restricting it to
localhost would be a start, but not sufficient for multi-user systems.

It looks like it should be easy to modify both classes (or create
similar composite classes) that used unix-domain stream sockets. I
tried at one point and I think I got the server side, but without a
working client side it was impossible to tell. Is there a better way
to do this, or might someone point to references or sample code for
creating a unix-domain SimpleXMLRPCServer and xmlrpclib.ServerProxy?

Thanks!
-m

 

[Diez B. Roggisch]

I've used the default support available by these classes. Thus it will

run on a potentially public TCP/IP port. As the application backend
allows, among other things, saving files to the local filesystem, this
would be a clear security hole in the wild. Restricting it to
localhost would be a start, but not sufficient for multi-user systems.

This might not be the answer you want, but I'd personally ditch xmlrpc and
switch to something like pyro or even corba and implement a "real"
authentication theme. They are easy to use, provide a full OO-style
interface and are even faster than xmlrpc.

Part of the problems you're facing stem from the stateless nature of xmlrpc
(and soap, for that matter). That allows everybody to access the API
without prior authentication. It requires some effort to implement a
authentication/authorization scheme over xmlrpc. What usually is done in
xmlrpc in similar situations like yours is that there is a

authenticate(user, password)

function that will return a handle on success that has to be passed to all
subsequent calls to other functions. All this because the handle can't be
associated with each and every xmlrpc request (in soap that can be done,
but its undstandarized.)

With corba/pyro, authenticate would return an object that implicitely has
all the state needed - nameley who created the connection - and then you
don't have to bother about that anymore.

Switching to pyro shouldn't be much more than a few lines of code, more or
less only subclassing your server from Pyro.core.ObjBase instead of
SimpleXMLRPCServer.

 

[Michael Urman]

[Sorry, I previously replied to Diez offlist, and probably to a
spam-protected address at that. Here's that reply and my followup
after reading up on pyro
]

I don't have a problem with switching interfaces so long as I can keep
my (admittedly useless) feature of multiple simultaneous connections.
I am hoping to avoid writing an authentication method, as some slight
missteps there could lead to real trouble later; this is why I was
hoping to do unix-domain socket transports which I could just set to
read-write only by the owner on the filesystem itself.


If I can get the authentication that I'm looking for that cheaply,
then this does indeed sound like the way for me to go. I'm not worried
about supporting remote connections, or anything of that nature, so
local identity is sufficient. I'll look into pyro; conveniently
there's a debian package for me to try.

Thanks Diez!
-m

Hmm. On inspection, pyro seems to be really heavy, what with its
requirement of a pyro-nameserver, and using TCP as the transport. I
think I'd still prefer convincing a variant of SimpleXMLRPCServer and
xmlrpclib.ServerProxy to use unix domain sockets and using filesystem
security to limit access to the owner.

Thanks again,
-m

 

[Michael Urman]

Thanks for your time everyone; I got it XMLRPC working over unix
domain stream sockets. In case people are interested, here's the
pieces I put together. I'm sure they throw away a little flexibility,
but they work for my purpose. Any pointers to make the code more
robust, or do less total overriding of should-be-arguments
appreciated.

-m

from SocketServer import UnixStreamServer
from SimpleXMLRPCServer import SimpleXMLRPCDispatcher,
SimpleXMLRPCRequestHandler
from xmlrpclib import ServerProxy, Fault, Transport
from socket import socket, AF_UNIX, SOCK_STREAM

# Server side is pretty easy - almost a direct copy of SimpleXMLRPCServer
SOCKPATH = 'testsock'
class UnixStreamXMLRPCServer(UnixStreamServer, SimpleXMLRCPDispatcher):
def__init__(self, addr=SOCKPATH, requestHandler=SimpleXMLRPCRequestHandler):
self.logRequests = 0 # critical, as logging fails with UnixStreamServer
SimpleXMLRPCDispatcher.__init__(self)
UnixStreamserver.__Init__(self, addr, requestHandler)

# Client is a lot more complicated and feels fragile
from httplib import HTTP, HTTPConnection
class UnixStreamHTTPConnection(HTTPConnection):
def connect(self):
self.sock = socket(AF_UNIX, SOCK_STREAM)
self.sock.connect(SOCKPATH)

class UnixStreamHTTP(HTTP):
_connection_class = UnixStreamHTTPConnection

class UnixStreamTransport(Transport):
def make_connection(self, host):
return UnixStreamHTTP(SOCKPATH) # overridden, but prevents IndexError

proxy = ServerProxy('http://' + SOCKPATH, transport=UnixStreamTransport())
# proxy now works just like any xmlrpclib.ServerProxy

 

[Diez B. Roggisch]

Hmm. On inspection, pyro seems to be really heavy, what with its

requirement of a pyro-nameserver, and using TCP as the transport.

The nameserver is purely optional. Regarding the overhead of transport -
well, I didn't check pyro on that, but corba is 10-100 times faster over
the network than soap/xmlrpc. So while the local loopback _might_ be slower
(I'm not even sure about that) than the unix socket, marshalling data as
xml has its own cost overhead.

 

[Stephen Waterbury]

... corba is 10-100 times faster over
the network than soap/xmlrpc. ...

I'm not challenging these statistics (because I don't know),
but I would be interested in the source. Are you referring
to the results of an actual benchmark, or something more
subjective?

Steve

 

[Diez B. Roggisch]

I'm not challenging these statistics (because I don't know),
but I would be interested in the source. Are you referring
to the results of an actual benchmark, or something more
subjective?

Mainly personal expirience (I run a corba server that has an xmlrpc server
on top to adapt the interface for php, which has limited corba facilities),
but there are benchmarks on this that support my claim:

http://csdl.computer.org/comp/proceedings/apsec/2002/1850/00/18500084abs.htm