In many cases we can query the environment variable directly instead
of encoding it into UTF8 first and then decoding it again from
UTF8 via an intermediate V8 string.
Drive-by: pass per_process::system_environment explicitly when
the real environment variables are supposed to be used instead of
relying on fallback with defaults.
PR-URL: https://github.com/nodejs/node/pull/51829
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Within Node.js, attempt to determine if libuv is using io_uring. If it
is, disable process.setuid() and other user identity setters.
We cannot fully prevent users from changing the process's user identity,
but this should still prevent some accidental, dangerous scenarios.
PR-URL: https://github.com/nodejs-private/node-private/pull/528
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
CVE-ID: CVE-2024-22017
SYS_capget with _LINUX_CAPABILITY_VERSION_3 returns the process's
permitted capabilities as two 32-bit values. To determine if the only
permitted capability is indeed CAP_NET_BIND_SERVICE, it is necessary to
check both of those values.
Not doing so creates a vulnerability that potentially allows
unprivileged users to inject code into a privileged Node.js process
through environment variables such as NODE_OPTIONS.
PR-URL: https://github.com/nodejs-private/node-private/pull/505
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
CVE-ID: CVE-2024-21892
If uid_t/gid_t are uint32_t, then the casts are unnecessary. This
appears to be true in all recent versions of all supported platforms,
so this change makes that assumption explicit and removes the casts.
Conversely, if uid_t/gid_t are smaller unsigned integer types (such as
uint16_t in earlier versions of Linux) or signed integer types (such as
int32_t), then the casts are potentially dangerous because they might
change the value of the uid/gid. If this happens on any platform, the
added static_assert will fail, and additional bound checks should be
introduced.
PR-URL: https://github.com/nodejs/node/pull/44914
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
So far, process initialization has been a bit all over the place
in Node.js. `InitializeNodeWithArgs()` is our main public API
for this, but inclusion of items in it vs. `InitializeOncePerProcess()`
and `PlatformInit()` has been random at best. Likewise,
some pieces of initialization have been guarded by
`NODE_SHARED_MODE`, but also fairly randomly and without
any meaningful connection to shared library usage.
This leaves embedders in a position to cherry-pick some of
the initialization code into their own code to make their
application behave like typical Node.js applications to the
degree to which they desire it.
Electron takes an alternative route and makes direct use of
`InitializeOncePerProcess()` already while it is a private
API, with a `TODO` to add it to the public API in Node.js.
This commit addresses that `TODO`, and `TODO`s around the
`NODE_SHARED_MODE` usage. Specifically:
- `InitializeOncePerProcess()` and `TearDownOncePerProcess()`
are added to the public API.
- The `flags` option of these functions are merged with the
`flags` option for `InitializeNodeWithArgs()`, since they
essentially share the same semantics.
- The return value of the function is made an abstract class,
rather than a struct, for easier API/ABI stability.
- Initialization code from `main()` is brought into these
functions (since that makes sense in general).
- Add a `TODO` for turning `InitializeNodeWithArgs()` into
a small wrapper around `InitializeOncePerProcess()` and
eventually removing it (at least one major release cycle
each, presumably).
- Remove `NODE_SHARED_MODE` guards and replace them with
runtime options.
PR-URL: https://github.com/nodejs/node/pull/44121
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
This commit updates SafeGetenv to check if the current process has the
effective capability cap_net_bind_service set, and if so allows
environment variables to be read.
The motivation for this change is a use-case where Node is run in a
container, and the is a requirement to be able to listen to ports
below 1024. This is done by setting the capability of
cap_net_bind_service. In addition there is a need to set the
environment variable `NODE_EXTRA_CA_CERTS`. But currently this
environment variable will not be read when the capability has been set
on the executable.
PR-URL: https://github.com/nodejs/node/pull/37727
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
These cannot be preserved correctly in v8 snapshot. Currently
none of these are called during bootstrap, this adds assertions
to make sure future contributors do not accidentally call
these in the wrong time.
Consider this, on the machine that builds releases:
```
process.cwd(); # "/home/iojs/build/workspace/"
```
If `process.cwd()` is cached as in
https://github.com/nodejs/node/pull/27224, when the user
downloads this binary to their machine:
```
$ cd ~/
$ pwd # "/User/foo"
$ node -p "process.cwd()" # "/home/iojs/build/workspace/"
```
This patch only adds checks in methods that get states from the
environment - it's not likely that the setters would be called
during bootstrap, and if they are called, we'll just ignore them
and whatever tests that test the change would fail when snapshot
is enabled. However the getters may be called in order
to persist information into strings and that would be harder
to catch (the test is only likely to test the format of these
strings which won't be useful).
PR-URL: https://github.com/nodejs/node/pull/27234
Refs: https://github.com/nodejs/node/pull/27224
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Instead of sharing the OS-backed store for all `process.env` instances,
create a copy of `process.env` for every worker that is created.
The copies do not interact. Native-addons do not see modifications to
`process.env` from Worker threads, but child processes started from
Workers do default to the Worker’s copy of `process.env`.
This makes Workers behave like child processes as far as `process.env`
is concerned, and an option corresponding to the `child_process`
module’s `env` option is added to the constructor.
Fixes: https://github.com/nodejs/node/issues/24947
PR-URL: https://github.com/nodejs/node/pull/26544
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Embedders may want to control whether a Node.js instance
controls the current process, similar to what we currently
have with `Worker`s.
Previously, the `isMainThread` flag had a bit of a double usage,
both for indicating whether we are (not) running a Worker and
whether we can modify per-process state.
PR-URL: https://github.com/nodejs/node/pull/25881
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
So that it's easier to tell whether we are manipulating per-process
global states that may need to be treated with care to avoid races.
Also added comments about these variables and moved some of them
to a more suitable compilation unit:
- Move `v8_initialized` to `util.h` since it's only used in
`util.cc` and `node.cc`
- Rename `process_mutex` to `tty_mutex` and move it into
`node_errors.cc` since that's the only place it's used
to guard the tty.
- Move `per_process_opts_mutex` and `per_process_opts`
into `node_options.h` and rename them to
`per_process::cli_options[_mutex]`
- Rename `node_isolate[_mutex]` to `per_process::main_isolate[_mutex]`
PR-URL: https://github.com/nodejs/node/pull/25302
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Expose the POSIX credential accessors through
`internalBinding('credentials')` instead of setting them on the
process or bootstrapper object from C++ directly. Also moves
`SafeGetEnv` from `internalBinding('util')` to
`internalBinding('credentials')` since it's closely related to
the credentials.
In the JS land, instead of wrapping the bindings then writing
to the process object directly in main_thread_only.js, return
the wrapped functions back to bootstrap/node.js where they get
written to the process object conditionally for clarity.
Refs: https://github.com/nodejs/node/issues/24961
PR-URL: https://github.com/nodejs/node/pull/25066
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
