On Wed, Oct 16, 2013 at 11:58 PM, Jan Lehnardt <[email protected]> wrote:
> > On Oct 16, 2013, at 23:40 , Benoit Chesneau <[email protected]> wrote: > > > On Wed, Oct 16, 2013 at 11:32 PM, Klaus Trainer <[email protected] > >wrote: > > > >> Hi there! > >> > >> You might want to check out Try Erlang (http://www.tryerlang.org/). > >> That is, you can't check out the source code right now. However, > >> according to the FAQ (http://www.tryerlang.org/faq) they "plan to > >> release the whole project as Open Source very soon". I guess that > >> nagging Roberto Aloi (who's the principal author) might speed that up ;) > >> > >> Regarding sandbox security: I believe that it is possible to implement a > >> sandbox thing that provides reasonable security, as long as your > >> whitelist is restrictive enough. That is, one has to be pretty cautious > >> regarding the whitelist policy, especially when it comes to functions > >> that have the ability to construct new terms, like for instance > >> `list_to_atom/1` or `binary_to_term/1,2`. The former makes it possible > >> fill up the Erlang VM's atom table, which makes it prone to DoS attacks. > >> The latter has a "safe" mode (when being invoked with the `safe` > >> option), though, but still allows to create function references, which > >> can be exploited (see > >> > >> > http://aloiroberto.wordpress.com/2010/10/14/how-they-tried-to-fool-tryerlang-org/ > >> ). > >> > >> Oh, I've used the term "reasonable security" above. I should explain > >> (at least roughly) what I mean with that ;) For example, Try Erlang has > >> been existing (and being online) for several years now, and people > >> haven't found something exploitable, except for one time more than three > >> years ago. Depending on your security needs, your knowledge of Erlang, > >> your knowledge of the sandbox code, and other known facts as well as > >> your general level of paranoia, this might be enough for you to trust > it. > >> > >> > >> Klaus > >> > >> > > > > On linux a simpler way would be launching an external command in a > cgroup. > > with cgexec from libcgroup or stuff like > > https://github.com/thestinger/playpen rather than try to filter any call > > you could then forbid some devices, the network and such... > > at which point you lose all the speed improvements an in-VM language gives > you. > Well it depends how you use it. You may just need to start couchdb in 1 cgroup. Or launch each view server isolated in their own process added or not to a cgroup (or resource limited). Anyway you will also lose a lot of the performance if you filter in live Erlang or Elixir. I don't think it's really a question of performance but more likely of the convenience you want and the platform of course. - benoit
