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

Re: xinetd is a viable inet-superserver

On Wed, Nov 28, 2007 at 09:15:05AM +0000, Klaus Ethgen wrote:
> 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?)

  No I won't use debconf here, because it's definitely the most viable
way to use xinetd nowadays. Though the next upload will document that
fact completely in the README.Debian

> > 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!)

  It won't do that because new defaults /etc/inetd.conf are empty. And
it's documented in NEWS.Debian properly, which administrators are
supposed to read. apt-listchanges does that for you.

> The only solutions would be eider:
> 1. Implement a debconf question and explain that there is a problem or

  I don't want to use debconf. It's an overkill. Though I may force the
setting to "No" instead of "Yes" if upgrading from an existing install.
That's safer indeed. Will do that.

> 2. Switch it of by default for updates and maybe on by default on new
>    installs.

> >   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_.

  wrong. providing inet-superserver means that you are able to perform
what any implementation of inetd(8) does, namely, reading
/etc/inetd.conf, and _then_ possibly have extended features on its own.

> > (1) only honour /etc/xinetd* files, by disabling compat mode
> >     altogether.
> Would be the best in my understanding.

  You can do that, it's up to you as an administrator.

> > (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
> deleted.

  Too bad. Note that given that xinetd proposes the handly "disabled =
yes" configuration option, that's unwise.

> >   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).

  Gni ? I don't understand what you're talking about.

> >   - 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?

  because the duplicated configuration in stock /etc/inetd.conf _and_
/etc/xinetd.c/* configuration will come from packages that want to
support both, and then the service name will be the same.

  I don't expect administrators to be dumb enough to configure mutual
exclusive services in their /etc/inetd.conf _and_ xinetd.conf. Or if
they do, then I'm sure they already have plenty of rope and I don't mind
giving them some more.

·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgp3W_fyw0zdY.pgp
Description: PGP signature

Reply to: