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

Empieza revisando el manejo existente de permisos de --allow-fs-read y --allow-fs-write, y después reproduce el ejemplo de realpathSync de macOS del issue. El issue no menciona archivos ni tests, así que localiza primero los puntos de entrada del análisis de flags y de la política del sistema de archivos. Se considera terminado cuando --allow-fs-tmp concede el acceso previsto al directorio temporal en todas las plataformas sin debilitar las comprobaciones no relacionadas del sistema de archivos.

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.