Closed gschmottlach-xse closed 7 years ago
I cannot reproduce the problem. For me npm install jailed
downloads the lates version v0.3.1, which also includes the changeset of #25. Is it probably outdated in the Electron environment for some reason?
I tried it again today and it appears you are correct, I got the newer version (0.3.1) with support for Electron. There must've been a window between updates that allowed me to pull the older variant without this support. Sorry for the noise.
On the subject of a potential feature request . . . is there a way to augment the exposed APIs that can be called? I can see where it's specified in the code but wondered if there was a way to modify this once the module is loaded (short of forking the project and making the modifications myself). As I mentioned, I'm using jailed to execute scripts generated by a custom Blockly implementation. Since I control the code generation process there are a few areas where I'd like to open up the sandbox by exposing additional system APIs. Is this possible currently or does it require direct code modification (e.g. forking the project).
Thanks for sharing you great work!
Glenn
Would it work, if you expose a general method called action(name, params)
, where name is a custom string describing an action to perform? Later on you can extend supported action names on the fly in the handler method.
I'm not sure if I follow you. Are you suggesting adding something like:
application.remote.action(name, params)
to the jailed code so that the actual execution is proxied back to the host (parent) process? I've already done something like this but it requires a call back to the host process for execution. There are some Node.js APIs I'd like to call from the jailed (sub)-process in addition to setInterval/setTimeout etc... I'm not as concerned about creating a true jailed sandbox, but rather a separate thread/process of execution where the Blockly script can execute and I can control (e.g. terminate) it from the host (parent) process. Your jail allows me to do this but (understandably) is very restrictive on the Node.js APIs that can be invoked from the the jail. I was just wondering if there is a better mechanism than modifying the library to open this up?
Method exporting is designed for invoking functions on the opposite site, so all you can do is export something additional (or very general, like the suggested action()
method).
Currently there is no opportunity to "unlock" the sandbox and make it less restricted, and you are using Jailed not in the way it was designed for :-) This might be an insteresting feature for the future which is not there yet.
I would suggest to manually reuse the child_process module and controll the subprocess. Jailed is too overdesigned solution for that.
Thanks for the info. I realize I could have absolute control with the child_process module but your module does offer some very useful sugar-coating around these (more primitive) features. At the moment I can work within the jailed constraints. If they become an impediment to future development, I can always fork your project and make the necessary modifications to fit my use-case. That's for sharing this . . . it's provided a nice foundation on which to build.
It appears the tarball that npm pulls when you do an "npm install jailed" is pulling an older version of your code which doesn't include the fix for issue #25. I'm trying to use jailed in an Electron environment and need this fix so that it will work. Could you please push up an updated tarball? I like your implementation - makes it easier to run Blockly code in an isolated and separate psuedo-sandbox.
Thanks . . .
Glenn