Move sandbox to its own project?
16 views
Skip to first unread message
Yoz Grahame
Dec 21, 2010, 1:56:46 PM12/21/10
to jsap...@googlegroups.com
As someone also working on the execution of untrusted code, I would love to see the part of JSApp that deals with this (as in, handling child processes and sandbox contexts) split out to its own module. I would happily help with this (and even do most of the work) if the code structure was clearer.
There are a couple of other projects on Github that do similar things, except that node-sandbox has almost no features, jefe is complex and broken, and neither is actively maintained.
-- Yoz
There are a couple of other projects on Github that do similar things, except that node-sandbox has almost no features, jefe is complex and broken, and neither is actively maintained.
-- Yoz
Matthew Francis-Landau
Dec 21, 2010, 3:10:49 PM12/21/10
to jsap...@googlegroups.com
I think that the core of the sandbox is based of the runInNewContext function. All the code for the sandbox is held in the sandbox directory. There is a strong hint of sandboxing web servers as that is main purpose of JSApp.us, but you might find that sandbox/boxed.js sandbox/index.js and sandbox/modules.js to be useful in constructing a sandbox. As for sandbox/build.js you would have to rewrite large portions of this, as its function is to load the code out of the database.
I am going to list a few things that you might find useful in understand the sandbox (if you still find the code confusing, write back):
*node-host uses a pre-forked pool of process to handle any of the incoming request to the applications
-This means that more than one applications can be running on a process at a time, for web applications where most of the time is spent in the database any ways there seems to be little problem with this
-If a process in the pre-forked pool has a problem is is brought down within a second and restarted.
*The building of the code for the sandbox can be done in a different step from the execution of the code, this is use full for when "compiling" the code into a smaller package to latter be loaded for execution. The code is package into a json object and then latter executed by the sandbox.
Matthew Francis-Landau
http://jsapp.us/p/matthewfl
I am going to list a few things that you might find useful in understand the sandbox (if you still find the code confusing, write back):
*node-host uses a pre-forked pool of process to handle any of the incoming request to the applications
-This means that more than one applications can be running on a process at a time, for web applications where most of the time is spent in the database any ways there seems to be little problem with this
-If a process in the pre-forked pool has a problem is is brought down within a second and restarted.
*The building of the code for the sandbox can be done in a different step from the execution of the code, this is use full for when "compiling" the code into a smaller package to latter be loaded for execution. The code is package into a json object and then latter executed by the sandbox.
Matthew Francis-Landau
http://jsapp.us/p/matthewfl
Yoz Grahame
Dec 21, 2010, 5:47:31 PM12/21/10
to jsap...@googlegroups.com
OK, it's starting to make more sense now, thank you.
Some more questions for you. to help me get a sense of the problems and solutions:
1: Why did you use nginx + python for the main web server, instead of more node.js?
2: Why did you write custom code for the proxy instead of using a vanilla one?
3: Where is the code that watches, kills and spawns processes?
4: Are you watching memory consumption?
Sorry for the interrogation here - many thanks for making this code public!
-- Yoz
Some more questions for you. to help me get a sense of the problems and solutions:
1: Why did you use nginx + python for the main web server, instead of more node.js?
2: Why did you write custom code for the proxy instead of using a vanilla one?
3: Where is the code that watches, kills and spawns processes?
4: Are you watching memory consumption?
Sorry for the interrogation here - many thanks for making this code public!
-- Yoz
Matthew Francis-Landau
Dec 21, 2010, 6:13:12 PM12/21/10
to jsap...@googlegroups.com
The python proxy is only used when developing, it is from a little python proxy that I found on line and never had a problem with before. What it is doing is rerouting all the request for jsapp.us at the localhost (I only had to add like 2 lines to get this working).
As for nginx, it is a very good web server. While the load distributor could be written in node, I have seen node seg-fault on the most simple code, as well it requires more cpu time than nginx.
For example: the master process (keep the things alive, and prints output of process to stdout for debugging) has used about 11 hours of cpu time in the last 24 hours. The front-end editor server has used about 10 minutes. In this same period of time, the sum of the nginx process is only about 5 minutes. Also note that nginx is a web server designed in C to perform this task, and thus nothing that I make in node will be able to compare in speed or efficiency.
The master process is responsible for starting up all the processes. It is running inside a bash, white true loop to ensure that it stays running (I have seen this seg-fault before).
I was originally going to make some way of watching the memory, but have not yet needed it (I was planning to make the master watch the /proc files). But there is a heart beat system, in which the master process will kill a child if it fails to keep the heart beat.
--
Matthew Francis-Landau
mat...@matthewfl.com
http://matthewfl.com
As for nginx, it is a very good web server. While the load distributor could be written in node, I have seen node seg-fault on the most simple code, as well it requires more cpu time than nginx.
For example: the master process (keep the things alive, and prints output of process to stdout for debugging) has used about 11 hours of cpu time in the last 24 hours. The front-end editor server has used about 10 minutes. In this same period of time, the sum of the nginx process is only about 5 minutes. Also note that nginx is a web server designed in C to perform this task, and thus nothing that I make in node will be able to compare in speed or efficiency.
The master process is responsible for starting up all the processes. It is running inside a bash, white true loop to ensure that it stays running (I have seen this seg-fault before).
I was originally going to make some way of watching the memory, but have not yet needed it (I was planning to make the master watch the /proc files). But there is a heart beat system, in which the master process will kill a child if it fails to keep the heart beat.
--
Matthew Francis-Landau
mat...@matthewfl.com
http://matthewfl.com
Reply all
Reply to author
Forward
0 new messages