Date: Wed, 23 Jun 1999 10:29:04 +0200 From: Sheldon Hearn <sheldonh@uunet.co.za> To: John Baldwin <jobaldwi@vt.edu> Cc: David Malone <dwmalone@maths.tcd.ie>, freebsd-hackers@freebsd.org Subject: Re: Inetd and wrapping. Message-ID: <40401.930126544@axl.noc.iafrica.com> In-Reply-To: Your message of "Tue, 22 Jun 1999 18:18:34 -0400." <199906222218.SAA22760@smtp4.erols.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 22 Jun 1999 18:18:34 -0400, John Baldwin wrote: > But if I want to log *all* connections to service foo, but not bar, I > could not use tcpd for foo and and bar by itself and achieve that, so > you are removing some configurability. If very few people use this > extra configurability and if it is a pain to add it in, then I guess > it's no real big deal. I used to pride myself in my communication skills, but I'm starting to doubt myself. :-) My concern is that what you want introduces duplicate functionality. I'm not denying that you can't do exactly the same things with inetd that you could with tcpd, but that's to be expected. So far, the mail that I've received which has requested per-case exclusion options has been motivated by two concerns: 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. 2) Logging. I understand that folks want to be able to have their logs look the same as they did when tcpd was in use. That's already not possible, since the wrapping-related messages you see come from inetd[pid] and not tcpd[pid]. I believe that you can have all the messages you used to get going to all the places it used to go, but now using different configuration. Now you should use the hosts_options(5) "severity" option to assign a syslog selector to the messages generated for a service and tune syslog.conf to get messages to the right log destinations. 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. 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. 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. Hopefully this clarifies what's going on in my head. :-) Later, Sheldon. 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?40401.930126544>