According to the release notes for 23.3.3, OTP-17958 addressed the following:
erlang:open_port({spawn, },) has been fixed on Windows to handle whitespace characters in the path correctly.
This could, for example, cause execution of the resolver helper program inet_gethost to fail and instead possibly execute a different program.
I noticed a similar issue with RabbitMq - and not knowing the source of the issue, reported it there, where it was closed. The response seems to indicate this is likely an issue with Erlang similar to the above mentioned resolved bug. I have reposted a summary of the contents of said issue below:
I first noticed this in RabbitMq 3.9.7 and it persists in 3.9.16, when running against Erlang 24.3.2 and 24.3.3, on Windows, where there are spaces in the path to ERLANG_HOME. I do not know if this is related to RabbitMq or Erlang, however, Erlang 24.3.3 mentions a bugfix for OTP-17958 which addressed the following:
erlang:open_port({spawn, },) has been fixed on Windows to handle whitespace characters in the path correctly.
To see the error I am referring to, if you execute the following (with spaces to your erlang installation):
rabbitmqctl.bat 2>c:\error_output.txt await_startup
and view the file created (c:\error_output.txt
), you will see the following:
C:\Program: Unknown option "Files\Redacted\Erlang\erts-12.3.1\bin\inet_gethost.exe"
Usage: C:\Program [-d [-d ...]] [-g <greedy threshold>] [<number of workers>]
The command appears to work as intended if you are just looking at the standard output stream if you used the command on the console without error output redirection. Similar output can be seen with the list_users
argument. The other batch files I typically use: rabbitmq-plugins.bat
and rabbitmq-service.bat
, do not have such error stream output.
Something in the workflow of the batch file is attempting to execute inet_gethost
. The only mention to âinet_gethostâ that I can find in the RabbitMq source code is in rabbit_networking.erl as a comment before calling inet_parse:address
.
Obviously, this is an issue with not quoting the path properly, like as specified in the OTP issue quoted above. Likewise, this is a relatively mild or moderate security issue as if someone used the default Erlang path and was already able to have permissions to add a file âC:\program.exeâ, it could be executed with the callers permissions (requiring the actor to previously been on the other side of the âairtight hatchwayâ).
If this is an issue with Erlang - I donât know the appropriate way to report an issue other than perhaps this forum post.