On Tue, Nov 07, 2006 at 07:39:22PM +0100, Jaromir Dolecek wrote:
> On Wed, Nov 01, 2006 at 03:34:05PM -0500, Chuck Cranor wrote:
> > before going into some detail about the libwrap overhead, it is 
> > important to understand that ypserv is a single threaded server 
> > application.   it processes one request at a time.   if ypserv 
> > blocks on a request (e.g. waiting for I/O), then everything stops
> > until it unblocks.
> Did you confirm that switching off libwrap would actually help
> with this?

Sure.   In fact, it is pretty easy for someone to remotely 
exploit it and screw up your YP service.  All you need is an 
IP address whose DNS servers are down or badly configured 
[thus causing long delays and an eventual timeout in getaddrinfo(3)
and getnameinfo(3)].   When you connect to ypserv from that
host, all ypserv requests will block until the timeout expires.
Just keep connecting from the bad host and you'll basically
almost completely disrupt yp service.

We have two ypserv hosts for our YP domain.  One is on our
private net10 network, and the other is on both the private
net10 network and the Internet.   The second server has all
sorts of random trouble because it is on the Internet and we
frequently get port scanned from random places on the internet.
The first server is fine, because it is unreachable from the
Internet.


> One solution to this is also to convert ypserv to be threaded
> server.

I seem a couple of problems with that.   First, because the timeout
is so long [and easy to trigger, once you understand the DNS part] 
it would be easy to cause ypserv to exhaust its thread pool.    Second,
it doesn't address the circular dependency issue --- libwrap still
uses APIs that may depend on ypserv.   I don't think we want daemons
calling themselves to make requests.    Finally, I believe fixing
the problem in libwrap is a smaller (less invasive) change than 
rewriting chunks of ypserv to be threaded.


chuck