Unfortunately it's not possible to check this. I already tried to limit LISTEN and ACCEPT to 127.0.0.1, but the security manager also allows listening on 0.0.0.0, independent on what you really do (for bind/listen it does not check the IP at all, only the port -> see docs).
I checked SOLR tests already: Jetty and connections to our Jetties is no issue at all, it binds to 127.0.0.1 only and clients also do. The search hits on "localhost" in the source code were only in comments (we should maybe fix). There are 2 things that bind to "all" interfaces and connect to "localhost" are Zookeeper (we should at least fix this) and Java's horrible serialization/RPC/MBean framework (we cannot fix). I could extend forbidden-apis to look for string patterns in the constant pool of all checked classes... Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Dawid Weiss > Sent: Saturday, June 08, 2013 3:58 PM > To: [email protected] > Subject: Re: FYI: localhost vs 127.0.0.1 in networking-related tests > > Uwe -- could this be integrated in security manager's checkConnect? > > Dawid > > On Sat, Jun 8, 2013 at 3:55 PM, Erick Erickson <[email protected]> > wrote: > > I suspect it's one of those thing that will creep back in as code > > changes, using localhost seems harmless enough (but we know it > > isn't).... > > > > Is there any chance the precommit stuff could be enhanced to check? > > Maybe only in the test code? > > > > On Sat, Jun 8, 2013 at 9:03 AM, Robert Muir <[email protected]> wrote: > >> I think this is absolutely related. But i did a quick search for > >> "localhost" > >> in the source tree and found occurrences in src/ and test/ related code... > >> if the server is binding ONLY to 127.0.0.1, but the client is trying > >> to connect to "localhost", it could be causing issues with those > >> tests on certain configurations (at least OS X + java6) > >> > >> On Sat, Jun 8, 2013 at 8:57 AM, Erick Erickson > >> <[email protected]> > >> wrote: > >>> > >>> Dear Lord that's obscure! If I remember right, Uwe advocated using > >>> 127.0.0.1 > >>> at one point, is this related? > >>> > >>> Anyway, I'm glad you were able to track this down! > >>> > >>> Erick > >>> > >>> On Sat, Jun 8, 2013 at 8:49 AM, Robert Muir <[email protected]> wrote: > >>> > Hello, > >>> > > >>> > As you know, the jetty test in lucene's replicator module would > >>> > fail in non-reproducible ways, only on Mac OS X, and only on > >>> > java6. Finally we got to the bottom of this: > >>> > https://issues.apache.org/jira/browse/LUCENE-5037 > >>> > > >>> > The basic problem is: the server would start on 127.0.0.1, but the > >>> > client would connect to localhost. At least this one configuration > >>> > (OSX + > >>> > java6) > >>> > behaves wierd on a dual-stack ipv4/ipv6 system, it seems to > >>> > round-robin thru the 3 entries for localhost in /etc/hosts > >>> > (127.0.0.1, ::1, and link-local ipv6). This means the test would > >>> > fail if the resolver picked an ipv6 one. > >>> > > >>> > So the fix was to just use 127.0.0.1 for both server and client in > >>> > the test. > >>> > > >>> > I wonder if the same bug impacts other tests (e.g. solr jetty > >>> > tests) using jetty. > >>> > >>> -------------------------------------------------------------------- > >>> - To unsubscribe, e-mail: [email protected] For > >>> additional commands, e-mail: [email protected] > >>> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] For > > additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] For additional > commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
