NODE_PATH not recognized when cap_net_bind_service is set

[Musinux]

• 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.

[mscdex]

FWIW setting cap_net_bind_service=+ep on 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]

Of course, but it doesn't explain why this behavior changed.

[richardlau]

I suspect #18511 -- Note that after that PR NODE_PATH is accessed via safeGetenv whereas before it was directly read from process.env.

[Trott]

@richardlau Does that make this not-a-bug in your view?

[richardlau]

@Trott I think so? I'm not really familiar with setcap but 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 to NODE_PATH which are affected (ignored) when Node.js is run with capabilities.

[Trott]

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.