Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Jul 1999 14:07:11 -0400 (EDT)
From:      Seth <seth@freebie.dp.ny.frb.org>
To:        Chris Johnson <cjohnson@palomine.net>
Cc:        freebsd-stable@FreeBSD.ORG
Subject:   Re: tcpd, inetd, and hosts.[allow|deny]
Message-ID:  <Pine.BSF.4.10.9907281354210.3101-100000@freebie.dp.ny.frb.org>
In-Reply-To: <19990728135205.A13283@palomine.net>

next in thread | previous in thread | raw e-mail | index | archive | help


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9907281354210.3101-100000>