This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Fri Apr 26 10:37:11 2024 Received: from spaans.ds9a.nl (adsl-xs4all.ds9a.nl [213.84.159.51]) by kylie.puddingonline.com (8.11.6/8.11.6) with SMTP id g8HKfai07341 for ; Tue, 17 Sep 2002 22:41:37 +0200 Received: (qmail 622 invoked from network); 17 Sep 2002 20:25:16 -0000 Received: from unknown (HELO spaans.ds9a.nl) (3ffe:8280:10:360:202:44ff:fe2a:a1dd) by mayo.ipv6.ds9a.nl with SMTP; 17 Sep 2002 20:25:16 -0000 Received: (qmail 24735 invoked by uid 1000); 17 Sep 2002 19:46:36 -0000 Received: (maildatabase); juh Received: (qmail 5730 invoked by alias); 21 Oct 2000 07:46:11 -0000 Received: (qmail 5514 invoked from network); 21 Oct 2000 07:45:23 -0000 Received: from server.ds9a.tudelft.nl (HELO home.ds9a.nl) (10.0.0.1) by spaans.ds9a.nl with SMTP; 21 Oct 2000 07:45:23 -0000 Received: (qmail 2272 invoked by uid 0); 20 Oct 2000 23:39:45 -0000 Received: from vger.kernel.org (199.183.24.194) by home.ds9a.nl with SMTP; 20 Oct 2000 23:39:45 -0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 20 Oct 2000 19:01:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Oct 2000 19:01:31 -0400 Received: from mail.calderasystems.com ([216.250.130.2]:40717 "EHLO mail.calderasystems.com") by vger.kernel.org with ESMTP id ; Fri, 20 Oct 2000 19:01:16 -0400 Received: (qmail 1656 invoked by uid 0); 20 Oct 2000 22:44:36 -0000 Received: from mpeterson@calderasystems.com by mail.calderasystems.com with scan4virus-0.50 (uvscan: v4.0.70/v4077. . Clean. Processed in 0.214893 secs); 20/10/2000 16:44:36 Received: from ns.calderalabs.com (root@216.250.131.1) by mail.calderasystems.com with SMTP; 20 Oct 2000 22:44:36 -0000 Received: from calderasystems.com (mpeterson@gomboo.calderalabs.com [216.250.131.136]) by ns.calderalabs.com (8.9.3/8.9.3) with ESMTP id QAA05946; Fri, 20 Oct 2000 16:44:32 -0600 Message-Id: <39F0CABA.EBB2FF87@calderasystems.com> Date: Fri, 20 Oct 2000 16:44:10 -0600 From: Matt Peterson X-Mailer: Mozilla 4.73C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en Mime-Version: 1.0 To: Eric Lammerts Cc: David Woodhouse , Andi Kleen , linux-kernel@vger.kernel.org Subject: Re: bind() allowed to non-local addresses References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Eric Lammerts wrote: > > On Fri, 20 Oct 2000, Matt Peterson wrote: > > Are you also suggesting that every other program that expects bind() to > > fail with EADDRNOTAVAIL are broken too? Just for fun, I greped all > > sources of software shipped in Caldera's distributions for instances of > > where a check is made for EADDRNOTAVAIL after a call to bind(). Guess > > what else besides Java is probably "broken" ... > > > > - lpng > > - bind 8.2 > > - automount > > - cvs > > - dhcpd > > - KDE > > - UCL mbone > > - ncftp > > - netatalk > > - nfsd > > - rexec > > - pppd > > - sendmail > > - xchat > > Just for fun I looked at the sources of cvs, ncftp, netatalk, rexec > and pppd. Guess what? None of them check for EADDRNOTAVAIL after a > call to bind(). I stand corrected. I double checked and not all of the above check EADDRNOTAVAIL after a bind(). My grep script was only smart enough to check for calls to bind() and EADDRNOTAVAIL . It turns out that EADDRNOTAVAIL is also a commonly checked return code to the ioctl(SIOCDIFADDR) which is not an issue because it probably does not follow the bind() code path through the kernel. > Cvs and pppd don't even call bind()! > > Get your facts straight, please. cvs-1.10.8/vms/rcmd.c:64: rs = bind(s, (struct sockaddr *)&local_isa, sizeof(local_isa)); cvs-1.10.8/vms/rcmd.c:79: rs = bind(s, (struct sockaddr *)&local_isa, sizeof(local_isa)); The cvs code does call bind, but you are right, it does not check rs for EADDRNOTAVAIL. pppd uses the ioctl() mentioned above. My apologies. I do not have time to go through an analize code to see if the success of bind when the interface is not known would cause any problems. My guess is that it would not because before binding the interface is looked up via ioctl() or gethostbyname(). Also as mentioned earlier in this thread, INADDR_ANY is also commonly used. The point I probably failed in making is that (right or wrong) many developers (because of tradition, documentation and various specs) expect bind() on a non-local address to fail. This is certainly the case with Sun and many authors of Sockets interface documentation. Anyway, I am through discussing the issue. We will probably use the sysctl solution posted by David Miller earlier in the thread with default bind() behavior reverted. -- Matthew Peterson Sr. Software Engineer Caldera Systems, Inc mpeterson@caldera.com  - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/