[erlang-patches] spawn to rpc, filter, etc.

[bile@REDACTED]

Björn Gustavsson wrote:
> I consider this feature "nice to have". It does not provide enough
> additional security so that you would dare to connect to untrusted
> nodes, so the ability to filter messages can only be a convenience
> feature, not a game changing feature. (As far as I can understand.
> You have not mentioned any specific applications that would have
> a need for the feature.)

Currently there is nearly zero security outside of the cookie. There are
cases where native connected nodes are desired without opening up the
entire system. Trust is not binary. Just because I can ssh to a box
doesn't mean I can execute anything on the machine. My team is currently
rewriting an application in Erlang and we must have certain levels of lock
down. There are always tradeoffs for security but Erlang in its current
form forces tradeoffs that aren't necessary. I see several easy and minor
changes to the Erlang system that would go a long way to providing a more
secure environment and I'm trying to get them out there so others can take
advantage of them.

>
> Therefore, being only a "nice to have" feature that changes
> sensitive code paths, the following are the minimum requirements:
>
> * It should be 100% backwards compatible.

I was under the understanding that different releases shouldn't
necessarily be used together. It's a rather large jump in security between
nodes relative to what exists and I'd think it's a reasonable tradeoff. As
I mentioned in the previous email it could be made fully compatible but I
don't find it a very appealing solution.

> * It should not reduce the performance for applications
> that don't use (and have no use for) the new feature.

Within reason, agreed. In this case if the filter isn't set 'apply' is
called directly. There is only wrapper function with a guard as overhead.

> * It should be obviously correct and harmless. (It is
> embarrassing for the Erlang/OTP team if a new killer feature
> breaks something that has always worked. It is *very*
> embarrassing if a not specially important features breaks
> something.)

Obviously. That's why pu and unit exists is it not? I'll be happy to write
some additional unit tests I've just not had the time. However, there is a
difference between purposeful breakage in the name of advancement and
breakage due to bad code. Security in Erlang has been talked about a lot
but little is done. This patch provides a certain amount of security
without any major impact. I wouldn't consider it unreasonable if R14
remote spawns didn't work on R13 and prior. Just as I consider it
reasonable that by catching throws now in rpc there is a possibility of
breakage.

>
> Unless you can convince us that the feature is more
> important than just "nice to have", it is unlikely that we
> will approve it.

I'm hoping more people comment on the feature. In my short time in the
Erlang community I've seen a few individuals ask about sandboxing beam
and/or networked nodes. The former would require a lot of work but the
latter is straight forward if an ability to plugin to remote 'apply'ing is
provided. I've CCed erlang-questions to bring a larger audience.

-Antonio