nested calls

[andreineculau]

if deps look like foo (request as peer dependency) + request

and i say that request has access to fs, http and https, then how would you limit foo from requiring request and doing evil stuff ?

[nickkolok]

Good question, thnx. It would be like this:

Let's imagine a project in folder myproject. a) Paraquiring request:

var request = paraquire('request',{builtin:{'https':true, 'http':true, 'fs':true}});

What is done by this command? a.1) Name request is resolved to myproject/node_modules/request/index.js (function resolveChildRequest) a.2) The content of file myproject/node_modules/request/index.js is readed, cached and precompiled without certain context (function getScript) a.3) The precompiled script is executed in new context with require function generated by generateRequire function. The execution takes place in runFile function. In this context (let's call it "A-context") request runs with access to fs, https and http.

b) Paraquiring evil-lib:

var evilLib = paraquire('evil-lib');

b.1) Name evil-lib is resolved to myproject/node_modules/evil-lib/index.js (function resolveChildRequest) b.2) The content of file myproject/node_modules/evil-lib/index.js is readed, cached and precompiled without certain context (function getScript) b.3) The precompiled script is executed in new context with require function generated by generateRequire function. The execution takes place in runFile function. In this context (let's call it "B-context") evil-lib has no access to fs etc.

c) evil-lib requires request to perform evil things:

var evilrequest = require('request');

c.1) Name request is resolved to myproject/node_modules/request/index.js (function resolveChildRequest) c.2) Precompiled script is taked from cache (function getScript) c.3) The precompiled script is executed in existing B-context with new require function generated by generateRequire function. The execution takes place in runFile function. In this context nobody has access to fs etc.

In other words, request paraquired by our project and request required by evil-lib are two different copies of request with different permissions.

Do I need to give more clear explanation?

[andreineculau]

:+1:

doesn't that mean that the permissions can end up as super-verbose? if I have a util module, that use super-request that uses request, then I have to allow http/s on all of those 3 modules

EDIT: similarly, since there may be different versions flying around (request may be a dependency of 2 other dependencies, each requiring a diff version), one needs to be very precise, thus verbose

[nickkolok]

So, you're talking about dependency chain like this: myproject ---> myutil ---> super-request ---> request Then you just can allow http/s once: myproject ---(paraquire with http/s perms is here)---> myutil ---(usual require)---> super-request ---(usual require)---> request If myutil module need more permissions, e.g. console, the scheme turns into: myproject ---(paraquire with http/s and console perms is here)---> myutil ---(paraquire with http/s perms is here)---> super-request ---(usual require)---> request

Of course, if myproject uses request explicitly, then our graph gets another branch: myproject ---(paraquire with http/s perms is here)---> request

Notice: require inside paraquired module is usual full-permissive require, but "full-permissive" means not "all-permissive", but "with no restrictions".

For example, A paraquires B with permissions to https, fs and console. B requires C. C has permissions to https, fs and console, but no permissions to access, for example, process. B paraquires D with permissions to console and process. As B has no access to process, permissions intercept so that D has only access to console. To be more verbose, B doesn't know what is process, it doesn't have process in it's scope, so B couldn't giv anybody access to process