[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: And now for something completely different... etch!

On 06/22/05 12:02:53PM -0500, Manoj Srivastava wrote:
> On Wed, 22 Jun 2005 07:22:33 -0400 (EDT), Freddie Unpenstein <fredderic@excite.com> said: 
> >> > - inetd begone! -> xinetd (better mechanism to control DoS,
> >> >   separation, etc.)
> >> xinetd begone. There is no justification for using anything
> >> resembling inetd on a modern system.
> > What planet do you live on?  I want MORE use of inetd, not less.  I
> > want to be able to select a service, and tell the system whether I
> > want it running all the time, or only when needed.
>         Why? What you offer here are preferences and opinions, with
>  nothing to back them up. Previous posters in the discussion have
>  offered reasons not to use inet daemons -- off the top of my head, it
>  was a) in the current day and age, an idling daemon does not consume
>  a significant amount of resources, b) a inted daemon adds complexity
>  to the mix, and another point of failure/attack c) It adds latency to
>  response for the daemon (I may have missed other points).
>         What do you have to counter these points? I can speculate that
>  you may disagree with point a above, but if so, I think in my
>  experience point a has been justified.

>From the security aspect using xinetd automatically gets you things like
connection rate limiting, tcp wrappers support, source address
available time restrictions, connection logging, interface binding, etc.

Sure some daemons already sport those options, but not all do and if a
standard is to be chosen it should be safer one. If you know the service
well enough to configure it you probably also know how to disable the
xinetd instance and enable the init script.

>         manoj


Reply to: