[erlang-questions] Limit functions available to a process
Brentley Jones
I remember seeing in the list a topic which talked a proposal which would allow different functions being available from a module depending on context. One would be able to give a different name to a module and expose different functions to certain modules. (Maybe someone could find a link to this?)
I only mention this to give context to what I want to be able to do. I know that currently in Erlang every process can call any function that it is exposed to. This includes the auto-imported "global" functions and BIFs, as well as all exported functions of other modules. I want to be able to limit a process, or module, from calling certain functions. For example, if I have the following module, with [1] being just one way to allow this, I want [2] below to produce either an undef or similar runtime error.
%% sandbox.erl
-module(sandbox).
-unimport(os). %[1]
-unimport(erlang, [spawn/1, spawn/2, spawn/3, spawn/4]). % [1]
do_something_naughty() ->
os:cmd("rm important_file"). % [2]
There have been a couple "safe Erlang" topics started recently, and I know that this won't prevent a process from calling the function through RPC, but it is a start to sandboxing Erlang modules or processes.
Since I know this currently isn't supported, where would I start looking (erl code or C code) to make this change? If I'm only thinking on the module level, is there a table that holds all exposed modules and/or functions?
Thanks for your time,
- Brentley Jones
________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org
Brentley Jones
On Dec 5, 3:42 pm, Brentley Jones <the.aj...@gmail.com> wrote:
> I remember seeing in the list a topic which talked a proposal which would allow different functions being available from a module depending on context. One would be able to give a different name to a module and expose different functions to certain modules. (Maybe someone could find a link to this?)
I found the topic that I was trying to explain:
http://www.erlang.org/pipermail/erlang-questions/2006-November/023879.html
It was before the google groups indexing, thus why I couldn't find it.
O'Keefe's proposal would actually do what I want. By being able to
define an environment that only has access to module a,c,b I would
have what I want.