Permission Model adoption from Package Managers about security-wg HOT 3 OPEN

How would you envision it being used? Since legitimate postinstall scripts often are about building native packages, they end up executing code in a way that the Node permission model wouldn't apply.

from security-wg.

How would you envision it being used? Since legitimate postinstall scripts often are about building native packages, they end up executing code in a way that the Node permission model wouldn't apply.

In case of building native packages, it will be denied, yeah. I was imagining a specific use case where a Node.js script is run. Do you see another use case for this? Either during the package installation or the module usage itself

from security-wg.

On the top of my head I don't see a lot of use cases for Node.js-based postinstall scripts - afaik the two categories in the wild are:

• Lazily downloading prebuilt binaries; that's something that's better served with optionalDependencies, since it integrates with the cache and lockfile. So we don't really want to encourage that.
• Print something during install; that's something Yarn doesn't support by default as we don't print messages unless the package completely fails to install.

So limiting the scope of Node.js scripts during postinstall isn't that impactful imo: in most cases users will be better served by disabling the postinstall entirely (if it's an ad), or running it with full permissions (if it's a compiled package).

With that said I think it could be interesting to discuss how to make yarn run secure the processes it starts - while I'm afraid postinstall is kind of an unfortunate evil, I could imagine us setting up a jail in yarn run so that transitive dependencies of your scripts (especially those which don't define a postinstall scripts, and thus have less scrutiny) can't compromise the user.

from security-wg.