How to remove/disable BEAM functionalities (creating a sandbox)


I want to remove unwanted functions from the BEAM, but without recompiling it.

My scenario is the following, someone is going to connect at my BEAM node, and I only want they to be able to execute a small subset of the normally available functions (like restricting SYSCALLS in a ELF file).

I know this is not the ideal approach, but it is part of a series of experiments that I’m doing on the BEAM. So any help would be nice.

Thanks in advance,

1 Like

The BEAM is not suitable for sandboxing.

If you want untrusted users run code on your node, provide them a way to connect via telnet or ssh (the BEAM has server applications for both) and provide them a shall that way that has a shrinked down language, either erlang or elixir like, or something completely different, which you then restrict by your own runtime environment before delegating to the BEAM.

Or even better, is to not let untrusted users connect to your node…


I think we can take Robert Virding’s answer here as a good summary: How to create a sandbox to run untrusted code/modules?


Can’t I use something like this:

  • Create a proxy for when the client issues a Node.spawn
  • Unquote the passed function (and all nested functions)
  • Blacklist or Whitelist the atom of the functions.

I’m not seeking a perfect sandbox, just any sandbox.

This is the part that is functionally impossible unless all you want to do are let people use math operators or something. It’s simply too easy to generate atoms dynamically and then use them as function calls. You’re better off using something like

This seems like a bit of an XY problem. What problem are you trying to solve here ultimately?


What I’m trying to do is to create a proof of concept where node A creates a process in node B following a certain set of rules.

If A tries to spawn a process that does not follow this set of rules (a prohibited function atom, or using a anonymous function for example), then I want to return a error.

I do not mind to implement a RPC or any other client.

1 Like

Is Node A untrusted? IE is this simply a way to help make sure developers do the right thing? or are potentially hostile or mischievous users going to be doing this?


I think both, but I’m assuming node A cannot be trusted.

Ideally for my proof of concept, I’ll have a chess game running on a genserver in B. And players will only be allowed to spawn process with functions from the module of the chess game. Sure a function inside the module may be vulnerable and break the protection, but the problem I’m trying to address is the spawn itself.

This could be used for mesh networks in embedded systems using for example, where I open myself to the world, but not too much.

I do not mind to implement a RPC or any other client.

I think you answered your question.

1 Like

I hoped to find an easier way, but I guess it is what it is.


Instead of connect to BEAM node, maybe implementing a SQL API would be an option?

1 Like