test: set umask explicitly

[i8-pi]

Some tests which create files and check file permissions assume the
umask is compatible with 022, and break when set to something like 007.
Explicitly set umask to 022

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

I'm seeing test errors

=== release test-fs-mkdir-mode-mask ===                                       
Path: parallel/test-fs-mkdir-mode-mask
assert.js:86
  throw new AssertionError(obj);
  ^

AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:

416 !== 420

    at test (/home/i8-pi/src/node/test/parallel/test-fs-mkdir-mode-mask.js:32:12)
    at Object.<anonymous> (/home/i8-pi/src/node/test/parallel/test-fs-mkdir-mode-mask.js:44:1)

when running
umask 007; make -j4 test

[Trott]

The issue here is that the temp directory is being created with more restrictive permissions than that being used by the test. Rather than fixing in the Python test runner, might it be better to change the tmpdir module (in test/common) to specify mode 755 when creating the temp directory? This would have the following advantages:

• Fixes it both with and without the Python test runner. (./node test/parallel/test-fs-mkdir-mode-mask.js will work no matter what your starting umask.)

• Keeps all the tmpdir code in one place.

• Allows us to run tests with different umasks easily to make sure they still work. In other words, Node.js should work as expected no matter what the starting umask, but by forcing the starting umask, maybe we miss something.

Counterarguments I can think of would be that this solution is simpler, and there may be edge cases where it's more robust too although I can't think of any.

[i8-pi]

Sorry, I didn't list all failing tests. Here are the rest:

=== release test-fs-open-mode-mask ===                               
Path: parallel/test-fs-open-mode-mask
assert.js:86
  throw new AssertionError(obj);
  ^

AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:

416 !== 420

    at test (/home/i8-pi/src/node/test/parallel/test-fs-open-mode-mask.js:25:12)
    at Object.<anonymous> (/home/i8-pi/src/node/test/parallel/test-fs-open-mode-mask.js:41:1)

=== release test-fs-promises-file-handle-chmod ===                         
Path: parallel/test-fs-promises-file-handle-chmod
(node:9455) ExperimentalWarning: The fs.promises API is experimental
/home/i8-pi/src/node/test/common/index.js:690
const crashOnUnhandledRejection = (err) => { throw err; };
                                             ^

AssertionError [ERR_ASSERTION]: Expected values to be strictly deep-equal:

288 !== 292

    at validateFilePermission (/home/i8-pi/src/node/test/parallel/test-fs-promises-file-handle-chmod.js:22:10)

so this isn't purely a tmpdir issue

I would consider the umask part of the test environment that the test framework should sanitize before each run, just like with environment variables. A common entry point to all test would be the best place to set it, if the Python test runner is not such a place

If there are tests that should be run with a different umask, I think they should be separate tests where we explicitly override the default, so a single test run covers all cases

[Trott]

so this isn't purely a tmpdir issue

All of the listed failures are indeed the same tmpdir issue (which makes sense because tests generally shouldn't be creating files outside of tmpdir).

I would consider the umask part of the test environment that the test framework should sanitize before each run, just like with environment variables. A common entry point to all test would be the best place to set it, if the Python test runner is not such a place

If there are tests that should be run with a different umask, I think they should be separate tests where we explicitly override the default, so a single test run covers all cases

That all makes a lot of sense to me. Perhaps both things should be done.

[Trott]

CI: https://ci.nodejs.org/job/node-test-pull-request/19819/

[Trott]

Belated welcome @i8-pi and thanks for the pull request! As you might guess, reviews can be a bit slow to happen this time of year, even for simple changes, so thanks in advance for your patience.

[bnoordhuis]

Thanks @i8-pi, LGTM. CI: https://ci.nodejs.org/job/node-test-pull-request/19853/

[addaleax]

Windows re-build: https://ci.nodejs.org/job/node-test-commit-windows-fanned/23668/

[addaleax]

Landed in ee592c3