Workers bind to external network interface by default  11598 Closed garrison opened this Issue on Jun 5, 2015 · 4 comments Projects None yet Labels parallel Milestone No milestone Assignees No one assigned 4 participants  garrison  vtjnash  amitmurthy  tkelman Notifications    garrison The Julia Language member garrison commented on Jun 5, 2015  When running julia -p 2, I was surprised to learn that the workers are told to bind to my external network interface.  $ ps x  5144 pts 12   Sl+    0:01 . julia -p 2  5152 ?        Ssl    0:00  home garrison julia usr bin julia -Cnative -J home garrison julia usr lib julia sys.ji --bind-to 192.168.1.101 --worker  5153 ?        Ssl    0:01  home garrison julia usr bin julia -Cnative -J home garrison julia usr lib julia sys.ji --bind-to 192.168.1.101 --worker  I would have hoped that a UNIX domain socket would be used if all the workers are on the local machine.  Failing that, binding to localhost would make a lot more sense, although this is still problematic from a security standpoint.   tkelman tkelman added the parallel label on Jun 5, 2015  vtjnash The Julia Language member vtjnash commented on Jun 5, 2015  binding to a local port would prevent heterogeneous networks consisting of both local and remote clients so it is typically undesirable to bind to localhost.  it is possible to add remove workers at runtime, so it's not possible to known ahead of time if all workers will be local   the kernel should fast-track the data as if it was declared using a unix domain socket, so there's no benefit there from performance.  i'm not sure i understand the security argument. are you assuming some malicious process will discover the remote port and try to become part of the pool? that would be bad, but to solve that it sounds like the master process should be emitting a private token to stdin immediately upon startup of the client that would act as the shared secret for any client wishing to join the processor pool.  garrison The Julia Language member garrison commented on Jun 5, 2015  Yes, my main concern here is security. I don't like the idea that julia is listening on an external network interface without me giving it an explicit instruction to do so.      i'm not sure i understand the security argument. are you assuming some malicious process will discover the remote port and try to become part of the pool? that would be bad, but to solve that it sounds like the master process should be emitting a private token to stdin immediately upon startup of the client that would act as the shared secret for any client wishing to join the processor pool.  My concern is that a malicious connection  which could originate, it seems, from another user on the same machine; from another person on the same network; or from somebody far away on the internet  could connect to the port a worker has binded to and gain control of it.  Perhaps the method you suggest would work as a line of defense. The piece of code implementing this deserves to be audited pretty thoroughly though, as a single bug could lead to a compromised process. Even then, most people who think even passingly about security will prefer not to have julia workers listening on external ports  EDIT: unless, of course, they are running workers on multiple machines, in a controlled environment . Appropriate firewalling could mitigate the problem, but should not be relied on.  As a tangent thought  ignoring the security concern for a moment, although that is my primary concern , I'm not sure why it binds to a specific network interface  192.168.0.101 on my system . If each worker process were to be available everywhere, I would expect it to bind to 0.0.0.0 instead.  amitmurthy The Julia Language member amitmurthy commented on Jun 6, 2015  It is actually listening on all interfaces. The bind-to is the address it expects other processes from remote hosts to connect at. Except on the node running the master process, local workers always connect at 127.0.0.1 - this helps the specific use case of a laptop being put to sleep and getting a different IP on wakeup.  garrison garrison referenced this issue on Jul 22, 2015 Open Bind workers to localhost interface during the tests?  8802  amitmurthy The Julia Language member amitmurthy commented on Jun 7  closed by  16292  amitmurthy amitmurthy closed this on Jun 7