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. Yes. > (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:
pgpvk8ExSXKjI.pgp
Description: PGP signature