Sorry for the flurry of emails, found a proof of concept for overriding the filesystem core api, using nodejs vm: https://github.com/augustl/nodejs-sandboxed-fs
On Fri, Apr 18, 2014 at 11:00 AM, Shazron <shaz...@gmail.com> wrote: > Just food for thought for the future, regarding trust for these scripts, > based on the discussion so far: > > 1. Security model is basically what npm's security model for scripts are > (full trust) > 2. We could manually "verify" the scripts (for each update! gets tedious), > but before it is verified, there is a banner in the plugin registry. Not > sure how this works with command line adding of plugins with scripts, and > dependencies, since users will not see that banner, and if we have a text > warning with confirmation, that gets annoying. > 3. Sandboxing possible with http://nodejs.org/api/vm.html ? Not sure > exactly how (haven't investigated fully). > > I think the ideal situation is to: > 1. sandbox filesystem reads to the project folder only > 2. sandbox filesystem writes to the project folder only > 3. prevent the plugin from executing scripts that either exist or are have > been created in the project folder > > Not sure how to do this yet though (how to override the node filesystem > core api temporarily). > > > > > On Fri, Apr 18, 2014 at 8:43 AM, Brian LeRoux <b...@brian.io> wrote: > >> yes! (ideally we kill magic folders and make this explicit in the config) >> >> >> On Fri, Apr 18, 2014 at 8:35 AM, Sergey Grebnov (Akvelon) < >> v-seg...@microsoft.com> wrote: >> >> > Sound like most of us prefer module.export. Cool, will update the code >> > today and let you know once this is done. >> > >> > Since we will be moving to cordova-lib the next action item here could >> be >> > creating uniform hooks with shared code for both application level and >> > plugin level hooks. Thoughts? >> > >> > Thx! >> > Sergey >> > -----Original Message----- >> > From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf >> Of >> > Brian LeRoux >> > Sent: Friday, April 18, 2014 8:25 AM >> > To: dev@cordova.apache.org >> > Subject: Re: Proposal: hooks support for plugins >> > >> > like this too / would be much cleaner >> > >> > >> > >> > On Thu, Apr 17, 2014 at 5:38 PM, Shazron <shaz...@gmail.com> wrote: >> > >> > > I like Parashuram's idea. This way the plugin hooks can be testable as >> > > well? >> > > >> > > >> > > On Thu, Apr 17, 2014 at 5:22 PM, Parashuram Narasimhan (MS OPEN TECH) >> > > < panar...@microsoft.com> wrote: >> > > >> > > > Currently, the plugin hooks are constructed like the hooks in a >> > > > cordova project. An alternative would be to construct the javascript >> > > > files to >> > > have >> > > > module.exports, and we could pass in the parameters to the function >> > > > that >> > > is >> > > > exported. This way, the module will not spawn a new node process. >> > > > Comments, Thoughts? >> > > > >> > > > -----Original Message----- >> > > > From: Sergey Grebnov (Akvelon) [mailto:v-seg...@microsoft.com] >> > > > Sent: Thursday, April 17, 2014 5:19 PM >> > > > To: dev@cordova.apache.org >> > > > Subject: RE: Proposal: hooks support for plugins >> > > > >> > > > I've sent a pull request with initial implementation for review. >> > > > https://github.com/apache/cordova-plugman/pull/74 >> > > > >> > > > Thx! >> > > > Sergey >> > > > -----Original Message----- >> > > > From: Jonathan Bond-Caron [mailto:jbo...@gdesolutions.com] >> > > > Sent: Thursday, March 6, 2014 2:07 PM >> > > > To: dev@cordova.apache.org >> > > > Subject: RE: Proposal: hooks support for plugins >> > > > >> > > > On Thu Mar 6 01:57 PM, Sergey Grebnov (Akvelon) wrote: >> > > > > Can we think about scripts as just a new plugin module? - Similar >> > > > > to js-module or config-file and which must be processed special >> > > > > way (by execution). >> > > > > >> > > > > <script-module src="src/compile_sqlite.js"/> <framework >> > > > > src="src/windows8/SQLitePCL.Ext.dll" custom="true"/> >> > > > > <script-module src="src/add_win8_toastCapable.js"/> >> > > > > <script-module src="src/set_default_target_paltform_arm.js"/> >> > > > > >> > > > > Not so powerful and cool, but easy to implement and understand. >> > > > > During uninstall each script is called again but with 'uninstall' >> > > > > flag (or each script file can emit install and uninstall >> > > > > functions) >> > > > > >> > > > >> > > > I'm all for simple, what happens if one of those scripts fails? E.g. >> > > > failed compile >> > > > >> > > > For example in cli: >> > > > >> > > > cordova plugin add sqlite >> > > > platforms = ['android', 'windows8']; for(p in platforms) >> > > > installPlugin('sqlite'); // android ok! windows8 fails at >> > > > 'src/compile_sqlite.js' >> > > > >> > > > Is 'sqlite' at that point installed on android? Do we rollback the >> > > > install? Run the uninstall() scripts? >> > > > >> > > > For that reason, sandbox idea seems less chaotic with some hookApi - >> > > which >> > > > would cleanup properly if something goes wrong... >> > > > >> > > > What you're suggesting seems like it could work, until something >> > > > goes wrong and leaves the platform(s) project/native in an >> > inconsistent state. >> > > > Multiple that with "pluginb" that fails at 'src/compile_stuff.js' >> > > > >> > > > Could be doable but not sure well it would work. >> > > > >> > > > >> > > >> > >> > >