by redmail.netbsd.org with SMTP; 18 Oct 1999 10:19:18 -0000
	by splode.eterna.com.au (Postfix) with ESMTP
	id 597AA3C88; Mon, 18 Oct 1999 20:19:07 +1000 (EST)
To: "Brian C. Grayson" <bgrayson@marvin.ece.utexas.edu>
Cc: Manuel Bouyer <bouyer@antioche.lip6.fr>,
	tech-security@netbsd.org, itojun@iijlab.net
subject: re: libwrap (was Re: amd vulnerability: patch for 1.3.3) 
in-reply-to: your message of "Mon, 18 Oct 1999 03:03:05 EST."
             <19991018030305.A20667@marvin.ece.utexas.edu> 
organisation: people's front against (bozotic) www (softwar foundation)
x-other-organisation: The NetBSD Foundation.
Date: Mon, 18 Oct 1999 20:19:06 +1000
Message-ID: <16779.940241946@eterna.com.au>
From: matthew green <mrg@eterna.com.au>

   
     I was under the impression that portmap was for RPC what
   inetd was for TCP.  The man page says "When a client wishes to
   make an RPC call to a given program number, it will first
   contact portmap on the server machine to determine the port
   number where RPC packets should be sent."  I'm not much of a
   networking guy, though.
   
     But I tried it out, and it appears to work.  So there's
   something to be said for naivete!  If all RPCs go through
   portmap, then I think this is good.  If there are sneaky ways
   to avoid portmap, then these changes may only provide a false
   sense of security.

well, think about it some... the client contacts portmap to find
out what port the server is running on, and then contacts the server
on that port -- this is where you need libwrap support, for this
to be really useful...