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 in errno module
• map ENOTCAPABLE to PermissionError. Insufficient capabilities is a sort of permission problem.
• catch PermissionError additionally to FileNotFoundError at places that read VENV_LANDMARK and BUILDDIR_TXT