Description
Bug report
WASI has a capability-based security concept. A process must have a valid handle to open a resource. For example WASI runtimes let processes only open files that are inside a directory tree for which the process owns a file descriptor. wasmtime implements this with openat2(2) with flags RESOLVE_NO_MAGICLINKS | RESOLVE_BENEATH
. Any attempt to open a file outside results in OSError: [Errno 76] Capabilities insufficient
(ENOTCAPABLE
/ __WASI_ERRNO_NOTCAPABLE
).
getpath.py
runs into the capability issue in several places when the module attempts to read from landmark files VENV_LANDMARK
and BUILDDIR_TXT
. On wasmtime the WASI process starts with CWD=/
(root). By default the process does not have capability to access /
. Our tests currently work around the problem by mapping on the host SRCDIR
to /
inside the WASI environment. Without the mapping, Python startup fails with
Exception ignored error evaluating path:
Traceback (most recent call last):
File "<frozen getpath>", line 353, in <module>
OSError: [Errno 76] Capabilities insufficient
Fatal Python error: error evaluating path
Python runtime state: core initialized
Your environment
wasm32-wasi
Fix proposal
- expose
ENOTCAPABLE
inerrno
module - map
ENOTCAPABLE
toPermissionError
. Insufficient capabilities is a sort of permission problem. - catch
PermissionError
additionally toFileNotFoundError
at places that readVENV_LANDMARK
andBUILDDIR_TXT