Report host uid/gid credentials under NODERAWFS

[guybedford]

Reports the real host process credentials for getuid/geteuid/getgid/getegid under NODERAWFS (via node's process.get*id()), rather than the hardcoded 0.

These move from weak C stubs into the JS syscall layer, since a weak C definition otherwise wins over the JS override and the syscall would keep returning 0. Other backends — and Windows, which has no uid/gid concept — continue to report 0. The set* variants stay EPERM: musl routes them all through __setxid, which emscripten stubs out because it relies on dynamic (numeric) syscall dispatch that the compile-time syscall mapping can't provide.

Tested across MEMFS/NODEFS/NODERAWFS (test_fs_getuid).

Made with AI assistance under my review

[sbc100]

Aren't these already tested in test/unistd/misc.c?

[guybedford]

Good point, removed that branch to just test the NODERAWFS path only.

[sbc100]

lgtm % testing question

[sbc100]

Maybe rename the test and the source file test_getuid_noderaws?

[kleisauke]

Would it make more sense to do this under NODE_HOST_ENV rather than NODERAWFS?

[sbc100]

Would it make more sense to do this under NODE_HOST_ENV rather than NODERAWFS?

I'm not sure. NODE_HOST_ENV is specifically about the environment variables. I guess it depends how granular folks want to be in exposing the underlying OS primitives.

These uid/gid settings seems like they should probably also go hand in hard with NODERAWFS since UID and GID number are exports via the filesystem ownership bits (fstat). Unless we also expose getgid etc, users of NODERAWFS will have a confusing mixed picture of the UID space (with the functions reports different IDs to fstat).

[kleisauke]

I see. I thought that decoupling it from NODERAWFS would also make it work with WASMFS. I think my confusion came from these lines:

emscripten/src/lib/libsyscall.js

Lines 331 to 333 in bd5b72d

	// When building with WASMFS the socket syscalls are implemented natively in
	// libwasmfs.a.
	#if PROXY_POSIX_SOCKETS == 0 && WASMFS == 0

That would make me assume that libsyscall.js is also used under WASMFS too, which isn't the case.

emscripten/src/modules.mjs

Lines 89 to 91 in bd5b72d

	if (!WASMFS) {
	libraries.push('libsyscall.js');
	}

(i.e. && WASMFS == 0 always evaluates to true)

That said, adding new features like this (and 16fa2c6) only to the legacy JS filesystem would make it more difficult to enable WASMFS by default in the future.

[sbc100]

I see. I thought that decoupling it from NODERAWFS would also make it work with WASMFS. I think my confusion came from these lines:

emscripten/src/lib/libsyscall.js

Lines 331 to 333 in bd5b72d

	// When building with WASMFS the socket syscalls are implemented natively in
	// libwasmfs.a.
	#if PROXY_POSIX_SOCKETS == 0 && WASMFS == 0

That would make me assume that libsyscall.js is also used under WASMFS too, which isn't the case.

emscripten/src/modules.mjs

Lines 89 to 91 in bd5b72d

	if (!WASMFS) {
	libraries.push('libsyscall.js');
	}

(i.e. && WASMFS == 0 always evaluates to true)
That said, adding new features like this (and 16fa2c6) only to the legacy JS filesystem would make it more difficult to enable WASMFS by default in the future.

While its true that extending the old FS makes more work for the WASMFS transition, I don't think that means we shouldn't do it.

I think we are still at the point where its reasonable for some folks to work on the old FS (and make changes like this) while other try to improve WASMFS. I'm personally not 100% convinced the WASMFS even makes sense for NODERAWFS case. For example there is no point the WASMFS in-memory FS cache when using NODERAWFS.. we just want the system calls to be mapped as directly ass possible to the OS in this case.