You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support creating temporary files and directories #306
As far as I know, implementations will fallback to getenv("TEMP_DIR") as the base temp directory
WASI implementations really shouldn't be doing this, nor should WASI explicitly sanction it, as that'd go against WASI's design principles: it'd make shared global state available to content implicitly. Whatever data other processes leave in that directory would now be accessible from within the sandbox.
Even if you solve that part by instead creating an isolated temporary directory just for this sandboxed content, there are still tricky issues: depending on the OS and configuration, you can do DoS attacks by writing large files. And you can gather information about the system by figuring out the free space, again by writing large files, but incrementally until you get an error.
We clearly should have support for temp_dir etc, but it'll probably have to come through an explicit capability the application needs to request.
Many applications really want/need temporary files, especially considering how important it is on Wasm to not blow up the memory usage, since allocated memory can't be reclaimed.
It would also be nice to specify a minimum required size and a requested size when creating a temp dir/file, and to ask the environment for size allowance.
What's the best way to push this forward? A concrete API proposal?
Even if you solve that part by instead creating an isolated temporary directory just for this sandboxed content, there are still tricky issues: depending on the OS and configuration, you can do DoS attacks by writing large files. And you can gather information about the system by figuring out the free space, again by writing large files, but incrementally until you get an error.
That is already possible if you have any directory exposed to the wasi module. So maybe just have a --allow-tmpdir option?
Activity
caspervonb commentedon Aug 5, 2020
As far as I know, implementations will fallback to getenv("TEMP_DIR") as the base temp directory, do we need to provide anything else here?
bjorn3 commentedon Aug 5, 2020
std::env::temp_dir()panics on WASI: https://github.com/rust-lang/rust/blob/dab2ae0404014b4fbc5a32a8c954fe6068b25f71/library/std/src/sys/wasi/os.rs#L169tschneidereit commentedon Aug 5, 2020
WASI implementations really shouldn't be doing this, nor should WASI explicitly sanction it, as that'd go against WASI's design principles: it'd make shared global state available to content implicitly. Whatever data other processes leave in that directory would now be accessible from within the sandbox.
Even if you solve that part by instead creating an isolated temporary directory just for this sandboxed content, there are still tricky issues: depending on the OS and configuration, you can do DoS attacks by writing large files. And you can gather information about the system by figuring out the free space, again by writing large files, but incrementally until you get an error.
We clearly should have support for
temp_diretc, but it'll probably have to come through an explicit capability the application needs to request.theduke commentedon Jun 15, 2022
Chiming in here: I had the exact same idea.
Many applications really want/need temporary files, especially considering how important it is on Wasm to not blow up the memory usage, since allocated memory can't be reclaimed.
It would also be nice to specify a minimum required size and a requested size when creating a temp dir/file, and to ask the environment for size allowance.
What's the best way to push this forward? A concrete API proposal?
bjorn3 commentedon Jun 15, 2022
That is already possible if you have any directory exposed to the wasi module. So maybe just have a
--allow-tmpdiroption?