Add NODE_HOST_ENV to mirror host env vars under node

[sbc100]

This setting is enabled by default when NODERAWFS is enabled, but can also be disabled explicitly.

Fixes: #18816, #25791

[kleisauke]

Instead of this PR, perhaps it would be useful to document at https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#interacting-with-code-environment-variables that it's quite easy to mirror the entire environment on Node.js with:

Module.preRun = () => {ENV = Object.create(process.env)};

(see #3948 (comment) where this was originally mentioned)

[kleisauke]

FWIW, the reason I mentioned this is that Rust no longer test the wasm32-unknown-emscripten target triple on CI due to this:
rust-lang/rust#116381
rust-lang/rust#116362 (comment)

[sbc100]

OK, I went with NODE_HOST_ENV which is enabled by default when NODERAWFS is used.

It should fix the libc++ get_temp_directory issue under windows.

[sbc100]

Reviving this 2 years old PR!

[sbc100]

Ping .. someone want to approve this?

[kripken]

Perhaps leave it orthogonal to NODERAWFS? That would avoid a breaking change, and seems more reasonable unless I'm missing something.

[sbc100]

It is orthogonal, but enabled by NODERAWFS default since I think anyone exposing the full host FS would also certainly also want the host environment variables. They are often very much linked.. think TMPDIR, HOME, etc

Its pretty hard to imagine giving full FS access but then not wanting to give access to environment variables. The former is a lot more permissive.

[sbc100]

I updated the changelog entry and improved the docs.

[kripken]

Fair points. But I still worry about a breaking change here. In particular this exposes more of the host environment to the compiled program - it already had files, and now it has env vars as well, which can contain sensitive info.

[sbc100]

Honestly, you can already access them, at least on linux. i.e. cat /proc/self/environ.

[sbc100]

Another reason to link them by default is that if you don't you into issues like #25791 because the values in the environment don't correspond to real paths on the filesystem. e.g. our fake environment has TMP=/tmp but that path does not exist on windows with NODERAWFS. So I don't think it makes much sense to fake one without the other (unless you really know what you are doing and want to opt into it).

[kripken]

Fair enough, good points.

[kripken]

lgtm % comments

[dschuff]

This may have broken test_std_filesystem_{tempdir_}wasmfs_rawfs on the Chromium CI.

There are also 3 other changes in that roll CL, but this one seems the most likely.