[erlang-questions] Capability model? (was: Process declarations)

[Mark S. Miller]

Tony Finch wrote:
> On Thu, 5 Oct 2006, Joe Armstrong wrote:
> 
>> Process declarations:
>> Do away with spawn. Replace with a process keyword:
>> So that we can name processes. Things without names we cannot talk about.
> 
> I think this is a bad idea because it's moving away from the capability
> model, where posession of a pid implies permission to communicate with it,
> and if you don't have the pid you can't. The pid *is* the name. Also, I'm
> not sure how your proposal deals with multiple processes running the
> annotated code.


Currently, the underlying logic of Erlang perfectly supports the capability 
model, but current Erlang practice does not. The main problems as I see it:

* pids are currently forgeable, by unserialization from a guessable 
representation.

* Common Erlang practice is to register pids in a global name table.

* Common Erlang practice is for process A to perform an RPC to process B by 
giving the B direct access to A's pid, and for A to distinguish B's response 
from further requests by A's clients by forgeable convention. This practice 
permits B to make requests of A, and it permits other clients of A to send to 
A a forged response to A's outstanding call to B.


All these problems are easily fixed while keeping the sense of Erlang. Only 
the first is fundamental, but is probably also the least painful. As has been 
discussed here previously, A can fix the last problem by creating an 
intermediate process, A2, to receive the response to this one request. It 
would then give B A2's pid. This change would be the most painful, as it would 
require pervasive changes to existing libraries.

So Erlang is at a fork in the road. It is well positioned to move towards 
capabilities if there's enough interest, and enough willingness to pay the 
price. Or if not, it may as well move away, because there's no benefit to 
remaining in this middle ground.

When considering this choice, ask whether Erlang has any other plausible route 
for supporting distributed security.

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

     Cheers,
     --MarkM