[erlang-questions] Remote "access" points

Ulf Wiger ulf.wiger@REDACTED
Wed Nov 18 21:35:12 CET 2009


Calum wrote:
> On Wed, Nov 18, 2009 at 6:32 PM, Andrew Thompson <andrew@REDACTED> wrote:
> 
>> But its a message not a function call? Are you proposing to filter all
>> messages from other nodes as well as all calls to rpc:call or spawn?
> 
> Isn't it a message that requests a function gets executed? Somewhere
> in the request, the module name must be in there.

In a sense it is, but OTOH it is just a message.
We happen to know in this case that the recipient of the
message will interpret it as a request to call a particular
function. We can also recognize the registered name.

But if the message goes to <0.10.0> on the node in question -
is it ok then? Clearly not, because in all Erlang nodes with
a standard boot sequence, that /is/ the 'rex' process. It might
also be that some application running in the system has some
dispatcher pattern that, directly or indirectly, forwards any
message to a given process. This could allow us to wrap the
rpc request inside a dispatch request, and achieve the same
effect anyway. We could also hunt down a supervisor and ask it
to terminate its children - or send us a list of children so
that we can get more information about ways to break the system.

The possibilities are simply endless, if you allow users to
connect using Distributed Erlang. It was designed for closed
clusters, where all participants are trusted.

You can provide a narrow interface by opening a socket.
You can use something like UBF, CORBA, Thrift or HTTP, or why
not write a BERT server in Erlang?

http://github.com/blog/531-introducing-bert-and-bert-rpc

BR,
Ulf W
-- 
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com


More information about the erlang-questions mailing list