From owner-freebsd-current Wed Jun 30 0:42: 7 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id D8A7014BCD for ; Wed, 30 Jun 1999 00:42:03 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id AAA26546; Wed, 30 Jun 1999 00:41:54 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <3779CA42.40534D6C@gorean.org> Date: Wed, 30 Jun 1999 00:41:54 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: current@freebsd.org Subject: Re: HEADS UP! Inetd wrapping OFF by default References: <83735.930560597@axl.noc.iafrica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > > First, the setting in /etc/defaults/rc.conf should default to > > off, as defaulting it to on violates POLA for the many many people who > > haven't updated to 3.x from 2.2 yet. > > If we were integrating TCP Wrapper support into the base system for the > very first time, I'd agree with you. However, we've already had a > release go out with an inetd that wrapped by default. It's never too late to change a bad decision. :) The majority of users (and clients) I talk to are still using 2.2.8-[Release|Stable] for many reasons, not the least of which is the perceived (and in some cases very real) level of difficulty in the upgrade. > This is a situation in which we can't make _everyone_ happy. For the > particular case you've provided, anyone who upgrades from 2.2 to 3.3 > without reading the release notes will get what's coming to him. That's always true, but traditionally it's been a primary goal of the project to make these kinds of changes as minimal as possible. > > Also, if the decision is made to leave it on by default, there should > > be a hosts.allow file installed by default that has nothing but "ALL : > > ALL" in it. > > We already have a hosts.allow that effectively allows everything. That's good news, thank you for clarifying it. > > Second, this command line switch is horrible UI design for > > several reasons. First, any command line option that requires that > > the same flag be applied twice is bad design, historical precedents > > aside. > > That's an unfortunately timed revelation for me. I mentioned it the last time you brought up this idea, a week or two ago. > I feel like I've seen > it in a number of programs, although the only one I can remember is > ftpd(8). I used that program as a reference, not knowing that it was bad > design. :-( *Nod* Good UI design is a difficult skill to learn, especially when there are so many bad examples out there. > > Second, what if I want to wrap my internal services, but not wrap my > > external ones? > > Then you want something that the guys working on the code, who use inetd > quite a lot, didn't think of. They probably made the assumption that > real-world scenarios like that don't exist. *Nodding again* That's why we have discussion about these kinds of things. :) > > I propose that the -w flag be changed to take parameters. To > > start with, you would have [-w <[e] [i]>] to control wrapping for > > external and internal services respectively. > > This makes my skin crawl, but that's probably just because I know what > the code looks like. :-) Without having looked at the code, I can't see where it would be that much more difficult. If you want to know whether to wrap internal services you are checking for a condition, whether that condition is two -w flags or the 'i' option to a single -w flag. You can solve this easily in any number of ways, the most common of which is toggling a set of hex flags at startup time. I'm sure I don't have to go into details for you, my point is simply that if the code makes this any more difficult than it has to be, fix the code. While you've already got the hood up tuning up one or two more things shouldn't be that much more work. :) Let me know if you need any help with it. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message