From owner-freebsd-stable Wed Jul 28 11: 8:54 1999 Delivered-To: freebsd-stable@freebsd.org Received: from fed-ef1.frb.gov (fed.frb.gov [132.200.32.32]) by hub.freebsd.org (Postfix) with ESMTP id D0A5914C3F for ; Wed, 28 Jul 1999 11:08:52 -0700 (PDT) (envelope-from seth@freebie.dp.ny.frb.org) Received: by fed-ef1.frb.gov; id OAA20851; Wed, 28 Jul 1999 14:08:00 -0400 (EDT) Received: from m1pmdf.frb.gov(192.168.3.38) by fed.frb.gov via smap (V4.2) id xma020100; Wed, 28 Jul 99 14:07:14 -0400 Date: Wed, 28 Jul 1999 14:07:11 -0400 (EDT) From: Seth Subject: Re: tcpd, inetd, and hosts.[allow|deny] In-reply-to: <19990728135205.A13283@palomine.net> To: Chris Johnson Cc: freebsd-stable@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Jul 1999, Chris Johnson wrote: > But before you blindly remove all references to /usr/local/libexec/tcpd, you > read the man page for the new inetd, which refers you to hosts_access(5). You > read that and see that the files are now in /etc. And even if you don't read > the man page, it occurs to you that since inetd is a part of the base > distribution, it'd never be looking at a file in /usr/local/etc anyway. > > Chris > Yes. *I* would do that (and did, which is why I saw the problem). This was not a "hey, you guys, you got it wrong!" message. This was a "hey, I ran across this set of inconsistencies and wanted to make sure people weren't relying on false assumptions." Two things still stand out: 1) tcpdchk and tcpdmatch were included as part of the base distribution prior to having a wrapped inetd. Their default behavior was changed before 6/20: it went from checking /usr/local/etc to /etc. This wasn't documented on the list, afaict. My CTM update did a wholesale replacement of tcpdmatch.8 on 20 April. I can't tell whether this was the change. 2) I am not suggesting that the documentation is incorrect. The documentation has been consistent throughout. IMHO, however, whenever you make a substantive change to a security feature, you should point out explicitly what else is affected. You shouldn't rely on the users to figure out that they need to read a new hosts_access manpage, especially when they're familiar with the old hosts_access manpage and nobody's told them that the files have moved. Or maybe you should. But it doesn't cost much to just throw in a paragraph titled "SIDE EFFECTS" or something to that effect whenever you do something like this, and it protects those people who are unfamiliar enough with the changes not to realize that the change is not as simple as it looks. SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message