[erlang-patches] spawn to rpc, filter, etc.
Ulf Wiger
ulf.wiger@REDACTED
Mon Mar 1 18:44:12 CET 2010
bile@REDACTED wrote:
> Björn Gustavsson wrote:
>> ...
>
> 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.
I'd say that the inability to filter incoming rpc calls
is one of the things that push people towards implementing
their own communication channels and "user-level rpc".
Improving security would definitely be welcome...
One problem is of course that if you're connected to a
node, you can send any message on any process on that node,
which is a whopping big security hole.
As an example, the application controller is always pid <0.6.0>
(used to be <0.5.0> for many years. If you can only figure out
the node index of a remote node, you can do evil stuff like:
NIndex = 6341, % (or whatever)
P = c:pid(NIndex,6,0),
P ! {'$gen_call', {P,ref}, {stop_application,kernel}}
and render it pretty much useless.
I'm all for incrementally improving the situation, but am
hesitant if we don't believe that good-enough security is
within reach. Moving from "obviously unsecure" to "not
obviously unsecure" is not necessarily an improvement.
>> 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.
I think it should be 100% bw compatible with old nodes, but
old nodes should not need to offer any better security than
before. The problem is that there doesn't seem to be a way to
tell whether a connected node is old or new.
Users who don't need the added security must still be able
to rely on core functionality to be b/w compatible.
> 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.
I think there is a difference between these two, and do
think that remote spawns cannot be seen to suddenly break.
--
Ulf Wiger
CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
http://www.erlang-solutions.com
---------------------------------------------------
---------------------------------------------------
WE'VE CHANGED NAMES!
Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.
www.erlang-solutions.com
More information about the erlang-questions
mailing list