[erlang-questions] A less trusting Erlang.

Calum caluml@REDACTED
Mon Oct 12 20:39:07 CEST 2009


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. :)


More information about the erlang-questions mailing list