[erlang-patches] What's cooking in erlang/otp (2010-03-22)

[bile@REDACTED]

On Tue, 23 Mar 2010 01:18:29 +0100
Ulf Wiger <ulf.wiger@REDACTED> wrote:

> bile@REDACTED wrote:
> > There are several simple,
> > noninvasive changes which would provide some amount of sandboxing
> > without affecting existing behavior and there has been nothing but
> > resistance. 
> 
> I don't know about that, but some of the suggestions have actually
> affected compatibility, so they haven't actually been non-invasive.

The restricted ports did not affect compatibility and the second
version of the rpc and spawn filters did not either. By default
everything worked exactly as now.

> 
> But Erlang also makes socket communication easier, so building a
> distributed system based on user-level TCP-like channes is pretty
> straightforward, if you are not willing to suffer the openness
> that Distributed Erlang creates. Distributed Erlang was designed
> for embedded clusters, where each member of the cluster is
> implicitly trusted, and the interconnects are reliable (often
> redundant) unencrypted high-speed links.

Easier in what way? The core platform isn't extensible. Why can't the
platform be engineered so that the linking of nodes is abstracted such
that builtin features are still usable? There is some abstraction in
net_kernel but it's not advertised AFAICT. As a new user you can open
appmon, pman or tv and see across nodes... but if you do any serious
work that all goes away because most places simply can't afford a
completely open platform. Even allowing arbitrary erlang processes
access to a port is questionable in my environment. Hence the
restricted patch. Completely trusted clusters are just not something
that exists in many environments and it just forces individuals to have
to recreate the wheel over and over. If I could hook into the message
passing and linking code standard libraries could be developed to
provide for cookie like authentication, kerberos, etc. and all the
native distributed features would still function.