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

Re: xinetd is a viable inet-superserver

Hash: SHA1

Hi Pierre,

Am Mi den 28. Nov 2007 um  9:45 schrieb Pierre Habouzit:
> > As long as this is default switched of this might be ok.
>   No it's on by default, and easy to change in /etc/default/xinetd.

So it is easy switchable. (May there are a debconf question?)

> But I do believe (and there was an RC open on xinetd for that, and I
> agree about it) that it being off by default is wrong, because xinetd
> cannot document it's a proper inet-superserver without doing that. If
> as an administrator you disagree, you can change that anytime.

Well the problem is that this change the expected and desired way on
existing installations. If you are a admin and didn't (want to) care
about /etc/inetd.conf and with a update your xinetd will use it silently
(and may open big, big security hole in your server) this is a very big
issue! (And a security bug I think!)

The only solutions would be eider:
1. Implement a debconf question and explain that there is a problem or
2. Switch it of by default for updates and maybe on by default on new

>   Since xinetd conflicts with inet-superserver it's the sole one that
> can honour /etc/inetd.conf.

Well, not completely true. There might be more than one understanding.
Mine is that providing a inet-superserver provides the _functionality_
of a inet-superserver not the same _config file_.

> (1) only honour /etc/xinetd* files, by disabling compat mode
>     altogether.

Would be the best in my understanding.

> (2) work in compat mode, with the (probable, I did not checked but it's
>     likely) drawback that a service "disabled" in the /etc/xinetd* and
>     enabled in /etc/inetd.conf will probably be run.

Disabled can also mean that the respective file is not created or

>   There are 2 ways of not falling in the (2) trap:
>   - either always use update-inetd to enable or disable services (once
>     it'll support xinetd configuration files btw)

Only if it provides the full functionality of xinetd (like ie. only
allow specified ip range or only few connection at once).

>   - or me patching xinetd if it behaves like I fear it does to ignore
>     services from /etc/inetd.conf that are filed under the same name
>     than in /etc/xinetd*. I believe it to be the proper approach, I'll
>     try to write a patch asap.

Why using the name of the service? In inetd.conf the name has to be the
same than the port in /etc/services (and even some service might have
multiple names). In xinetd the name can be any if you specify the
service port in the config. So why not using the port to decide if the
service is enabled or not?

   Klaus Ethgen
- -- 
Klaus Ethgen                            http://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
Version: GnuPG v1.4.6 (GNU/Linux)


Reply to: