What is the drawback of install with --unsafe-perm

[JoeShi]

What is the cons of install with --unsafe-perm?

I run the following command to install the strong-pm on aws linux. After running these commands I cannot launch strong-pm. I need to append --unsafe-perm in step 2.

1. sudo npm install -g strong-pm
2. sudo sl-pm-install --upstart=0.6 --set-env NODE_ENV=production
3. sudo /sbin/initctl start strong-pm

The console says strong-pm start/running, process 3348.

However, I did not see strong-pm launch successfully. I checked the /var/logs/messages, and I found the error message.

strong-pm: Error: Cannot find module     '/usr/lib/node_modules/strong-pm/node_modules/loopback-connector-sqlite3/node_modules/sqlite3/lib/binding/node-v46-linux-x64/node_sqlite3.node'
 strong-pm:     at Function.Module._resolveFilename (module.js:325:15)
 strong-pm:     at Function.Module._load (module.js:276:25)
 strong-pm:     at Module.require (module.js:353:17)
 strong-pm:     at require (internal/module.js:12:17)
 strong-pm:     at Object.<anonymous> (/usr/lib/node_modules/strong-pm/node_modules/loopback-connector-sqlite3/node_modules/sqlite3/lib/sqlite3.js:4:15)
 strong-pm:     at Module._compile (module.js:409:26)
 strong-pm:     at Object.Module._extensions..js (module.js:416:10)
 strong-pm:     at Module.load (module.js:343:32)
 strong-pm:     at Function.Module._load (module.js:300:12)
 strong-pm:     at Module.require (module.js:353:17)
 strong-pm:     at require (internal/module.js:12:17)
 strong-pm main process (5154) terminated with status 1

[sam-github]

• con: install scripts are run as root, and you probably did not read them all to make sure they are safe
• pro: without them, no install script can write to disk in its own module folder, so unless the install script does nothing but print some things to standard out, the modules you need will not install

If you hate the idea, use nvm, and then you don't need sudo. Of course, you are still running arbitrary install scripts as your own user, and while that is marginally safer than running them as root, its not much.

But your choice is between being able to install modules with npm, or not being able to install them, so security may not be the relevant question here.

[notbrain]

But the docs state: strong-pm is incompatible with nvm.

[sam-github]

Where? I don't see that in the README. If it doesn't work (you tried?) then just do a tgz install.

Or follow our suggestion, use --unsafe-perms

[notbrain]

@sam-github My bad I should have qualified: strong-pm as a service is incompatible with nvm. Not sure why you'd use strong-pm over full strongloop if not running a service. Especially on production.

https://docs.strongloop.com/display/SLC/Setting+up+a+production+host

[sam-github]

Ah, right, nvm requires a startup script to set the paths. You could hack the service file to give it the paths to the nvm installed node, but why? Just do a normal node install.

@notbrain what is your question? is there anything I can help with?

[notbrain]

@sam-github no sorry just piling on a closed issue unnecessarily, was just checking up on --unsafe-perms issues with a new node 8 install where installing strongloop -g breaks with an infinite loop on node-gyp temp dir, but fixed with --unsafe-perms as far as I can tell.

[sam-github]

ok. strongloop is pretty close to deprecated, you should be moving to the loopback cli or the apiconnect cli, and to strong-supervisor to replace strong-pm

[notbrain]

Will strong-supervisor work seamlessly with strongloop/loopback 2.x apps without modification? In other words it's just a cluster/process manager running as a service just like strong-pm? What's the best source for a guide to upgrading from 2.x to 3 and strong-supervisor?

[OT] We'd love to upgrade to all the new tools but we have an inordinate amount of reliance on loopback.getCurrentContext() that we are working to port that's non trivial (the glorious cls library at the core, and the lack of a clear way to get http request context in loopback 3 without jumping through hoops).

[sam-github]

strong-pm actually uses strong-supervisor to run apps. strong-pm allows remote deploy, but mostly its feature is to expose an API that can be used by Arc, but Arc is deprecated...

also, strong-supervisor (and thus strong-pm that uses it) does nothing special to support loopback apps, and loopback apps require nothing special.

getCurrentContext() is a problem, we wish LB had never used cls. LB is working on a replacement, and, not that it helps now, recent and ongoing work in node core may make tracking async context more reliable