[erlang-questions] Handling unexpected messages (was Re: Erlangshell crashes)

[Valentin Micic]

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.

V.


----- Original Message ----- 
From: "Sean Hinde" <sean.hinde@REDACTED>
To: "Christian S" <chsu79@REDACTED>
Cc: <erlang-questions@REDACTED>
Sent: Monday, October 30, 2006 1:43 PM
Subject: Re: [erlang-questions] Handling unexpected messages (was Re: 
Erlangshell crashes)


>
> On 30 Oct 2006, at 11:12, Christian S wrote:
>
>> On 10/30/06, Ben Butler-Cole <ben@REDACTED> 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.
>
> Sean
>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions