Re: proposal: inetd improvements.

[elric%imrryr.org@localhost]

On 1275549369 seconds since the Beginning of the UNIX epoch
David Holland wrote:
>

> >     1.  maximum connexions per unit time is not a terribly
> >         useful feature and in fact makes the use of inetd in
> >         an enterprise unusable as it is a built-in denial of
> >         service.  I propose that we keep track of the number
> >         of outstanding children and place a maximum on that
> >         rather than connexions per second.  Perhaps we can
> >         leave connexions per unit time in the code but strongly
> >         discourage its use,
>
>I'm not going to ask what you mean by "in an enterprise". However, try
>the following exercise:
>
>   - edit inetd.conf
>   - enable talkd
>   - attempt to enable logging with talkd's -l option, but fat-finger
>     it and enter -lk
>   - restart inetd
>   - send yourself a talk request
>   - examine your syslog
>
>Perhaps in your enterprise (like the apparent audience of other
>"enterprise" software I shan't name) having this go on forever is
>desirable behavior, but that's not the case in my environment.
>
>Anyway, real rate limiting would be a good thing but let's not break
>what's already there.

I can't help but think that this talkd fat finger example is quite
an edge case but the ``solution'' is quite a problem.  If you exceed
the connexions per minute, inetd will _stop_ the service for ten
minutes.  It's just not reasonable to stop a service for ten minutes
because a certain threshold has been exceeded.  The numbers appear
to be straight from the eighties, from a University environment.

There are better solutions to the talkd example, anyway, which
could be specifically applied to the wait service case only.

At the very least, the defaults should be made reasonable for the
current decade but I think that we should reconsider the entire
approach and try to solve the wait service inappropriately started
in a more specific, more reasonable way.

I'll leave it alone for the time being, though.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/