Wasm Language Runtimes provides popular language runtimes (Ruby, Python, …) precompiled to WebAssembly that are tested for compatibility and kept up to date when new versions of upstream languages are released
Apache License 2.0
327
stars
27
forks
source link
fix: Patch for `is_readable()` and `is_writable()` to bypass WASI preview1 limitations with stating files #90
In wasi-libc stat(), since there is no user/group concept in Wasm, st_mode is initialized to 000, as well as st_uid and st_gid. This way, is_readable(), is_writable() and is_executable() will return TRUE.
Two approaches have been discussed:
Patch those methods to always return TRUE. This works for many scenarios since most PHP apps will later check (ie: fopen()) the concrete operation returns the right value even if the is_xxxable() function was previously called.
Trial and error. To avoid the above assumption and returning fake values that might be totally wrong, a different approach is to actually try to open/write those resources and return the result.
The latter approach seems more appropriate. The only drawback is a small penalty in performance since the execution of the new checkers takes longer than simply querying the values from stat. But once PHP's cache starts hitting, performance shouldn't be affected. But given there exist corner cases that this hack can't deal with, we decided to go with the former option, which is also what Python for WASI does (just relying on wasi-libc).
In wasi-libc
stat()
, since there is no user/group concept in Wasm,st_mode
is initialized to000
, as well asst_uid
andst_gid
. This way,is_readable()
,is_writable()
andis_executable()
will returnTRUE
.Two approaches have been discussed:
Patch those methods to always return TRUE. This works for many scenarios since most PHP apps will later check (ie:
fopen()
) the concrete operation returns the right value even if theis_xxxable()
function was previously called.Trial and error. To avoid the above assumption and returning fake values that might be totally wrong, a different approach is to actually try to open/write those resources and return the result.
The latter approach seems more appropriate. The only drawback is a small penalty in performance since the execution of the new checkers takes longer than simply querying the values from stat. But once PHP's cache starts hitting, performance shouldn't be affected. But given there exist corner cases that this hack can't deal with, we decided to go with the former option, which is also what Python for WASI does (just relying on wasi-libc).