[erlang-questions] A less trusting Erlang.

Robert Virding rvirding@REDACTED
Mon Oct 12 22:07:54 CEST 2009

The trouble is is that there are no "special" processes in the system as
such. Messages from the outside will be routed to a normal Erlang process
which will then decide whether to ignore it or or treat it as a command and
execute it. So by only exposing certain processes which are "safe" then your
system is "safe".

How do you mean recv_spawn? There is nothing builtin to the emulator which
somehow takes a message and spawns a new process to handle it, it all done
in Erlang. I can't remember where it all handled but I would start by
checking out the module net_kernel which must be called to start networking.
>From there you can probably work out how to restrict external access.


2009/10/12 Calum <caluml@REDACTED>

> On Mon, Oct 12, 2009 at 5:21 AM, Jim McCoy <jim.mccoy@REDACTED> wrote:
> > The short answer is that you can't
> (with Erlang as it currently is)
> > effectively prevent a node in a
> > distributed erlang setup from doing just about anything it wants to
> > another node.  It just doesn't work that way.  There was some effort a
> > while back to try to deal with these issues (see the SSErl work and a
> > long thread on the list from the summer of 2006 relating to E/Erlang
> > integration) but nothing concrete has come of it.
> I looked at SSErl, and seems as though it was an internal proof of concept.
> > You are better off using a well-defined protocol at the trust
> > boundaries and not trying to let untrusted users make calls directly
> > into the trusted side of this boundary.
> Which is all very fine, but then I'd end up duplicating (probably
> badly) all the nice node discovery, linking, rpc stuff that Erlang has
> got built in.
> If Erlang didn't allow anyone to run anything, it'd be perfect - I'm
> just curious as to whether it's fairly simple to limit it so.
> In my very simplistic mind *, I'm imagining a recv_spawn function
> squirrelled away in the source somewhere, which could have a few lines
> added to check that the function being requested matches a list
> (perhaps even as simple as being hardcoded to a module starting with
> the word public).
> C
> * I'm sure it's not as easy as this - but I'm wondering if anyone with
> knowledge of the internals of Erlang could tell me how many thousands
> of miles off I am. :)
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org

More information about the erlang-questions mailing list