Re: bind() allowed to non-local addresses
> Does some one have a copy of the posix 1003.1g draft so this can be > verified. This is the kind of ammunition I was talking about earlier 1003.1g isnt what matters - SuS is. > that I would need to convince Sun to change the compatibility test > suite. However, if the 1003.1g draft even mentions failure with errno The compatibility test is broken from a pedantic point of view as your IP address can change dynamically between the query for it and the bind. In general though, bind() is assumed to do the checks and fail if non local and I agree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Does some one have a copy of the posix 1003.1g draft so this can be verified. This is the kind of ammunition I was talking about earlier 1003.1g isnt what matters - SuS is. that I would need to convince Sun to change the compatibility test suite. However, if the 1003.1g draft even mentions failure with errno The compatibility test is broken from a pedantic point of view as your IP address can change dynamically between the query for it and the bind. In general though, bind() is assumed to do the checks and fail if non local and I agree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Thu, Oct 19, 2000 at 12:30:52AM +0100, Alan Cox wrote: > > Assuming that my "compatibility argument" is not considered valid. What > > I really need is some good ammunition for going back to Sun to ask them > > to change the JRE spec -- like some significant kernel features or Linux > > applications that relies on this new bind() behavior. > > The XNS specification seems loose enough to allow the Linux behaviour. I don't I cant see why.. > think we should however adopt it as default behaviour. Programs that dont care > about addresses use INADDR_ANY. IMHO it does _not_ allow Linux behaviour: (Snipped from SUS) NAME bind - bind a name to a socket [...] RETURN VALUE Upon successful completion, bind() returns 0. Otherwise, -1 is returned and errno is set to indicate the error. ERRORS The bind() function will fail if: [...] [EADDRNOTAVAIL] The specified address is not available from the local machine. - So binding to a non-local ip address shouldnt be allowed because it "is not available from the local machine"; even if the machine has a dynamic ip. Alberto Bertogli [EMAIL PROTECTED] PGP signature
Re: bind() allowed to non-local addresses
On Thu, Oct 19, 2000 at 12:30:52AM +0100, Alan Cox wrote: Assuming that my "compatibility argument" is not considered valid. What I really need is some good ammunition for going back to Sun to ask them to change the JRE spec -- like some significant kernel features or Linux applications that relies on this new bind() behavior. The XNS specification seems loose enough to allow the Linux behaviour. I don't I cant see why.. think we should however adopt it as default behaviour. Programs that dont care about addresses use INADDR_ANY. IMHO it does _not_ allow Linux behaviour: (Snipped from SUS) NAME bind - bind a name to a socket [...] RETURN VALUE Upon successful completion, bind() returns 0. Otherwise, -1 is returned and errno is set to indicate the error. ERRORS The bind() function will fail if: [...] [EADDRNOTAVAIL] The specified address is not available from the local machine. - So binding to a non-local ip address shouldnt be allowed because it "is not available from the local machine"; even if the machine has a dynamic ip. Alberto Bertogli [EMAIL PROTECTED] PGP signature
RE: bind() allowed to non-local addresses
> [EMAIL PROTECTED] said: > > There is NOT a bug in the JVM code that handles java.net.DatagramSock > > et. Don't you find it a little compelling that the nearly identical > > JVM code passes the Java Compatibility test suite on Linux 2.2, > > Solaris, HPUX, SCO, and even Windows? > > If the JVM spec says that it 'MUST' fail when used on a non-local > address, > and the POSIX spec for bind does not say that it 'MUST' fail, then yes, > there is a bug in the JVM if it assumes that the two are compatible. "The bind() function will fail if: ... [EADDRNOTAVAIL] The specified address is not available from the local machine" -- SuS 2 Now I suppose we can argue about what it means for an address to be available, but I'd say the words "will fail" make that pretty clear. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Fri, 20 Oct 2000, Matt Peterson wrote: > cvs-1.10.8/vms/rcmd.c:64:rs = bind(s, (struct sockaddr *)_isa, ^^^ > sizeof(local_isa)); > cvs-1.10.8/vms/rcmd.c:79:rs = bind(s, (struct sockaddr *)_isa, ^^^ > sizeof(local_isa)); > > The cvs code does call bind, but you are right, it does not check rs for Unless something really terrible happened quite recently, Linux is _not_ VMS. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
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 *)_isa, sizeof(local_isa)); cvs-1.10.8/vms/rcmd.c:79:rs = bind(s, (struct sockaddr *)_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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
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(). Cvs and pppd don't even call bind()! Get your facts straight, please. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
[EMAIL PROTECTED] said: > There is NOT a bug in the JVM code that handles java.net.DatagramSock > et. Don't you find it a little compelling that the nearly identical > JVM code passes the Java Compatibility test suite on Linux 2.2, > Solaris, HPUX, SCO, and even Windows? If the JVM spec says that it 'MUST' fail when used on a non-local address, and the POSIX spec for bind does not say that it 'MUST' fail, then yes, there is a bug in the JVM if it assumes that the two are compatible. The fact that they just happen to behave the same in certain phases of the moon and on other operating systems is not relevant. We may decide that we want to pander to this brokenness, especially given the widespread nature of the false assumption that bind() will fail when given a non-local address. But that doesn't make the JVM non-broken. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > There is NOT a bug in the JVM code that handles java.net.DatagramSock > > et. Don't you find it a little compelling that the nearly identical > > JVM code passes the Java Compatibility test suite on Linux 2.2, > > Solaris, HPUX, SCO, and even Windows? > > If the JVM spec says that it 'MUST' fail when used on a non-local address, > and the POSIX spec for bind does not say that it 'MUST' fail, then yes, > there is a bug in the JVM if it assumes that the two are compatible. Does some one have a copy of the posix 1003.1g draft so this can be verified. This is the kind of ammunition I was talking about earlier that I would need to convince Sun to change the compatibility test suite. However, if the 1003.1g draft even mentions failure with errno set to EADDRNOTAVAIL in a "SHOULD" context, or if EADDRNOTAVAIL is mentioned at all as a error code for non-local bind, then I am afraid (given the widespread acceptance of bind() behavior), Sun will not change the test suite. > The fact that they just happen to behave the same in certain phases of the > moon and on other operating systems is not relevant. Huh? Please give me one example of a sockets implementation (besides Linux 2.4) of where bind() does not fail if an attempt is made to bind do a non-local address. Your telling me that developers who are used to seeing a consistant behavior across OSes will think that the difference in Linux 2.4 is irrelivant? I don't think so. > We may decide that we want to pander to this brokenness, especially given > the widespread nature of the false assumption that bind() will fail when > given a non-local address. But that doesn't make the JVM non-broken. > 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 ... but the Linux kernel... Nope, it's not broken. Lets email maintainers of all these projects and tell them that they have been mistaken all this time in their understanding how bind() should work and see what kind of a response we get. Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
David Woodhouse wrote: [EMAIL PROTECTED] said: There is NOT a bug in the JVM code that handles java.net.DatagramSock et. Don't you find it a little compelling that the nearly identical JVM code passes the Java Compatibility test suite on Linux 2.2, Solaris, HPUX, SCO, and even Windows? If the JVM spec says that it 'MUST' fail when used on a non-local address, and the POSIX spec for bind does not say that it 'MUST' fail, then yes, there is a bug in the JVM if it assumes that the two are compatible. Does some one have a copy of the posix 1003.1g draft so this can be verified. This is the kind of ammunition I was talking about earlier that I would need to convince Sun to change the compatibility test suite. However, if the 1003.1g draft even mentions failure with errno set to EADDRNOTAVAIL in a "SHOULD" context, or if EADDRNOTAVAIL is mentioned at all as a error code for non-local bind, then I am afraid (given the widespread acceptance of bind() behavior), Sun will not change the test suite. The fact that they just happen to behave the same in certain phases of the moon and on other operating systems is not relevant. Huh? Please give me one example of a sockets implementation (besides Linux 2.4) of where bind() does not fail if an attempt is made to bind do a non-local address. Your telling me that developers who are used to seeing a consistant behavior across OSes will think that the difference in Linux 2.4 is irrelivant? I don't think so. We may decide that we want to pander to this brokenness, especially given the widespread nature of the false assumption that bind() will fail when given a non-local address. But that doesn't make the JVM non-broken. 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 ... but the Linux kernel... Nope, it's not broken. Lets email maintainers of all these projects and tell them that they have been mistaken all this time in their understanding how bind() should work and see what kind of a response we get. Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
[EMAIL PROTECTED] said: There is NOT a bug in the JVM code that handles java.net.DatagramSock et. Don't you find it a little compelling that the nearly identical JVM code passes the Java Compatibility test suite on Linux 2.2, Solaris, HPUX, SCO, and even Windows? If the JVM spec says that it 'MUST' fail when used on a non-local address, and the POSIX spec for bind does not say that it 'MUST' fail, then yes, there is a bug in the JVM if it assumes that the two are compatible. The fact that they just happen to behave the same in certain phases of the moon and on other operating systems is not relevant. We may decide that we want to pander to this brokenness, especially given the widespread nature of the false assumption that bind() will fail when given a non-local address. But that doesn't make the JVM non-broken. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
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(). Cvs and pppd don't even call bind()! Get your facts straight, please. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Fri, 20 Oct 2000, Matt Peterson wrote: 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 Unless something really terrible happened quite recently, Linux is _not_ VMS. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: bind() allowed to non-local addresses
[EMAIL PROTECTED] said: There is NOT a bug in the JVM code that handles java.net.DatagramSock et. Don't you find it a little compelling that the nearly identical JVM code passes the Java Compatibility test suite on Linux 2.2, Solaris, HPUX, SCO, and even Windows? If the JVM spec says that it 'MUST' fail when used on a non-local address, and the POSIX spec for bind does not say that it 'MUST' fail, then yes, there is a bug in the JVM if it assumes that the two are compatible. "The bind() function will fail if: ... [EADDRNOTAVAIL] The specified address is not available from the local machine" -- SuS 2 Now I suppose we can argue about what it means for an address to be available, but I'd say the words "will fail" make that pretty clear. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: bind() allowed to non-local addresses
> Due ot this and other reasons I'm restoring the 2.2.x behavior by > default, but adding a sysctl so that systems using dynamic addressing > may elect to get the different bind() behavior. > > Later, > David S. Miller > [EMAIL PROTECTED] If a system uses dynamic addressing, binding to an IP that wasn't currently available would be useless, since the odds are that this address would never ever be available locally. In fact, if a machine had dynamic addressing, any code that bound to a specific local IP would never be able to be connected to once that IP was lost. It is only machines that have static IPs that might not currently be usable that would benefit from being able to bind to an address that wasn't currently local. In this case, the IP may return to the machine in the future. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Thu, Oct 19, 2000 at 10:45:02AM -0700, David S. Miller wrote: > To this I agree, but I cannot change the fact that this assumption > does exist in applications, so this is why I reverted the change. Would you accept a patch for an setsockopt to enable it again ? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Date:Thu, 19 Oct 2000 11:35:12 -0600 From: Matt Peterson <[EMAIL PROTECTED]> Don't you find it a little compelling that the nearly identical JVM code passes the Java Compatibility test suite on Linux 2.2, Solaris, HPUX, SCO, and even Windows? He is arguing that returning an error for a non-local address being sent to bind() is an implementation dependency and should not be something JRE absolutely requires. It is a dark corner of the BSD socket API and not written in stone anywhere, therefore it is bad to create a dependency upon it. To this I agree, but I cannot change the fact that this assumption does exist in applications, so this is why I reverted the change. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Thu, Oct 19, 2000 at 11:35:12AM -0600, Matt Peterson wrote: > Again, there is not a bug in the JVM's handling of > java.net.DatagramSocket(). I offered the JVM as an example only because > it is one application that I know of expects the standardized behavior > of bind(). The bind() behavior in Linux 2.4 is not an issue because it As Alan noted (and I just verified) Single Unix is vague enough that I think the Linux behaviour is compliant. The point is that the Sun test is broken on any machines with dynamic IP (=most machines on the internet today), because it could have any address available locally. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Andi Kleen wrote: > > > The JRE compliance tests have a test which makes sure that for a > > non-local addresses, bind() returns an error code, specifically > > -EADDRNOTAVAIL. > > Sounds like a bug that should be reported to Sun. > Hello? Send a bug to Sun? I don't see any logic here. I have traced through the Sun code all the way to the bind() call and through to the code in the kernel where the check for local interfaces is ignored. The JVM code path is VERY simple and ends up in a straightforward call to bind(). The same problem is easily reproduced in C code. There is NOT a bug in the JVM code that handles java.net.DatagramSocket. Don't you find it a little compelling that the nearly identical JVM code passes the Java Compatibility test suite on Linux 2.2, Solaris, HPUX, SCO, and even Windows? I might even go as far as to argue that there is not a problem with the JCK test suite either. The BSD Socket interface is documented. It may be a little shady in some areas (this being one of them) but at least the Sun test suite is expecting the documented (look at any man page or sockets reference) and long standing behavior of bind(). Any argument for changing the way bind() works needs to be able to stand up to the challenge of developers who are expecting bind() to behave the way it has for many years on many different platforms. Again, there is not a bug in the JVM's handling of java.net.DatagramSocket(). I offered the JVM as an example only because it is one application that I know of expects the standardized behavior of bind(). The bind() behavior in Linux 2.4 is not an issue because it affects Java only -- it is an issue because it also affects other applications and developers that are likewise expecting the traditional bind() behavior. -- Matthew Peterson Sr. Software Engineer Caldera Systems, Inc [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Thu, Oct 19, 2000 at 09:35:20AM -0700, David S. Miller wrote: >Date: Thu, 19 Oct 2000 18:30:22 +0200 >From: Andi Kleen <[EMAIL PROTECTED]> > >On Thu, Oct 19, 2000 at 09:02:12AM -0700, David S. Miller wrote: >> I'll say it again, if you have to make changes to apps/servers the >> feature does not make any sense. It must operate transparently or >> not at all. > >Why? Linux historically required always some changes to port programs >(e.g. UDP or accept error behaviour), one socket option more for some >very special cases is not too bad. > > So you propose people should be required to port working programs > between different Linux versions :-) They already need probably, e.g. to handle the new UDP error behaviour. Actually I did not propose to change the default behaviour (or rather not change it back), just to give the applications a way to set the behaviour *they* want as needed. > >> Therefore for the case you mention, for now they live without >> non-local binds, period. > >The other guy unfortunately did not describe how exactly the java >fails, so I cannot say what is worse. > > The JRE compliance tests have a test which makes sure that for a > non-local addresses, bind() returns an error code, specifically > -EADDRNOTAVAIL. Sounds like a bug that should be reported to Sun. > >> Andi, listen to what you propose, LD_PRELOAD hacks to force programs >> to set some magic socket option, and this is a real solution? > >LD_PRELOAD for binary only programs, patches for free software. > > User level binary compatability is everything, and why I have to > revert this change in the first place. I agree that the default should be 2.2 compatible. Adding the sysctl to magically break these applications would be probably bad (just remember ip_dynaddr and bind ;) > Java isn't the only case, I have in fact seen code which tries to > figure out whether XSHM pixmaps should be used by doing a bind() call > using the X server's address. Ok, sysctl to off (or better no sysctl and only the setsockopt to enable the more liberal behaviour) -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
"David S. Miller" <[EMAIL PROTECTED]> writes: >Date: Thu, 19 Oct 2000 09:07:57 -0600 >From: Matt Peterson <[EMAIL PROTECTED]> > >Hence, the JVM fails compatibility on Linux 2.4. > > Due ot this and other reasons I'm restoring the 2.2.x behavior by > default, but adding a sysctl so that systems using dynamic addressing > may elect to get the different bind() behavior. Thanks! Greetings Christoph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Date: Thu, 19 Oct 2000 18:30:22 +0200 From: Andi Kleen <[EMAIL PROTECTED]> On Thu, Oct 19, 2000 at 09:02:12AM -0700, David S. Miller wrote: > I'll say it again, if you have to make changes to apps/servers the > feature does not make any sense. It must operate transparently or > not at all. Why? Linux historically required always some changes to port programs (e.g. UDP or accept error behaviour), one socket option more for some very special cases is not too bad. So you propose people should be required to port working programs between different Linux versions :-) > Therefore for the case you mention, for now they live without > non-local binds, period. The other guy unfortunately did not describe how exactly the java fails, so I cannot say what is worse. The JRE compliance tests have a test which makes sure that for a non-local addresses, bind() returns an error code, specifically -EADDRNOTAVAIL. > Andi, listen to what you propose, LD_PRELOAD hacks to force programs > to set some magic socket option, and this is a real solution? LD_PRELOAD for binary only programs, patches for free software. User level binary compatability is everything, and why I have to revert this change in the first place. By your reasoning here, what I really should do is leave the 2.4.x "bind() allows non-local address" behavior and require people to use LD_PRELOAD based bind() wrappers which do the local address check before making the system call on 2.4.x systems. This would fix the JRE, and binary-only programs with this issue, right? > The current situation is one chooses between %100 anally compliant > Java or truly dynamic address friendly bind(). :-) Analy compliant java can use the setsockopt without LD_PRELOAD. No, existing binaries must function properly. Because there is precedence on our 2.2.x behavior, and we are knowledgable about the userland dependencies that do in fact exist. Java isn't the only case, I have in fact seen code which tries to figure out whether XSHM pixmaps should be used by doing a bind() call using the X server's address. It isn't pretty, but it's pretty much been around longer than Linux. :-) Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
In article <[EMAIL PROTECTED]> you wrote: > Thus spake David S. Miller ([EMAIL PROTECTED]): >> I'll say it again, if you have to make changes to apps/servers the >> feature does not make any sense. It must operate transparently or >> not at all. > There once was a socket file system which solved exactly this problem in > a nice and obvious way. If you wanted to allow user joe to bind to port > 80, you just do "chown joe /socks/80". > Whatever happened to that neat idea? It is in Linux 2.4? No, not really, but Linux 2.4 has a socket filesystem for internal use. It's FS_NOMOUNT|FS_SINGLE so you cannot mount it in userspace. With a little hacking it might do what you want. Christoph -- Always remember that you are unique. Just like everyone else. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Date:Thu, 19 Oct 2000 18:18:34 +0200 From: Felix von Leitner <[EMAIL PROTECTED]> There once was a socket file system which solved exactly this problem in a nice and obvious way. If you wanted to allow user joe to bind to port 80, you just do "chown joe /socks/80". I do not see how this would solve the problem at hand. We don't know what the socket will be ahead of time, nor what port number it will want to use, and what we want to control is what semantics bind() gets when called on that socket. It has nothing to do with specific port numbers, it has to do with BSD socket API assumptions held by some applications/libraries and not others. Another point I want to make, is that by definition Java servers will not work on systems using dyanmic IP addressing. This cannot be fixed, because it is a limitation implanted by creators of JRE conformance tests. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Thu, Oct 19, 2000 at 09:02:12AM -0700, David S. Miller wrote: >Date: Thu, 19 Oct 2000 17:56:17 +0200 >From: Andi Kleen <[EMAIL PROTECTED]> > >It would be better if there was at least an socket option to >overwrite the sysctl. What happens when you need both behaviours on >the same box in different applications ? (e.g. a dynamic IP box >running java and servers) With an socket option you could at least >use LD_PRELOAD for socket() or even fix the programs > > I'll say it again, if you have to make changes to apps/servers the > feature does not make any sense. It must operate transparently or > not at all. Why? Linux historically required always some changes to port programs (e.g. UDP or accept error behaviour), one socket option more for some very special cases is not too bad. > > Therefore for the case you mention, for now they live without > non-local binds, period. The other guy unfortunately did not describe how exactly the java fails, so I cannot say what is worse. > >Otherwise it'll repeat the ip_dynaddr-breaks-bind desaster, which >we're still chewing on. > > Andi, listen to what you propose, LD_PRELOAD hacks to force programs > to set some magic socket option, and this is a real solution? LD_PRELOAD for binary only programs, patches for free software. > > The current situation is one chooses between %100 anally compliant > Java or truly dynamic address friendly bind(). :-) Analy compliant java can use the setsockopt without LD_PRELOAD. > 3) Does not require userland changes, such as adding setsockopt >calls to applications or using equivalent LD_PRELOAD hacks. I don't understand why (3) is such a big problem for you. It strikes me as clean enough. You can still have the sysctl, just the application should be able to overwrite it. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Thus spake David S. Miller ([EMAIL PROTECTED]): > I'll say it again, if you have to make changes to apps/servers the > feature does not make any sense. It must operate transparently or > not at all. There once was a socket file system which solved exactly this problem in a nice and obvious way. If you wanted to allow user joe to bind to port 80, you just do "chown joe /socks/80". Whatever happened to that neat idea? If it was under /proc, I would be happy. Felix - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Date: Thu, 19 Oct 2000 17:56:17 +0200 From: Andi Kleen <[EMAIL PROTECTED]> It would be better if there was at least an socket option to overwrite the sysctl. What happens when you need both behaviours on the same box in different applications ? (e.g. a dynamic IP box running java and servers) With an socket option you could at least use LD_PRELOAD for socket() or even fix the programs I'll say it again, if you have to make changes to apps/servers the feature does not make any sense. It must operate transparently or not at all. Therefore for the case you mention, for now they live without non-local binds, period. Otherwise it'll repeat the ip_dynaddr-breaks-bind desaster, which we're still chewing on. Andi, listen to what you propose, LD_PRELOAD hacks to force programs to set some magic socket option, and this is a real solution? The current situation is one chooses between %100 anally compliant Java or truly dynamic address friendly bind(). :-) So cope with this or, propose a solution that: 1) Solves the dynamic address bind() problem. 2) Does not break existing applications expectations of bind() behavior for non-local addresses. (As a side note, I think it is a mistake for the Java folks to base JRE compliance upon dark corners of BSD socket API behavior) 3) Does not require userland changes, such as adding setsockopt calls to applications or using equivalent LD_PRELOAD hacks. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Thu, Oct 19, 2000 at 08:17:28AM -0700, David S. Miller wrote: >Date: Thu, 19 Oct 2000 09:23:26 -0600 >From: Matt Peterson <[EMAIL PROTECTED]> > >Have you thought about an SOL_SOCKET level socket option? It might >be more intuitive for programmers than an ioctl and could be >documented with sockets where it will be used. > > Where did I say "ioctl"? > > The solution I am implementing is neither a socket option nor an > ioctl, it's a system-wide sysctl. > > If people need to change code in applications to get the "servers > start even when dynamic address is temporarily down" behavior, the > feature makes no sense. The whole point was to make it totally > transparent to the apps. > > This is why a sysctl is how I am allowing the new behavior. A person > will be able to go: > > ! echo "1" >/proc/sys/ipv4/ip_nonlocal_bind > > and be done with it. And like I said it will be "0" by default, > thus giving the 2.2.x behavior. It would be better if there was at least an socket option to overwrite the sysctl. What happens when you need both behaviours on the same box in different applications ? (e.g. a dynamic IP box running java and servers) With an socket option you could at least use LD_PRELOAD for socket() or even fix the programs Otherwise it'll repeat the ip_dynaddr-breaks-bind desaster, which we're still chewing on. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
"David S. Miller" wrote: > >Date: Thu, 19 Oct 2000 09:23:26 -0600 >From: Matt Peterson <[EMAIL PROTECTED]> > >Have you thought about an SOL_SOCKET level socket option? It might >be more intuitive for programmers than an ioctl and could be >documented with sockets where it will be used. > > Where did I say "ioctl"? Sorry, I've had ioctl on the brain lately. Yes, sysctl is a good solution. -- Matthew Peterson Sr. Software Engineer Caldera Systems, Inc [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Date: Thu, 19 Oct 2000 09:23:26 -0600 From: Matt Peterson <[EMAIL PROTECTED]> Have you thought about an SOL_SOCKET level socket option? It might be more intuitive for programmers than an ioctl and could be documented with sockets where it will be used. Where did I say "ioctl"? The solution I am implementing is neither a socket option nor an ioctl, it's a system-wide sysctl. If people need to change code in applications to get the "servers start even when dynamic address is temporarily down" behavior, the feature makes no sense. The whole point was to make it totally transparent to the apps. This is why a sysctl is how I am allowing the new behavior. A person will be able to go: ! echo "1" >/proc/sys/ipv4/ip_nonlocal_bind and be done with it. And like I said it will be "0" by default, thus giving the 2.2.x behavior. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
"David S. Miller" wrote: > >Date: Thu, 19 Oct 2000 09:07:57 -0600 >From: Matt Peterson <[EMAIL PROTECTED]> > >Hence, the JVM fails compatibility on Linux 2.4. > > Due ot this and other reasons I'm restoring the 2.2.x behavior by > default, but adding a sysctl so that systems using dynamic addressing > may elect to get the different bind() behavior. > > Later, > David S. Miller > [EMAIL PROTECTED] Have you thought about an SOL_SOCKET level socket option? It might be more intuitive for programmers than an ioctl and could be documented with sockets where it will be used. Again, we would run into compatibility issues with other Sockets implementations, but traditionally the sockopt funtionality between implementations are (sorta) expected to vary. Just an idea. -- Matthew Peterson Sr. Software Engineer Caldera Systems, Inc [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Date: Thu, 19 Oct 2000 09:07:57 -0600 From: Matt Peterson <[EMAIL PROTECTED]> Hence, the JVM fails compatibility on Linux 2.4. Due ot this and other reasons I'm restoring the 2.2.x behavior by default, but adding a sysctl so that systems using dynamic addressing may elect to get the different bind() behavior. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
"David S. Miller" wrote: > >Date:Wed, 18 Oct 2000 17:20:22 -0600 >From: Matt Peterson <[EMAIL PROTECTED]> > >Assuming that my "compatibility argument" is not considered valid. >What I really need is some good ammunition for going back to Sun to >ask them to change the JRE spec -- like some significant kernel >features or Linux applications that relies on this new bind() >behavior. > > How about first finding out why their buggy JRE detects whether an > address is local by trying to bind() to it :-) > > Really, when an application feeds a specific address into bind() it > must have good reason for selecting it. All I want to know in this > specific instance, is why Sun's JRE is sending non-local addresses > into bind(), that's all. > > Later, > David S. Miller > [EMAIL PROTECTED] The JVM is simply running the appropriate native code for bytecodes that represents the java.net.DatagramSocket(int port, InetAddress laddr) constructor. Documentation for this constructor reads "Creates a datagram socket, bound to the specified local address." What do you expect the JVM to will do? It trys to bind() to the supplied address and port. There are no bugs here. java.net.DatagramSocket is just trying to emulate the expected Sockets interface behavior. The Sun JVM compatibility test suite appropriately includes some test to ensure that error conditions are handled correctly. Supplying a non-local IP address to bind() is an error condition. Hence, the JVM fails compatibility on Linux 2.4. -- Matthew Peterson Sr. Software Engineer Caldera Systems, Inc [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Horst von Brand wrote: > > > How about first finding out why their buggy JRE detects whether an > > > address is local by trying to bind() to it :-) > > > I don't know why the JRE does it, but I've seen that sort of thing used > > to decide whether to try X shared memory. > > Could you explain the logic behid that?! (a) connect to DISPLAY (b) ask for MIT-SHM extension; answer = yes (c) create shared memory segment (d) tell X server to open shared memory segment (e) oops, X server connected to wrong segment on remote machine! Checking for a local X connection was a buggy way to avoid that. The right way, of course, is to fill your new SHM segment with some random number, get the X server to connect, and read the contents over the X connection to see if you and the server found the same SHM segment. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
[EMAIL PROTECTED] writes: > Hello! > > > Using linux-2.4.0-test9, bind() incorrectly allows a bind to a non-local > > address. The correct behavior should be a return code of -1 with errno > > set to EADDRNOTAVAIL. > > You can bind to any address, it is your right. You will not able > to receive on or to send from such socket until address will become > really local. > > Such bind is allowed because the address can be dynamic. > Nobody wants that a service did not start only because > the moment of start address was temporarily off-line. No, please revert it or make it configurable. It may be nice for mobile devices, but not for servers. There are programs out there which test via bind() if it is a local address. Greetings Christoph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
[EMAIL PROTECTED] writes: Hello! Using linux-2.4.0-test9, bind() incorrectly allows a bind to a non-local address. The correct behavior should be a return code of -1 with errno set to EADDRNOTAVAIL. You can bind to any address, it is your right. You will not able to receive on or to send from such socket until address will become really local. Such bind is allowed because the address can be dynamic. Nobody wants that a service did not start only because the moment of start address was temporarily off-line. No, please revert it or make it configurable. It may be nice for mobile devices, but not for servers. There are programs out there which test via bind() if it is a local address. Greetings Christoph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Horst von Brand wrote: How about first finding out why their buggy JRE detects whether an address is local by trying to bind() to it :-) I don't know why the JRE does it, but I've seen that sort of thing used to decide whether to try X shared memory. Could you explain the logic behid that?! (a) connect to DISPLAY (b) ask for MIT-SHM extension; answer = yes (c) create shared memory segment (d) tell X server to open shared memory segment (e) oops, X server connected to wrong segment on remote machine! Checking for a local X connection was a buggy way to avoid that. The right way, of course, is to fill your new SHM segment with some random number, get the X server to connect, and read the contents over the X connection to see if you and the server found the same SHM segment. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
"David S. Miller" wrote: Date:Wed, 18 Oct 2000 17:20:22 -0600 From: Matt Peterson [EMAIL PROTECTED] Assuming that my "compatibility argument" is not considered valid. What I really need is some good ammunition for going back to Sun to ask them to change the JRE spec -- like some significant kernel features or Linux applications that relies on this new bind() behavior. How about first finding out why their buggy JRE detects whether an address is local by trying to bind() to it :-) Really, when an application feeds a specific address into bind() it must have good reason for selecting it. All I want to know in this specific instance, is why Sun's JRE is sending non-local addresses into bind(), that's all. Later, David S. Miller [EMAIL PROTECTED] The JVM is simply running the appropriate native code for bytecodes that represents the java.net.DatagramSocket(int port, InetAddress laddr) constructor. Documentation for this constructor reads "Creates a datagram socket, bound to the specified local address." What do you expect the JVM to will do? It trys to bind() to the supplied address and port. There are no bugs here. java.net.DatagramSocket is just trying to emulate the expected Sockets interface behavior. The Sun JVM compatibility test suite appropriately includes some test to ensure that error conditions are handled correctly. Supplying a non-local IP address to bind() is an error condition. Hence, the JVM fails compatibility on Linux 2.4. -- Matthew Peterson Sr. Software Engineer Caldera Systems, Inc [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Date: Thu, 19 Oct 2000 09:07:57 -0600 From: Matt Peterson [EMAIL PROTECTED] Hence, the JVM fails compatibility on Linux 2.4. Due ot this and other reasons I'm restoring the 2.2.x behavior by default, but adding a sysctl so that systems using dynamic addressing may elect to get the different bind() behavior. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
"David S. Miller" wrote: Date: Thu, 19 Oct 2000 09:07:57 -0600 From: Matt Peterson [EMAIL PROTECTED] Hence, the JVM fails compatibility on Linux 2.4. Due ot this and other reasons I'm restoring the 2.2.x behavior by default, but adding a sysctl so that systems using dynamic addressing may elect to get the different bind() behavior. Later, David S. Miller [EMAIL PROTECTED] Have you thought about an SOL_SOCKET level socket option? It might be more intuitive for programmers than an ioctl and could be documented with sockets where it will be used. Again, we would run into compatibility issues with other Sockets implementations, but traditionally the sockopt funtionality between implementations are (sorta) expected to vary. Just an idea. -- Matthew Peterson Sr. Software Engineer Caldera Systems, Inc [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Date: Thu, 19 Oct 2000 09:23:26 -0600 From: Matt Peterson [EMAIL PROTECTED] Have you thought about an SOL_SOCKET level socket option? It might be more intuitive for programmers than an ioctl and could be documented with sockets where it will be used. Where did I say "ioctl"? The solution I am implementing is neither a socket option nor an ioctl, it's a system-wide sysctl. If people need to change code in applications to get the "servers start even when dynamic address is temporarily down" behavior, the feature makes no sense. The whole point was to make it totally transparent to the apps. This is why a sysctl is how I am allowing the new behavior. A person will be able to go: ! echo "1" /proc/sys/ipv4/ip_nonlocal_bind and be done with it. And like I said it will be "0" by default, thus giving the 2.2.x behavior. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
"David S. Miller" wrote: Date: Thu, 19 Oct 2000 09:23:26 -0600 From: Matt Peterson [EMAIL PROTECTED] Have you thought about an SOL_SOCKET level socket option? It might be more intuitive for programmers than an ioctl and could be documented with sockets where it will be used. Where did I say "ioctl"? Sorry, I've had ioctl on the brain lately. Yes, sysctl is a good solution. -- Matthew Peterson Sr. Software Engineer Caldera Systems, Inc [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Thu, Oct 19, 2000 at 08:17:28AM -0700, David S. Miller wrote: Date: Thu, 19 Oct 2000 09:23:26 -0600 From: Matt Peterson [EMAIL PROTECTED] Have you thought about an SOL_SOCKET level socket option? It might be more intuitive for programmers than an ioctl and could be documented with sockets where it will be used. Where did I say "ioctl"? The solution I am implementing is neither a socket option nor an ioctl, it's a system-wide sysctl. If people need to change code in applications to get the "servers start even when dynamic address is temporarily down" behavior, the feature makes no sense. The whole point was to make it totally transparent to the apps. This is why a sysctl is how I am allowing the new behavior. A person will be able to go: ! echo "1" /proc/sys/ipv4/ip_nonlocal_bind and be done with it. And like I said it will be "0" by default, thus giving the 2.2.x behavior. It would be better if there was at least an socket option to overwrite the sysctl. What happens when you need both behaviours on the same box in different applications ? (e.g. a dynamic IP box running java and servers) With an socket option you could at least use LD_PRELOAD for socket() or even fix the programs Otherwise it'll repeat the ip_dynaddr-breaks-bind desaster, which we're still chewing on. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Date: Thu, 19 Oct 2000 17:56:17 +0200 From: Andi Kleen [EMAIL PROTECTED] It would be better if there was at least an socket option to overwrite the sysctl. What happens when you need both behaviours on the same box in different applications ? (e.g. a dynamic IP box running java and servers) With an socket option you could at least use LD_PRELOAD for socket() or even fix the programs I'll say it again, if you have to make changes to apps/servers the feature does not make any sense. It must operate transparently or not at all. Therefore for the case you mention, for now they live without non-local binds, period. Otherwise it'll repeat the ip_dynaddr-breaks-bind desaster, which we're still chewing on. Andi, listen to what you propose, LD_PRELOAD hacks to force programs to set some magic socket option, and this is a real solution? The current situation is one chooses between %100 anally compliant Java or truly dynamic address friendly bind(). :-) So cope with this or, propose a solution that: 1) Solves the dynamic address bind() problem. 2) Does not break existing applications expectations of bind() behavior for non-local addresses. (As a side note, I think it is a mistake for the Java folks to base JRE compliance upon dark corners of BSD socket API behavior) 3) Does not require userland changes, such as adding setsockopt calls to applications or using equivalent LD_PRELOAD hacks. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Thus spake David S. Miller ([EMAIL PROTECTED]): I'll say it again, if you have to make changes to apps/servers the feature does not make any sense. It must operate transparently or not at all. There once was a socket file system which solved exactly this problem in a nice and obvious way. If you wanted to allow user joe to bind to port 80, you just do "chown joe /socks/80". Whatever happened to that neat idea? If it was under /proc, I would be happy. Felix - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Thu, Oct 19, 2000 at 09:02:12AM -0700, David S. Miller wrote: Date: Thu, 19 Oct 2000 17:56:17 +0200 From: Andi Kleen [EMAIL PROTECTED] It would be better if there was at least an socket option to overwrite the sysctl. What happens when you need both behaviours on the same box in different applications ? (e.g. a dynamic IP box running java and servers) With an socket option you could at least use LD_PRELOAD for socket() or even fix the programs I'll say it again, if you have to make changes to apps/servers the feature does not make any sense. It must operate transparently or not at all. Why? Linux historically required always some changes to port programs (e.g. UDP or accept error behaviour), one socket option more for some very special cases is not too bad. Therefore for the case you mention, for now they live without non-local binds, period. The other guy unfortunately did not describe how exactly the java fails, so I cannot say what is worse. Otherwise it'll repeat the ip_dynaddr-breaks-bind desaster, which we're still chewing on. Andi, listen to what you propose, LD_PRELOAD hacks to force programs to set some magic socket option, and this is a real solution? LD_PRELOAD for binary only programs, patches for free software. The current situation is one chooses between %100 anally compliant Java or truly dynamic address friendly bind(). :-) Analy compliant java can use the setsockopt without LD_PRELOAD. 3) Does not require userland changes, such as adding setsockopt calls to applications or using equivalent LD_PRELOAD hacks. I don't understand why (3) is such a big problem for you. It strikes me as clean enough. You can still have the sysctl, just the application should be able to overwrite it. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Date:Thu, 19 Oct 2000 18:18:34 +0200 From: Felix von Leitner [EMAIL PROTECTED] There once was a socket file system which solved exactly this problem in a nice and obvious way. If you wanted to allow user joe to bind to port 80, you just do "chown joe /socks/80". I do not see how this would solve the problem at hand. We don't know what the socket will be ahead of time, nor what port number it will want to use, and what we want to control is what semantics bind() gets when called on that socket. It has nothing to do with specific port numbers, it has to do with BSD socket API assumptions held by some applications/libraries and not others. Another point I want to make, is that by definition Java servers will not work on systems using dyanmic IP addressing. This cannot be fixed, because it is a limitation implanted by creators of JRE conformance tests. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
In article [EMAIL PROTECTED] you wrote: Thus spake David S. Miller ([EMAIL PROTECTED]): I'll say it again, if you have to make changes to apps/servers the feature does not make any sense. It must operate transparently or not at all. There once was a socket file system which solved exactly this problem in a nice and obvious way. If you wanted to allow user joe to bind to port 80, you just do "chown joe /socks/80". Whatever happened to that neat idea? It is in Linux 2.4? No, not really, but Linux 2.4 has a socket filesystem for internal use. It's FS_NOMOUNT|FS_SINGLE so you cannot mount it in userspace. With a little hacking it might do what you want. Christoph -- Always remember that you are unique. Just like everyone else. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
"David S. Miller" [EMAIL PROTECTED] writes: Date: Thu, 19 Oct 2000 09:07:57 -0600 From: Matt Peterson [EMAIL PROTECTED] Hence, the JVM fails compatibility on Linux 2.4. Due ot this and other reasons I'm restoring the 2.2.x behavior by default, but adding a sysctl so that systems using dynamic addressing may elect to get the different bind() behavior. Thanks! Greetings Christoph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Date: Thu, 19 Oct 2000 18:30:22 +0200 From: Andi Kleen [EMAIL PROTECTED] On Thu, Oct 19, 2000 at 09:02:12AM -0700, David S. Miller wrote: I'll say it again, if you have to make changes to apps/servers the feature does not make any sense. It must operate transparently or not at all. Why? Linux historically required always some changes to port programs (e.g. UDP or accept error behaviour), one socket option more for some very special cases is not too bad. So you propose people should be required to port working programs between different Linux versions :-) Therefore for the case you mention, for now they live without non-local binds, period. The other guy unfortunately did not describe how exactly the java fails, so I cannot say what is worse. The JRE compliance tests have a test which makes sure that for a non-local addresses, bind() returns an error code, specifically -EADDRNOTAVAIL. Andi, listen to what you propose, LD_PRELOAD hacks to force programs to set some magic socket option, and this is a real solution? LD_PRELOAD for binary only programs, patches for free software. User level binary compatability is everything, and why I have to revert this change in the first place. By your reasoning here, what I really should do is leave the 2.4.x "bind() allows non-local address" behavior and require people to use LD_PRELOAD based bind() wrappers which do the local address check before making the system call on 2.4.x systems. This would fix the JRE, and binary-only programs with this issue, right? The current situation is one chooses between %100 anally compliant Java or truly dynamic address friendly bind(). :-) Analy compliant java can use the setsockopt without LD_PRELOAD. No, existing binaries must function properly. Because there is precedence on our 2.2.x behavior, and we are knowledgable about the userland dependencies that do in fact exist. Java isn't the only case, I have in fact seen code which tries to figure out whether XSHM pixmaps should be used by doing a bind() call using the X server's address. It isn't pretty, but it's pretty much been around longer than Linux. :-) Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Thu, Oct 19, 2000 at 09:35:20AM -0700, David S. Miller wrote: Date: Thu, 19 Oct 2000 18:30:22 +0200 From: Andi Kleen [EMAIL PROTECTED] On Thu, Oct 19, 2000 at 09:02:12AM -0700, David S. Miller wrote: I'll say it again, if you have to make changes to apps/servers the feature does not make any sense. It must operate transparently or not at all. Why? Linux historically required always some changes to port programs (e.g. UDP or accept error behaviour), one socket option more for some very special cases is not too bad. So you propose people should be required to port working programs between different Linux versions :-) They already need probably, e.g. to handle the new UDP error behaviour. Actually I did not propose to change the default behaviour (or rather not change it back), just to give the applications a way to set the behaviour *they* want as needed. Therefore for the case you mention, for now they live without non-local binds, period. The other guy unfortunately did not describe how exactly the java fails, so I cannot say what is worse. The JRE compliance tests have a test which makes sure that for a non-local addresses, bind() returns an error code, specifically -EADDRNOTAVAIL. Sounds like a bug that should be reported to Sun. Andi, listen to what you propose, LD_PRELOAD hacks to force programs to set some magic socket option, and this is a real solution? LD_PRELOAD for binary only programs, patches for free software. User level binary compatability is everything, and why I have to revert this change in the first place. I agree that the default should be 2.2 compatible. Adding the sysctl to magically break these applications would be probably bad (just remember ip_dynaddr and bind ;) Java isn't the only case, I have in fact seen code which tries to figure out whether XSHM pixmaps should be used by doing a bind() call using the X server's address. Ok, sysctl to off (or better no sysctl and only the setsockopt to enable the more liberal behaviour) -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Andi Kleen wrote: The JRE compliance tests have a test which makes sure that for a non-local addresses, bind() returns an error code, specifically -EADDRNOTAVAIL. Sounds like a bug that should be reported to Sun. Hello? Send a bug to Sun? I don't see any logic here. I have traced through the Sun code all the way to the bind() call and through to the code in the kernel where the check for local interfaces is ignored. The JVM code path is VERY simple and ends up in a straightforward call to bind(). The same problem is easily reproduced in C code. There is NOT a bug in the JVM code that handles java.net.DatagramSocket. Don't you find it a little compelling that the nearly identical JVM code passes the Java Compatibility test suite on Linux 2.2, Solaris, HPUX, SCO, and even Windows? I might even go as far as to argue that there is not a problem with the JCK test suite either. The BSD Socket interface is documented. It may be a little shady in some areas (this being one of them) but at least the Sun test suite is expecting the documented (look at any man page or sockets reference) and long standing behavior of bind(). Any argument for changing the way bind() works needs to be able to stand up to the challenge of developers who are expecting bind() to behave the way it has for many years on many different platforms. Again, there is not a bug in the JVM's handling of java.net.DatagramSocket(). I offered the JVM as an example only because it is one application that I know of expects the standardized behavior of bind(). The bind() behavior in Linux 2.4 is not an issue because it affects Java only -- it is an issue because it also affects other applications and developers that are likewise expecting the traditional bind() behavior. -- Matthew Peterson Sr. Software Engineer Caldera Systems, Inc [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Thu, Oct 19, 2000 at 11:35:12AM -0600, Matt Peterson wrote: Again, there is not a bug in the JVM's handling of java.net.DatagramSocket(). I offered the JVM as an example only because it is one application that I know of expects the standardized behavior of bind(). The bind() behavior in Linux 2.4 is not an issue because it As Alan noted (and I just verified) Single Unix is vague enough that I think the Linux behaviour is compliant. The point is that the Sun test is broken on any machines with dynamic IP (=most machines on the internet today), because it could have any address available locally. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Date:Thu, 19 Oct 2000 11:35:12 -0600 From: Matt Peterson [EMAIL PROTECTED] Don't you find it a little compelling that the nearly identical JVM code passes the Java Compatibility test suite on Linux 2.2, Solaris, HPUX, SCO, and even Windows? He is arguing that returning an error for a non-local address being sent to bind() is an implementation dependency and should not be something JRE absolutely requires. It is a dark corner of the BSD socket API and not written in stone anywhere, therefore it is bad to create a dependency upon it. To this I agree, but I cannot change the fact that this assumption does exist in applications, so this is why I reverted the change. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Thu, Oct 19, 2000 at 10:45:02AM -0700, David S. Miller wrote: To this I agree, but I cannot change the fact that this assumption does exist in applications, so this is why I reverted the change. Would you accept a patch for an setsockopt to enable it again ? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: bind() allowed to non-local addresses
Due ot this and other reasons I'm restoring the 2.2.x behavior by default, but adding a sysctl so that systems using dynamic addressing may elect to get the different bind() behavior. Later, David S. Miller [EMAIL PROTECTED] If a system uses dynamic addressing, binding to an IP that wasn't currently available would be useless, since the odds are that this address would never ever be available locally. In fact, if a machine had dynamic addressing, any code that bound to a specific local IP would never be able to be connected to once that IP was lost. It is only machines that have static IPs that might not currently be usable that would benefit from being able to bind to an address that wasn't currently local. In this case, the IP may return to the machine in the future. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Followup to: <[EMAIL PROTECTED]> By author:"David S. Miller" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > How about first finding out why their buggy JRE detects whether an > address is local by trying to bind() to it :-) > > Really, when an application feeds a specific address into bind() it > must have good reason for selecting it. All I want to know in this > specific instance, is why Sun's JRE is sending non-local addresses > into bind(), that's all. > autofs uses the following algorithm to determine if an address is local: connect to it as the remote end using a datagram socket (so there isn't any actual network traffic). If the LOCAL address (which is picked by the system) and the REMOTE address (the address under test) are identical afterwards, the address is local. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Jamie Lokier <[EMAIL PROTECTED]> said: > David S. Miller wrote: > > How about first finding out why their buggy JRE detects whether an > > address is local by trying to bind() to it :-) > I don't know why the JRE does it, but I've seen that sort of thing used > to decide whether to try X shared memory. Could you explain the logic behid that?! -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: bind() allowed to non-local addresses
> The XNS specification seems loose enough to allow the Linux > behaviour. I don't > think we should however adopt it as default behaviour. Programs > that dont care > about addresses use INADDR_ANY. > > Alan I worry that an application may use ability to bind to determine whether an address is local or not in an area with security impact. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
David S. Miller wrote: > How about first finding out why their buggy JRE detects whether an > address is local by trying to bind() to it :-) I don't know why the JRE does it, but I've seen that sort of thing used to decide whether to try X shared memory. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
> Assuming that my "compatibility argument" is not considered valid. What > I really need is some good ammunition for going back to Sun to ask them > to change the JRE spec -- like some significant kernel features or Linux > applications that relies on this new bind() behavior. The XNS specification seems loose enough to allow the Linux behaviour. I don't think we should however adopt it as default behaviour. Programs that dont care about addresses use INADDR_ANY. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Date:Wed, 18 Oct 2000 17:20:22 -0600 From: Matt Peterson <[EMAIL PROTECTED]> Assuming that my "compatibility argument" is not considered valid. What I really need is some good ammunition for going back to Sun to ask them to change the JRE spec -- like some significant kernel features or Linux applications that relies on this new bind() behavior. How about first finding out why their buggy JRE detects whether an address is local by trying to bind() to it :-) Really, when an application feeds a specific address into bind() it must have good reason for selecting it. All I want to know in this specific instance, is why Sun's JRE is sending non-local addresses into bind(), that's all. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Wed, Oct 18, 2000 at 05:20:22PM -0600, Matt Peterson wrote: > Your argument for supporting dynamic interfaces is valid, I really like > the idea of being able to bind to an interface that is not up yet. I can > definitely see where this would be helpful -- too bad is is not part of > the spec. What I don't like about it is that it may break existing > applications. Is the Socket spec so loose that Linux 2.4 can be > comfortable in its current condition? I hope not. > > Since it is possible that this "bug" un-repairably breaks the > portability of our application (a Java virtual machine) to the new > kernel, I suspect that there may be other applications that it breaks > too. Could you explain how the JVM breaks exactly ? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
[EMAIL PROTECTED] wrote: > > Hello! > > > Using linux-2.4.0-test9, bind() incorrectly allows a bind to a non-local > > address. The correct behavior should be a return code of -1 with errno > > set to EADDRNOTAVAIL. > > You can bind to any address, it is your right. You will not able > to receive on or to send from such socket until address will become > really local. > > Such bind is allowed because the address can be dynamic. > Nobody wants that a service did not start only because > the moment of start address was temporarily off-line. > > Alexey This issue here is mostly one of compatibility and standards compliance. You may not be able to obtain the Posix draft P1003.1g but you should be able to see XNS Issue 5.2 which defines the industry-standard Open Systems interfaces to communications services (including Sockets). You might be required to supply name and email address to see the free online copy: http://www.opengroup.org/onlinepubs/009619199/bind.htm#tagcjh_03_03 According to the specs and numerous implementations, looks like the way bind() is supposed to work is that it returns EADDRNOTAVAIL if the specified address is not available from the local machine rather than waiting for a recv() or send() to fail. Many developers working on software ports have felt the pain of loose interpretations of the Sockets interface. This divergence would add yet another headache. Your argument for supporting dynamic interfaces is valid, I really like the idea of being able to bind to an interface that is not up yet. I can definitely see where this would be helpful -- too bad is is not part of the spec. What I don't like about it is that it may break existing applications. Is the Socket spec so loose that Linux 2.4 can be comfortable in its current condition? I hope not. Since it is possible that this "bug" un-repairably breaks the portability of our application (a Java virtual machine) to the new kernel, I suspect that there may be other applications that it breaks too. Assuming that my "compatibility argument" is not considered valid. What I really need is some good ammunition for going back to Sun to ask them to change the JRE spec -- like some significant kernel features or Linux applications that relies on this new bind() behavior. -- Matthew Peterson Sr. Software Engineer Caldera Systems, Inc [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
[EMAIL PROTECTED] wrote: Hello! Using linux-2.4.0-test9, bind() incorrectly allows a bind to a non-local address. The correct behavior should be a return code of -1 with errno set to EADDRNOTAVAIL. You can bind to any address, it is your right. You will not able to receive on or to send from such socket until address will become really local. Such bind is allowed because the address can be dynamic. Nobody wants that a service did not start only because the moment of start address was temporarily off-line. Alexey This issue here is mostly one of compatibility and standards compliance. You may not be able to obtain the Posix draft P1003.1g but you should be able to see XNS Issue 5.2 which defines the industry-standard Open Systems interfaces to communications services (including Sockets). You might be required to supply name and email address to see the free online copy: http://www.opengroup.org/onlinepubs/009619199/bind.htm#tagcjh_03_03 According to the specs and numerous implementations, looks like the way bind() is supposed to work is that it returns EADDRNOTAVAIL if the specified address is not available from the local machine rather than waiting for a recv() or send() to fail. Many developers working on software ports have felt the pain of loose interpretations of the Sockets interface. This divergence would add yet another headache. Your argument for supporting dynamic interfaces is valid, I really like the idea of being able to bind to an interface that is not up yet. I can definitely see where this would be helpful -- too bad is is not part of the spec. What I don't like about it is that it may break existing applications. Is the Socket spec so loose that Linux 2.4 can be comfortable in its current condition? I hope not. Since it is possible that this "bug" un-repairably breaks the portability of our application (a Java virtual machine) to the new kernel, I suspect that there may be other applications that it breaks too. Assuming that my "compatibility argument" is not considered valid. What I really need is some good ammunition for going back to Sun to ask them to change the JRE spec -- like some significant kernel features or Linux applications that relies on this new bind() behavior. -- Matthew Peterson Sr. Software Engineer Caldera Systems, Inc [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Wed, Oct 18, 2000 at 05:20:22PM -0600, Matt Peterson wrote: Your argument for supporting dynamic interfaces is valid, I really like the idea of being able to bind to an interface that is not up yet. I can definitely see where this would be helpful -- too bad is is not part of the spec. What I don't like about it is that it may break existing applications. Is the Socket spec so loose that Linux 2.4 can be comfortable in its current condition? I hope not. Since it is possible that this "bug" un-repairably breaks the portability of our application (a Java virtual machine) to the new kernel, I suspect that there may be other applications that it breaks too. Could you explain how the JVM breaks exactly ? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Assuming that my "compatibility argument" is not considered valid. What I really need is some good ammunition for going back to Sun to ask them to change the JRE spec -- like some significant kernel features or Linux applications that relies on this new bind() behavior. The XNS specification seems loose enough to allow the Linux behaviour. I don't think we should however adopt it as default behaviour. Programs that dont care about addresses use INADDR_ANY. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Date:Wed, 18 Oct 2000 17:20:22 -0600 From: Matt Peterson [EMAIL PROTECTED] Assuming that my "compatibility argument" is not considered valid. What I really need is some good ammunition for going back to Sun to ask them to change the JRE spec -- like some significant kernel features or Linux applications that relies on this new bind() behavior. How about first finding out why their buggy JRE detects whether an address is local by trying to bind() to it :-) Really, when an application feeds a specific address into bind() it must have good reason for selecting it. All I want to know in this specific instance, is why Sun's JRE is sending non-local addresses into bind(), that's all. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
David S. Miller wrote: How about first finding out why their buggy JRE detects whether an address is local by trying to bind() to it :-) I don't know why the JRE does it, but I've seen that sort of thing used to decide whether to try X shared memory. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: bind() allowed to non-local addresses
The XNS specification seems loose enough to allow the Linux behaviour. I don't think we should however adopt it as default behaviour. Programs that dont care about addresses use INADDR_ANY. Alan I worry that an application may use ability to bind to determine whether an address is local or not in an area with security impact. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Jamie Lokier [EMAIL PROTECTED] said: David S. Miller wrote: How about first finding out why their buggy JRE detects whether an address is local by trying to bind() to it :-) I don't know why the JRE does it, but I've seen that sort of thing used to decide whether to try X shared memory. Could you explain the logic behid that?! -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Followup to: [EMAIL PROTECTED] By author:"David S. Miller" [EMAIL PROTECTED] In newsgroup: linux.dev.kernel How about first finding out why their buggy JRE detects whether an address is local by trying to bind() to it :-) Really, when an application feeds a specific address into bind() it must have good reason for selecting it. All I want to know in this specific instance, is why Sun's JRE is sending non-local addresses into bind(), that's all. autofs uses the following algorithm to determine if an address is local: connect to it as the remote end using a datagram socket (so there isn't any actual network traffic). If the LOCAL address (which is picked by the system) and the REMOTE address (the address under test) are identical afterwards, the address is local. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
