Repository navigation
NODE_PATH not recognized when cap_net_bind_service is set #22648
Description
- Version: v10.9.0
- Platform: Linux NZXT 4.9.0-5-rt-amd64 deps: update openssl to 1.0.1j #1 SMP PREEMPT RT Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux
- Subsystem: module require
I recently upgraded my Node.js version from v9.6.1 to v10.9.0, and the behavior related to the capability cap_net_bind_service has changed.
Up until the v9.6.1 version, i have always set the net_bind_service capability to be able to load my service on ports 80 and 443 on my development machine. It has always worked as expected.
With v10.9.0, it prevents the NODE_PATH env variable to be used to set a different require path.
Full commands to replicate the behavior (v9.6.1):
$ cd ~/tmp/node/node-v9.6.1-linux-x64
$ sudo cp -r bin include lib share /usr/local/
$ sudo setcap cap_net_bind_service=+ep /usr/local/bin/node
$ node -v
v9.6.1
$ NODE_PATH=$PWD"/lib" node
> console.log(process.env.NODE_PATH)
/home/louis/tmp/node/node-v9.6.1-linux-x64/lib
undefined
> require.resolve.paths("custom")
[ '/home/louis/tmp/node/node-v9.6.1-linux-x64/repl/node_modules',
'/home/louis/tmp/node/node-v9.6.1-linux-x64/node_modules',
'/home/louis/tmp/node/node_modules',
'/home/louis/tmp/node_modules',
'/home/louis/node_modules',
'/home/node_modules',
'/node_modules',
'/home/louis/tmp/node/node-v9.6.1-linux-x64/lib',
'/home/louis/.node_modules',
'/home/louis/.node_libraries',
'/usr/local/lib/node',
'/home/louis/tmp/node/node-v9.6.1-linux-x64/lib',
'/home/louis/.node_modules',
'/home/louis/.node_libraries',
'/usr/local/lib/node' ]Here, with the version v9.6.1, /home/louis/tmp/node/node-v9.6.1-linux-x64/lib is correctly set in the require paths
Now the same steps with the v10.9.0:
$ cd ~/tmp/node/node-v10.9.0-linux-x64
$ sudo cp -r bin include lib share /usr/local/
$ sudo setcap cap_net_bind_service=+ep /usr/local/bin/node
$ node -v
v10.9.0
$ NODE_PATH=$PWD"/lib" node
> console.log(process.env.NODE_PATH)
/home/louis/tmp/node/node-v10.9.0-linux-x64/lib
undefined
> require.resolve.paths("custom")
[ '/home/louis/tmp/node/node-v10.9.0-linux-x64/repl/node_modules',
'/home/louis/tmp/node/node-v10.9.0-linux-x64/node_modules',
'/home/louis/tmp/node/node_modules',
'/home/louis/tmp/node_modules',
'/home/louis/node_modules',
'/home/node_modules',
'/node_modules',
'/usr/local/lib/node',
'/usr/local/lib/node' ]In this last example, you can see that /home/louis/tmp/node/node-v9.6.1-linux-x64/lib has disapeared.
However, without the setcap command, NODE_PATH works as expected with v10.9.0.
$ sudo setcap -r /usr/local/bin/node #removes capabilities
$ node -v
v10.9.0
$ NODE_PATH=$PWD"/lib" node
> process.env.NODE_PATH
'/home/louis/tmp/node/node-v10.9.0-linux-x64/lib'
> require.resolve.paths("custom")
[ ... (skipped)
'/home/louis/tmp/node/node-v10.9.0-linux-x64/lib',
... (skipped ]I will now use Node.js without the bind capability (port >1024), but I think this is a regression.
Activity
mscdex commentedon Sep 2, 2018
FWIW setting
cap_net_bind_service=+epon the node executable is a bad idea as it affects any invocation of node, not just a specific script or specific server within a script.Musinux commentedon Sep 2, 2018
Of course, but it doesn't explain why this behavior changed.
richardlau commentedon Sep 4, 2018
I suspect #18511 -- Note that after that PR
NODE_PATHis accessed viasafeGetenvwhereas before it was directly read fromprocess.env.Trott commentedon Nov 16, 2018
@richardlau Does that make this not-a-bug in your view?
richardlau commentedon Nov 17, 2018
@Trott I think so? I'm not really familiar with
setcapbut it looks like we made a deliberate change in #9160 and #18511.It is a change in behaviour though, and perhaps it could have been better communicated. #23770 documented a different environment variable (
NODE_EXTRA_CA_CERTS) but there are more than a few others in addition toNODE_PATHwhich are affected (ignored) when Node.js is run with capabilities.Trott commentedon Nov 18, 2018
Closing. PR to update docs would be welcome. Feel free to comment (or re-open if GitHub lets you) if you feel like I'm closing this before its time.