[erlang-questions] Handling unexpected messages (was Re: Erlangshell crashes)
Mon Oct 30 15:18:01 CET 2006
Another thing that might be useful, is to prevent a malicious code from
being executed in a first place. One way is to start a run time using
restricted shell, and ensure that only code intended to run can be started
(although this is not going to cover erlang rpc calls -- that may be handled
at a different level). Such a shell may enforce some form of login, and
hence, some role-driven access rights etc. We did something to that end a
while ago, but still did not deploy it in any production system, thus cannot
say how useful or problematic it might be. But it's a start.
----- Original Message -----
From: "Sean Hinde" <>
To: "Christian S" <>
Sent: Monday, October 30, 2006 1:43 PM
Subject: Re: [erlang-questions] Handling unexpected messages (was Re:
> On 30 Oct 2006, at 11:12, Christian S wrote:
>> On 10/30/06, Ben Butler-Cole <> wrote:
>>> I'm writing my first Erlang system and need to decide general
>>> policies for this kind of thing. Is there not an argument for
>>> exiting if you get an unexpected message rather than just ignoring
>>> it? I suppose that opens you up to a denial of service attack if
>>> your Pids or process names aren't completely secure.
>> If you have malicious code in your erlang system it can do far worse
>> things. All code in an erlang system is granted access to every
>> corner. There is no such things as secure pids or process names to it.
>> Yes it is probably a good idea to crash on the unexpected. Write
>> programs for the expected and crash when expectations aren't met.
>> Continuing a program when something unexpected has happened is to walk
>> on thin ice on a lake of undefined behavior.
> As a contrary argument, many of the messages passed in a typical
> large Erlang system (at least in Telecoms) have nothing whatever to
> do with core function. To crash some core function process because
> some broken maintenance module sends it a duff status request is
> almost certainly not the right thing to do. Much better to log the
> duff request and ignore it.
>> erlang-questions mailing list
> erlang-questions mailing list
More information about the erlang-questions