New permission: `--allow-fs-tmp` boolean

Comece revisando o tratamento existente das permissões de --allow-fs-read e --allow-fs-write e, em seguida, reproduza o exemplo de realpathSync no macOS da issue. A issue não nomeia arquivos nem testes, então localize primeiro os pontos de entrada do parsing das flags e da política do sistema de arquivos. Considera-se concluído quando --allow-fs-tmp conceder o acesso pretendido ao diretório temporário entre plataformas, sem enfraquecer verificações não relacionadas do sistema de arquivos.

What is the problem this feature will solve?

Determining the paths to allow if we want to give read/write access to tmp in a cross-platform way is tedious and error prone.
The path cannot be hardcoded for obvious reasons, but there is no reliable way to get it from env variables either.
In practical use, RW access to tempdir is widely needed.

Even if we get the tmpdir path, it happens to be a symlink on a mac, so creating a file in temp and passing it to a library that carefuly resolves symlinks before doing its work will once again trigger a policy error.

What is the feature you are proposing to solve the problem?

Pseudocode of what we'd need to do

  if (configOptions['--allow-fs-tmp'] === true) {
      delete configOptions['--allow-fs-tmp']
      if (configOptions['--allow-fs-write']) {
        if (typeof configOptions['--allow-fs-write'] === 'string') {
          configOptions['--allow-fs-write'] = [
            configOptions['--allow-fs-write'],
          ]
        }
        if (configOptions['--allow-fs-write'] === true) {
          return // none of this matters
        }
      } else {
        // do this for both undefined and false
        configOptions['--allow-fs-write'] = []
      }
      const tmp = tmpdir()
      configOptions['--allow-fs-write'].push(tmp)
      // because macos is being weird
      const tmpRealPath = realpathSync(tmp)
      if (tmpRealPath !== tmp) {
        configOptions['--allow-fs-write'].push(tmpRealPath)
      }
    }

What alternatives have you considered?

• tried using env variables in userspace, but stumbled upon the symlink issue on mac soon.
• considered separete read and write permissions, but can't think of a usecase for readonly tmp access where it makes a difference security-wise.

Implementation considerations

macos symlink issue

tmpdir being a link on mac revealed another issue in testing - the implementation of realpath uses OS resolution on linux but seems to fall back to iterating over parents and reading whether they're a link or not on a mac. Which results in the following working fine on linux but not on mac:

given 
naugtur@localhostage:/tmp $ ls -al ?
q:
total 0
drwxrwxr-x  3 naugtur naugtur  60 Sep 15 13:47 .
drwxrwxrwt 30 root    root    760 Sep 15 13:50 ..
drwxrwxr-x  2 naugtur naugtur  40 Sep 15 13:47 w

z:
total 0
drwxrwxr-x  2 naugtur naugtur  60 Sep 15 13:48 .
drwxrwxrwt 30 root    root    760 Sep 15 13:50 ..
lrwxrwxrwx  1 naugtur naugtur   8 Sep 15 13:48 x -> /tmp/q/w

$ node --permission --allow-fs-read=/tmp/q/w --allow-fs-read=/tmp/z/x 
Welcome to Node.js v26.8.1.
Type ".help" for more information.
> 
Access to FileSystemWrite is restricted.
REPL session history will not be persisted.
> const fs = require('fs')
undefined
> fs.existsSync('/tmp/z/x')
true
> fs.existsSync('/tmp/q/w')
true
> fs.existsSync('/tmp/')
Uncaught:
Error: Access to this API has been restricted. Use --allow-fs-read to manage permissions.
    at Object.existsSync (node:fs:339:18) {
  code: 'ERR_ACCESS_DENIED',
  permission: 'FileSystemRead',
  resource: '/tmp/'
}
> fs.realpathSync('/tmp/z/x')
'/tmp/q/w'
> 

The realpathSync call on mac would iterate through all parents manually to check whether they're links and trigger policy checks for each, so for the same code to work, it'd have to be allowed read on all of /tmp (more specifically /var on mac, which is much worse as there's descriptors to read stuff from other processes there)

The basic implementation of this feature will fail on a mac if someone attempts to call realpath of a path in tempdir.

My preference is implement this and report a separate issue where policy check for realpath would be done on the final result not the intermediate steps of the lookup of the fallback. If possible. Alternatively, the first policy error it gets is swallowed and turned into an assumption that all above is a real path in absence of ability to check.