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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message