mirror of
https://github.com/nodejs/node.git
synced 2026-10-28 18:25:13 +08:00
James M Snell
f378cfcfbf
Necessarily semver-major. When `--permission` is on, every env var not matched by `--allow-env` is removed at startup. It takes names, prefix patterns (`PREFIX_*`), or `*`, repeatable or comma-sep'd. There are a range of env vars that Node.js itself uses, and a default range that are generally known to be safe in common usage. These are never scrubbed. These include things like `NODE_OPTIONS`, `NODE_EXTRA_CA_CERTS`, `PATH`, `HOME`, etc. `NODE_ENV` is not in the defaults and must be allowed explicitly. Proxy vars (`HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY`) are also not in the defaults since they can carry credentials. When `--use-env-proxy` or `NODE_USE_ENV_PROXY` is set and any of them were removed, a single warning naming them is emitted. Env vars can be dropped at runtime after reading using `permission.drop()`. This is a stronger protection than using `process.env.FOO = undefined` because it will scrub the env var also from the environment block. On Linux, the removed entries are overwritten in the initial environment block. fs reads of any other process's /proc/<pid>/environ, ancestors included, are denied regardless of `--allow-fs-read`. A process's own is readable only with `--allow-env=*`. Symlinks are resolved before the check so paths like /dev/fd/../../<ppid>/environ are caught. The check only canonicalizes paths that statfs() reports are on procfs. On Windows, removal also clears the C runtime's copy of the environ using _wputenv_s. Reading a removed name returns undefined, warns once per name, and publishes to a diagnostics channel. Env file keys are allowed. If the user had reason to pass in an env file the assumption is they meant to allow them. File-source config (node.config.json and NODE_OPTIONS from a .env file) can only narrow the allow list. Embedders must call ScrubProcessEnvironment() themselves on startup. This is left up to the embedder to determine the exact timing but needs to be called before startup actually happens. Child processes are started with `--allow-env=*`. Those either receive the explicit env they were started with or only the env they inherit from the parent. Since the parent process is scrubbed, and the child cannot read any other process's /proc/<pid>/environ, it should never see more than the parent can. Main part of the impl was done by hand. Docs, tests, verification pass, and cleanup nits were automated. Signed-off-by: James M Snell <jasnell@gmail.com> Assisted-by: Opencode PR-URL: https://github.com/nodejs/node/pull/66132 Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Node.js Core Tests
This directory contains code and data used to test the Node.js implementation.
For a detailed guide on how to write tests in this directory, see the guide on writing tests.
On how to run tests in this directory, see the contributing guide.
For the tests to run on Windows, be sure to clone Node.js source code with the
autocrlf git config flag set to true.
Test Directories
| Directory | Runs on CI | Purpose |
|---|---|---|
abort |
Yes | Tests that use --abort-on-uncaught-exception and other cases where we want to avoid generating a core file. |
addons |
Yes | Tests for addon functionality along with some tests that require an addon. |
async-hooks |
Yes | Tests for async_hooks functionality. |
benchmark |
Yes | Test minimal functionality of benchmarks. |
cctest |
Yes | C++ tests that are run as part of the build process. |
code-cache |
No | Tests for a Node.js binary compiled with V8 code cache. |
common |
N/A | Common modules shared among many tests.1 |
doctool |
Yes | Tests for the documentation generator. |
es-module |
Yes | Test ESM module loading. |
fixtures |
N/A | Test fixtures used in various tests throughout the test suite. |
internet |
No | Tests that make real outbound network connections.2 |
js-native-api |
Yes | Tests for Node.js-agnostic Node-API functionality. |
known_issues |
Yes | Tests reproducing known issues within the system.3 |
message |
Yes | Tests for messages that are output for various conditions |
node-api |
Yes | Tests for Node.js-specific Node-API functionality. |
parallel |
Yes | Various tests that are able to be run in parallel. |
pseudo-tty |
Yes | Tests that require stdin/stdout/stderr to be a TTY. |
pummel |
No | Various tests for various modules / system functionality operating under load. |
sequential |
Yes | Various tests that must not run in parallel. |
testpy |
N/A | Test configuration utility used by various test suites. |
tick-processor |
No | Tests for the V8 tick processor integration.4 |
v8-updates |
No | Tests for V8 performance integration. |
-
Tests for networking related modules may also be present in other directories, but those tests do not make outbound connections. ↩︎
-
All tests inside of this directory are expected to fail. If a test doesn't fail on certain platforms, those should be skipped via
known_issues.status. ↩︎ -
The tests are for the logic in
lib/internal/main/prof_process.jsandlib/internal/v8_prof_polyfill.js. The tests confirm that the profile processor packages the correct set of scripts from V8 and introduces the correct platform specific logic. ↩︎