From bicknell@ussenterprise.ufp.org  Wed May 27 14:39:49 1998
Received: from ussenterprise.ufp.org (bicknell@ussenterprise.ufp.org [209.12.7.40])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA08157
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 27 May 1998 14:39:44 -0700 (PDT)
          (envelope-from bicknell@ussenterprise.ufp.org)
Received: (from bicknell@localhost)
	by ussenterprise.ufp.org (8.8.8/8.8.7) id RAA03805;
	Wed, 27 May 1998 17:39:28 -0400 (EDT)
Message-Id: <199805272139.RAA03805@ussenterprise.ufp.org>
Date: Wed, 27 May 1998 17:39:28 -0400 (EDT)
From: Leo Bicknell <bicknell@ufp.org>
Reply-To: bicknell@ufp.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: bind(3)/libc improvement
X-Send-Pr-Version: 3.2

>Number:         6774
>Category:       kern
>Synopsis:       bind(3)/libc improvement
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed May 27 14:40:01 PDT 1998
>Closed-Date:    Thu May 28 23:02:56 PDT 1998
>Last-Modified:  Thu May 28 23:04:06 PDT 1998
>Originator:     Leo Bicknell
>Release:        FreeBSD 2.2.5-RELEASE i386
>Organization:
United Federation of Planets
>Environment:

	Any FreeBSD 2.x system.

>Description:

	Many programs bind to "wildcard" addresses for the purposes of
getting a local IP address/port assigment.  This works fine when a
machine has a single interface, but for machines with multiple physical
or logical (alias) interfaces this is not always appropriate.  For
instance, on a machine with 10 aliases the "telnet" service, as managed
by inetd(8) will respond to all 10 addresses.

	What I propose is an enviornment variable, "LOCAL_BIND" which
would be used by the bind(3) code.  If this does not exist, the
traditional behavior would occur.  On the other hand, if it was set to
an IP address on the local system a "bind" call to the wildcard address
would go to that address, and that address only.  A further extension
would be to have a list of acceptable addresses.

	This would allow things like an outbound telnet connection
from a particular address forced by the user, or having a program like
inetd listen only to some addresses without chaning the code of these
user applications.

>How-To-Repeat:

	N/A

>Fix:
	
	N/A

>Release-Note:
>Audit-Trail:

From: njs3@doc.ic.ac.uk (Niall Smart)
To: bicknell@ufp.org, FreeBSD-gnats-submit@freebsd.org
Cc:  Subject: Re: kern/6774: bind(3)/libc improvement
Date: Thu, 28 May 1998 12:51:11 +0100

 On May 27,  5:39pm, Leo Bicknell wrote:
 } Subject: kern/6774: bind(3)/libc improvement
 > 
 > >Synopsis:       bind(3)/libc improvement
 
 > 	Many programs bind to "wildcard" addresses for the purposes of
 > getting a local IP address/port assigment.  This works fine when a
 > machine has a single interface, but for machines with multiple physical
 > or logical (alias) interfaces this is not always appropriate.  For
 > instance, on a machine with 10 aliases the "telnet" service, as managed
 > by inetd(8) will respond to all 10 addresses.
 > 
 > 	What I propose is an enviornment variable, "LOCAL_BIND" which
 > would be used by the bind(3) code.  If this does not exist, the
 > traditional behavior would occur.  On the other hand, if it was set to
 > an IP address on the local system a "bind" call to the wildcard address
 > would go to that address, and that address only.  A further extension
 > would be to have a list of acceptable addresses.
 
 I'm inclined to just say "what a gross hack". :)  If a program should
 have the ability to bind to specific addresses then the author of the
 code should provide that functionality through command line arguments
 or configuration files.  There is currently no problem with the bind(2)
 interface, the problem is in the programs which use it, and therefore
 it's their behaviour which should be changed, not bind(2)'s
 
 Also, were you aware that even if a process has bound to a specific
 interface, it can still receive packets recieved on other interfaces
 destined for that interface?
 
 > 	This would allow things like an outbound telnet connection
 > from a particular address forced by the user, or having a program like
 > inetd listen only to some addresses without chaning the code of these
 > user applications.
 
 Modifying inetd so it only binds to specific interfaces is probably
 a good idea.
 
 Niall
State-Changed-From-To: open->closed 
State-Changed-By: phk 
State-Changed-When: Thu May 28 23:02:56 PDT 1998 
State-Changed-Why:  
unfortunately most of the discussion has not been recorded here, but the 
gist of it as understood by me was a resounding no. 

>Unformatted:
