[ On Wednesday, January 30, 2002 at 10:47:14 (-0500), David Maxwell wrote: ]
> Subject: Re: FTPD-current
>
> man inetd.conf  It's configurable.
> 
> The fields of the configuration file are as follows:
> 
>            [addr:]service-name
>            socket-type
>            protocol[,sndbuf=size][,rcvbuf=size]
>            wait/nowait[.max]
>            user[.group]
>            server-program
>            server program arguments
> 
> ``max'' suffix (separated from ``wait'' or ``nowait'' by a dot) specifies
> the maximum number of server instances that may be spawned from inetd
> within an interval of 60 seconds. When omitted, ``max'' defaults to 40.

Speaking of which....

I've been finding inetd's concept of resource controls to be
increasingly useless.  While it might stop a DoS in many circumstances
it's almost impossible to tune reliably so that system resources can be
fully utilised without risk of overutilisation, even when the pattern of
daemon usage is very predictable.

The primary problem seems to stem from the fact that the limit is
defined as the number of daemons spawned during an interval, not the
number that are currently running.

For instance, how many ftpd's should you allow per minute on an FTP-only
server that has 500 MB of free memory and where each instance requires
nearly 1MB of RAM for its resident page set (and where we're not
concerned with I/O throughput)?  Obviously there's no correct answer
that can ever hope to safely (i.e. without paging) use the maximum
available resources under maximum load.  The question is wrong because
the available tuning knob is totally useless as a resource control.
Even if you only allow the default of '40', it's trivial for an attacker
(or normal demand) to cause the number of running ftpd's to well exceed
the available RAM while not at the same time causing inetd to notice any
excessive number of connections per interval since an ftpd instance may
live far longer than the interval.

(NetBSD's modern ftpd is a poor example as it has its own internal
controls that can be applied to managing resource utilisation....)

I think that by simply changing the meaning of the 'nowait:max' knob to
be the total number of daemon instances currently running then most of
the problem is solved for all daemons.  (the 'wait:max' knob would still
best be thought of in terms of connections per interval since of course
there'll only ever be one instance of the daemon at any one time, except
for the likes of talkd(8) which fake out inetd and keeps running even
though it expects to be started with 'wait')

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>