Repository navigation
setcap on Node.js prevents processing of NODE_OPTIONS #37588
Description
Activity
- addedlinuxIssues and PRs related to the Linux platform.Issues and PRs related to the Linux platform.securityIssues and PRs related to security.Issues and PRs related to security.
on Aug 9, 2021 When did this behavior break? It doesn't look like the code changed. Is this a change in kernel security?
Reproduced on 17.3.0. Its very important for debugging sсripts that using Bluetooth and GPIO. Please fix it.
Reacted by Arend de BoerJust wanted to share this is also happening for node v14 under Linux. The annoying part is it took me hours to land at this conclusion.
The only workaround seems to be NOT using
setcap... some alternatives include just using any other port not requiring elevated privileges, someiptablesstuff or running withauthbindinstead (but I havent tried it).So I had the use case to debug as non-root code using
raw-socketfor which the capabilitycap_net_rawis needed in a Dev Container using VS Code. My workaround to realize this is using a wrapper.VS Code starts the debugging like
/usr/bin/env 'NODE_OPTIONS= --require ...' 'VSCODE_INSPECTOR_OPTIONS=...' /usr/bin/node ./main.jswhich is not working as NODE_OPTIONS is not evaluated as non-root with the enabled capability.
So i created a wrapper, which extracts the value of
NODE_OPTIONSand puts it as node argument, like:/usr/bin/node.real --require ... ./main.jsThis works because the arguments are evaluated correctly even as non-root having capabilities.
The Wrapper
node-wrapper.sh:#!/bin/bash NODE_ARGS=() if [[ -n "$NODE_OPTIONS" ]]; then eval "read -r -a NODE_ARGS <<< \"$NODE_OPTIONS\"" unset NODE_OPTIONS fi REAL_NODE="$(command -v node).real" exec "$REAL_NODE" "${NODE_ARGS[@]}" "$@"
Using in a Dockerfile for the the Dev Container:
COPY node-wrapper.sh /usr/bin/node-wrapper.sh RUN chmod +x /usr/bin/node-wrapper.sh && \ NODE_BIN="$(command -v node)" && \ # Move the original node binary to .real mv "$NODE_BIN" "${NODE_BIN}.real" && \ # Move the wrapper in place mv /usr/bin/node-wrapper.sh "$NODE_BIN"
github-actions commented
on Jun 27, 2026 on Jun 27, 2026 – with GitHub ActionsContributorMore actionsThis issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.- addedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Jun 27, 2026 not stale
- removedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Jun 28, 2026 github-actions commented
on Sep 27, 2026 on Sep 27, 2026 – with GitHub ActionsContributorMore actionsThis issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.- addedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Sep 27, 2026 Not stale.
- removedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Sep 28, 2026
What steps will reproduce the bug?
sudo setcap cap_net_admin+iep $(which node)How often does it reproduce? Is there a required condition?
100% of the time
What is the expected behavior?
I would expect NODE_OPTIONS to be processed regardless.
What do you see instead?
Additional information
Reported on microsoft/vscode-js-debug#852