Re: [Exist-open] Standalone port binding

[Michael B. <mbe...@mb...>]

> I don't think that eXist is correctly binding the XMLRPC port in
standalone
> mode. When I run "netstat -l | grep exist" I get:
>
> tcp        0      0 localhost.lo:exist-http *:*                     LISTEN
> tcp        0      0 *:exist-xmlrpc          *:*                     LISTEN
>

This is slightly tricky. What you show from netstat suggests that you are
running a build from the first part of February 2005, after the repackaging
of the standalone server I referred to in another post today inadvertently
led to the REST listener under the standalone package being started on the
localhost only instead of all interfaces (which has always been the
behaviour under Cocoon and had previously also been the behaviour in the
standalone). I reported this as a bug, and Wolfgang fixed it in the CVS
later in February, so I assume it is now in the auto-built snapshots.

I can see why you want binding for all listeners to be to localhost only in
your use-case, but with a later build you might find to your dismay that the
REST server was now listening on all i/fs like the xmlrpc server. You can
easily set the REST server back to listening on localhost only by a simple
change to its startup code in StandaloneServer.java (method
startHTTPServer()), and I guess this could be easily made configurable as
the listening port already is. It involves altering

listener.setHost(null);
to
listener.setHost("localhost");

but it looks as though your present version is already setting the localhost
i/f as sole listener for REST and so can be left as is.

But AFAIK the xmlrpc server component simply imports the xmlrpc Webserver
class from a Jakarta project jar, and the source of that, though of course
available, doesn't actually ship with eXist.  The documentation, however,
(http://ws.apache.org/xmlrpc/server.html) indicates that that the Webserver
object supports methods acceptClient and denyClient, so you could presumably
evoke those on the Webserver object instantiated in StandaloneServer.java
so that it denied all requests except those from localhost, thus getting the
same effect as listening on localhost alone. Again this could no doubt be
made configurable to avoid having to hack the source.

That said, I don't think I personally would be happy with my docbase
residing on a server in my DMZ if the data in it had the security
sensitivity you describe. So I'm not sure the localhost-only approach would
really offer the security you need in this particular context, though if the
server were within the inner firewall ring, then making it communicate only
via the localhost i/f with a client process that had a tunnel into the DMZ
would be a useful additional safety measure.

Michael Beddow