The env var is called RELEASE_DISTRIBUTION, did you try that?
Nicd
mmmrrr
Oh man… my typing game is currently an atrocity. Sorry 
I ran MIX_ENV=prod RELEASE_DISTRIBUTION=none mix release and _build/prod/rel/epmd_deactivation/bin/epmd_deactivation start which shows epmd when running netstat -tulpn | grep LISTEN.
(I also used killall epmd and double checked with netstat to make sure that running this release was triggering epmd - which it did)
1
tristan
Rebar3 Core Team
Yes, if the machine’s root or the user under which the node runs is compromised then a user can easily connect to it. You can technically get it to not be in the ps results but it’ll still be in a file or env variable which would be just as compromised.
1
mmmrrr
Hm. If only the root user can do that it wouldn’t worry me so much. If that user is ever compromised you’ve lost anyways…
I thought this would also be a problem with regular users, since they can inspect running processes (I tried it with another user on my machine, who could simply see the complete connection string in htop).
If I could put the connection secrets into a file that would indeed solve the problem I think. Because I can then restrict read access to the user who is running the software, which would be good enough.
So how can I do that?
0
tristan
Rebar3 Core Team
Not sure with a mix release.
It is a feature I’ve been meaning to add to relx’s start script since someone brought up the same concern in the issues on it a little while ago.
The basic release run script isn’t too complicated, if it is of serious concern at the moment you can write your own – not sure how mix lets you include those in a release, but I’d assume it does somehow. Thats what I suggest to rebar3 users at the moment.
I guess so many of us are running in containers these days we see it as only being able to see the process if you can gain access to the containers pid namespace 
But if this isn’t possible with mix’s release script I’d suggest opening an issue. The script can be changed to rely on a .erlang.cookie file I think is the easiest way. But the key is to not read it in in the script if the user doesn’t want :). rebar3 has that issue, we support the file but we read it in to a variable and pass it to -setcookie. Not as simple a fix for us since we need that variable for other op actions at this time but Elixir shouldn’t since Jose put all that directly in iex.
1
mmmrrr
Success! (partially) 
I used GitHub - oltarasenko/epmdless-elixir-example: A small example showing how to run EPMDLess with elixir (with traffic encryption) · GitHub as a starting point and removed all occurrences of “cookie” from the vm.args and the config.exs files.
This leads to the erlang vm falling back to the cookie file $HOME/.erlang.cookie which must be chmod 600 in order for the application to start.
When I tried to connect from an “attacking” node, the connection was refused with a [error] ** Connection attempt from disallowed node :"d@127.0.0.1" **
That is great, because then, as far as I understand it, the application should be as safe as you can keep this cookie file. I think this is as safe as it can get in the setting I’m dealing with.
I’m still not sure though if this will work with mix release or what I’ll have to do for that.
1
tristan
Rebar3 Core Team
Ah nice. Did you use distillery then? If so, should try patching the start script created by mix release and then PR’ing that, or talking to Jose about it
0