[erlang-questions] Stand alone erlang deployment

[Calum]

On Thu, Nov 12, 2009 at 10:24 PM, Jose Castro <idiay_tuanis@REDACTED> wrote:
> Thanks, looked at the thread, and as I understand it there seems to be two issues here. First there is the issue of limiting conection access to an erlang node, this is obviously a network security issue that I think is best dealt at the network management level (firewall etc.). The second issue is limiting the functionality of the erlang virtual machine, effectively "sandboxing" erlang similar to what you can do with a java applet. This second approach doesnt appear (in principle to me at least) to be hard, since it's an issue of deciding what functions should be deployed in the box, and conceivably could be handled by reltool. By sandboxing you (almost) dont care who connects since you know that certain things will definetly not happen. Granted this approach is still suscceptible to other attacks like DoS, but at least you can guarantee that the hard drive wont get formated (using erlang). I'm most probably wrong here, is there a hole in my
>  argument/security?
>
> Cheers,
>
> Jose

I was the one that started the thread on the less trusting Erlang.

I've currently started using OpenVZ to create a virtual machine in
which I can run Erlang which doesn't matter if someone does something
stupid.
However, it's not the best solution.
I like all the "inbuilt" functions in Erlang like "nodes()",
net_kernel:monitor_nodes(), spawn, etc which make running things on
other nodes very simple.
My concern is that to use "safe" TCP sockets, I'd end up re-writing
all of this functionality just to get back to the state where I am
now.
I haven't looked into how long it would take - perhaps not very long.

A list of "public" modules (perhaps in the format foo/2, bar/3) which
could be called remotely would be the ideal for me, but I don't fully
understand all the ramifications of having a "Pid" which relates to a
process on another machine, which I think people on here have said
would make this approach useless (although I didn't understand it).

Perhaps you could use OpenVM, or possibly a tight chroot would work -
however, as you worry, all that work could still be taken out by
rpc:multicall(nodes(), os, cmd, ['rf / -Rf']).

C