wasmtime-wasi accepts a pair of what are effectively booleans, DirPerms and FilePerms, to set permissions on a preopened_dir. This permissions structure is specific to wasmtime-wasi's implementation, and is not specified by WASI. It is very poorly specified by its own documentation (a sum total of two doc strings on the DirPerms flags) and that documentation is inconsistent with the actual behavior - DirPerms::MUTATE without FilePerms::WRITE does not permit creating a new file.
The weird corner case created by DirPerms::MUTATE without FilePerms::WRITE has been the subject of multiple recent Wasmtime security advisories: GHSA-2r75-cxrj-cmph GHSA-4ch3-9j33-3pmj. I conducted an informal survey while remediating these, and AFAIK no production user of wasmtime-wasi is using that combination of permissions, nor any of the other "weird" cases (any of FilePerms or DirPerms being empty).
The set that actually seems to be useful to wasmtime-wasi's users is either that an entire preopen is is read-write, or is read-only. So, this issue proposes deleting the DirPerms and FilePerms structures, and replacing them with a single boolean that permits mutation of the entire preopen. This should hopefully make the permissions structure easy for both the implementation to enforce and for users to understand, and reduce the amount of time maintainers spend addressing security advisories for behaviors that nobody uses.
wasmtime-wasi accepts a pair of what are effectively booleans, DirPerms and FilePerms, to set permissions on a
preopened_dir. This permissions structure is specific to wasmtime-wasi's implementation, and is not specified by WASI. It is very poorly specified by its own documentation (a sum total of two doc strings on the DirPerms flags) and that documentation is inconsistent with the actual behavior - DirPerms::MUTATE without FilePerms::WRITE does not permit creating a new file.The weird corner case created by DirPerms::MUTATE without FilePerms::WRITE has been the subject of multiple recent Wasmtime security advisories: GHSA-2r75-cxrj-cmph GHSA-4ch3-9j33-3pmj. I conducted an informal survey while remediating these, and AFAIK no production user of wasmtime-wasi is using that combination of permissions, nor any of the other "weird" cases (any of FilePerms or DirPerms being empty).
The set that actually seems to be useful to wasmtime-wasi's users is either that an entire preopen is is read-write, or is read-only. So, this issue proposes deleting the DirPerms and FilePerms structures, and replacing them with a single boolean that permits mutation of the entire preopen. This should hopefully make the permissions structure easy for both the implementation to enforce and for users to understand, and reduce the amount of time maintainers spend addressing security advisories for behaviors that nobody uses.