[e-lang] [Fwd: Re: Proposal: E / Erlang integration]

Mark S. Miller markm at cs.jhu.edu
Thu Jun 8 18:05:19 EDT 2006


-------- Original Message --------
Subject: Re: [e-lang] Proposal: E / Erlang integration
Date: Thu, 8 Jun 2006 19:35:51 +0100
From: Vlad Dumitrescu <vladdu55 -at- gmail.com>
To: Mark S. Miller <markm -at- cs.jhu.edu>
CC: Discussion of E and other capability languages <e-lang -at-
mail.eros-os.org>,
   erlang-questions -at- erlang.org, Peter Van Roy <pvr -at- info.ucl.ac.be>


Hi!

If I may add a few observations:

>  > Although Erlang is not engineered to provide robustness against
>  > malice, it seems to be an object-capability language. Erlang
>  > processes are encapsulated objects and processIds are unforgeable
>  > capabilities, providing the right to send messages to a process. The
>  > rules by which processIds are transmitted and acquired seem to be
>  > precisely object-capability rules.  Most importantly, the language
>  > has no global scope. Each process has its own separate state.

No, process ids are actually forgeable... For remote pids one has to
find out the internal value to use as first argument for c:pid/3, but
even that one could be found by trial and error.

>  > Unfortunately, a process has only one processId, so the common
>  > convention is for making a request and receiving a reply is for the
>  > client to include its own processId in the message as a reply
>  > port. This gives the provider the authority, not only to reply to
>  > the client, but to invoke the client. It is not clear how to repair
>  > this convention within the overall Erlang framework.
>
> This issue seems fundamental. It cannot be fixed either by syntax or
> by a library. Until it is fixed, I don't see how to write practical
> Erlang programs with distributed object-capability security
> properties.

Maybe I am completely missing the point, but I think it is possible to
build a system that matches at least some of these requirements (I
include here the non-blocking event loop).

I am thinking about a setup where an "e-process" is actually composed
from several erlang processes: one for receiving events, one to do the
actual job, and maybe some more.

best regards,
Vlad



-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM




More information about the e-lang mailing list