Date: Thu, 24 Jun 1999 01:53:32 -0700 From: Doug <DougGuy@dal.net> To: Sheldon Hearn <sheldonh@uunet.co.za> Cc: John Baldwin <jobaldwi@vt.edu>, David Malone <dwmalone@maths.tcd.ie>, freebsd-hackers@freebsd.org Subject: Re: Inetd and wrapping. Message-ID: <3771F20C.7CD06689@dal.net> References: <40401.930126544@axl.noc.iafrica.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sheldon Hearn wrote: > I used to pride myself in my communication skills, but I'm starting to > doubt myself. :-) It's not that we don't understand you, it's that we don't agree with you. There is a HUGE difference. > My concern is that what you want introduces duplicate functionality. You keep saying, "but you can do something like what you want to do with tcp wrappers," but others are saying, quite clearly that they want to be able to COMPLETELY bypass tcp_wrappers altogether. Configuring tcp_wrappers for a specific case is very different from not having to configure it at all. > 1) Performance. > > I think we're all clear now that exclusion options will not > introduce a significant performance gain. We've already > scored our performance gain by obviating an exec on tcpd. By excluding tcp_wrappers you're also excluding the overhead to check the hosts.allow file. On a heavily loaded service this can be considerable. > It's critical that folks understand that built-in wrapping in inetd is > not the same as inetd passing the job of wrapping to a program called > tcpd. Something different is happening in each case. It just so happens > that the two cases share a common goal. Actually, the same thing is happening, just in different places. > When you say you want "functionality that exists with TCP wrappers", I > think you mean "identical semantics to those used with tcpd". You can't > have it, it's that simple. As long as you acknowledge that in this case, "You can't have it" is a design decision, and not everyone agrees with your concept of the design. Personally I don't care enough about it to write the patch, but that won't stop me from registering an objection since you seem to be assuming that silence == assent. > What you should be able to have is the same functionality as was > available when using tcpd. I don't think the fact that you may need to > set things up differently to achieve the same results as you had before > isn't a serious problem, because you're doing a different thing now. That's because you're looking at this from the standpoint of a developer who is deeply involved in the code on a daily basis. You need to start thinking of things in terms of the much more common case, the casual user who will be going from say, 3.0-Release to 3.3-Release without reading any of the documentation. Why should this user have to either go out of his way to fix something that wasn't broken, or find a critical service disabled when he reboots just because no one could be bothered to make the new interface compatible? As far as I'm concerned the system should ship with per service toggles, and all of them toggled off, with a hosts.allow with nothing but "ALL : ALL" in it. But then again I've been called overcautious. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3771F20C.7CD06689>