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.
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
What alternatives have you considered?